Page 1 of 1

[GSoC 2012] A unit testing framework (covered by GSoC 2011)

Posted: Sun Apr 01, 2012 6:27 pm
by bornToCode
According to me, there are several ways to implement the required solution for this project. One of the solutions is using “GHERKIN” scripts integrated with JUnit/NUnit (Test driven development) or JBehave(Behaviour driven development) to create simple tests as well as automated tests for a desktop or a web application. In my past internship I have used these scripts to write and describe several tests in a human understandable form (specifically English).

Suggested Solution

Gherkin is the language that Cucumber understands. It is a Business Readable, Domain Specific Language that lets you describe software’s behaviour without detailing how that behaviour is implemented. Like Python and YAML, Gherkin is a line-oriented language that uses indentation to define structure. Line endings terminate statements (eg, steps). Either spaces or tabs may be used for indentation (but spaces are more portable). Most lines start with a keyword.Comment lines are allowed anywhere in the file. They begin with zero or more spaces, followed by a hash sign (#) and some amount of text. Parser divides the input into features, scenarios and steps. When you run the feature the trailing portion (after the keyword) of each step is matched to a Ruby code block called Step Definitions. Gherkin serves two purposes – documentation and automated tests. The third is a bonus feature – when it yells in red it’s talking to us, telling us what code we should write. Gherkin’s grammar is defined in the Treetop grammar that is part of the Cucumber codebase. The grammar exists in different flavours for many spoken languages (37 at the time of writing), so that our team can use the keywords in our own language. Let’s say we have the following “Search” story and a more specific scenario – “display an error dialog if I don’t fill in the search form”:

Narrative: I should be able to search
Scenario: I should see an error if I try to search without filling in the search form fields.
When I open ''
When I click on the 'Search' button
Then I should see an error

Similar to other gherkin/cucumber based frameworks the combination would allow us to implement each step of the scenario as a method in a class, which optionally takes parameters mapped to words from the scenario. The above one can be stubbed like below:

@When("I open '$page'")

publicvoidwhenIOpen(String page)
@When("I click on the '$buttonText' button")
publicvoidwhenIClickOnTheButton(String buttonText)
@Then("I should see an error")

Thus we see that using this proposed solution, we can introduce an alternative way of describing test data in external, human-readable text files representing object structure. The scripts generate an underlying code linked together through objects and the keywords are reusable while implementing test APIs.

Another specialty about this method used is to automate the tests, especially when it is needed to do a behaviour testing for a web application. Hence, while the components will be tested, it is easy to integrate the API function with commands to take a screenshot and save the file as an image. Hence as soon as a particular test case is executed, the file is saved the required directory.

My job before GSOC starts would be getting to know the OGRE more by being in touch with mentors and continuously learning about it. In-depth discussions and research upon the existing software architecture would help in identifying the requirements for the API. This would help in organizing test data before actually implementing several tests using the proposed solution.

Deliverables and Timeline

Apr 17- May 8 (three weeks): Studying the specs and the code, and discussions with the mentor and community on the implementation of the API. Key focus on sample APIs for which tests are needed to be written.

May 9 -May 22 (two weeks): Review the existing test fixtures and how are they used in existing test classes. Examine relationships between entities and get to know more about how to enable running the test in a "record" mode to record a positive state.

May 22- Jun 20 (four weeks): Start integrating an existing sample project with GHERKIN and JUnit/NUnit. Implement Gherkin scripts for one of the project’s test class. Implement a corresponding test class and API. Test it thoroughly, collate results and submit to mentor for review. Finally, deploy it to the main application and make sure it doesn’t break existing build plus runs through all of the tests.

Jun 20 - Jul 16 (four weeks): Start test driven development for bigger projects and run code in the mainstream branch. Implement a common API to take a screenshot after a test is over and save it to a required directory. Follow the same steps as earlier to develop new Test projects for existing APIs and deploy it to the main application.

Jul 17- Aug 09 (four weeks): Looking into other existing spots for improvement, whether related to the above two or completely independent. Handle varied scenarios. Handling unforeseen problems if necessary for existing implementations. Starting work on the new spots with changes proposed and continuously reviewed by mentor.

Aug 10 - Aug 17 (one week) Tidying up any loose ends, ensuring the code is integrated and made available on Google Code and in the OGRE repositories.

Re: Project:A unit testing framework (covered by GSoC 2011)

Posted: Wed Apr 04, 2012 2:08 pm
by bornToCode
Hi Team,

On the side note, I used Specflow plug-in/library for .NET integrated with NUnit and followed following steps to build unit and regression tests for a web application:

1) Writing feature files (.fs files) with all sorts of "Scenario Outline", "When", "And", "Then" as well as table of variables whose values were put in.

2) Specflow helps in generating the underlying code with an object oriented way of linkage.

3) Start writing test class (as step definitions) with functions taged along with "When" and "Then" conditions accordingly

4) Import a common class/classes and other entities from actual application code to be able to test completely.




Re: [GSoC 2012] A unit testing framework (covered by GSoC 20

Posted: Wed Apr 04, 2012 2:29 pm
by spacegaier
I am not sure about that proposal. Are you aware that we already had a unit testing GSoC last year (you mentioned it int the thread title but no word in the actual proposal)?

So many questions:
How does your plan integrate with that / use what was already created? What would it mean/ gain for Ogre? It looks like there is Java needed,s o would that introduce a new "dependency"? ...

So far your proposal is a bit vague for my taste. Would be great if you could extend it and make the benefit for Ogre and the integration into what we already have clearer in order to have a chance at being selected.