DevOps Zone is brought to you in partnership with:

I have worked in software development since the mid 90's after a few years in the aerospace industry. Initially a database specialist always a programmer, currently with java. My focus is now on helping organisations to go faster with higher quality. Scrum and Agile are often part of that change. Martin is a DZone MVB and is not an employee of DZone and has posted 10 posts at DZone. View Full User Profile

Tumble dried BDD from Studio Pragmatists

06.07.2010
| 5853 views |
  • submit to reddit

On the 18th of May, 2010, the very new tumbler-glass project by Studio Pragmatists uploaded Tumbler 0.2.1 to Maven.  Having recently written about JBehave I found myself really liking the concept of behavior driven development.  So I decided to write a similar article about Tumbler. If you want the project code its available in my example project.

4 hour time box in 20 minutes!

Once again I decided to time box the work to 4 hours.  This time though the whole process only took about 20 minutes.  The product owner and testers produce a story file.  The Tumbler format allows for multiple stories each containing scenarios, so its possible to cover a complex set of requirements in one file.  This allows for flexibility when breaking down the work into tasks.  As per the usual behavior driven approach, a scenario contains the Given, When and Then sections which describe the behavior.

A simple tumbler behavior file

Story: Building a simple page

Scenario: should create a page 4 lines long with 5 data items in each line
Given a data fixture capable of complex page checking
When a page is created with 'twenty' items on a page
Then there should be 'four' lines on a page with 'five' data items on each line


Generating the Java files

The next step is to generate java from the scenario files I used an eclipse run configuration but the command line is:

java -classpath Tumbler.jar tumbler.ScenarioToJavaConverter YOUR_STORY.scenario


For the above scenario this was the result.  Note the generation of given, when and then methods and @story, @Scenario annotations that match up with the original file.

import org.junit.*;
import static org.junit.Assert.*;
import static tumbler.Tumbler.*;

@RunWith(TumblerRunner.class)
@Story("Building a simple page")
public class BuildingASimplePageScenarios {

@Scenario(pending = true)
public void shouldCreateAPage4LinesLongWith5DataItemsInEachLine() {
given("a data fixture capable of complex page checking");

when("a page is created with 'twenty' items on a page");

then("there should be 'four' lines on a page with 'five' data items on each line");
}
}


Which just leaves filling in the behavior and the actual test

@RunWith(TumblerRunner.class)
@Story("Building a simple page")
public class BuildingASimplePageScenarios {
private SimplePage page;

@Scenario(pending = false)
public void shouldCreateAPage4LinesLongWith5DataItemsInEachLine() {
given("a data fixture capable of complex page checking");
final PageDataFixture dataFixture = new PageDataFixture();

when("a page is created with 'twenty' items on a page");
page = SimplePage.newInstance(dataFixture.getDataItem(), 20);

then("there should be 'four' lines on a page with 'five' data items on each line");
Map expectedLines = dataFixture.createPageExpectation(4, 5);

Map actualMap = page.getMap();

assertThat(actualMap, is(expectedLines));
}
}

Finally there are two flags that can be applied to the test runner which turn on the production of a report. (-DgenerateReport=html -DoutputFolder=target)  It would be easy to configure a maven profile that picked up all your scenario files, and passed in these two flags.  The standard report uses Freemarker so it would be easy to produce your own.  Its a simple list of scenarios and their detail.

This is what my report looked like



Good Points

  • As per JBehave I like the attempt to draw the product owner closer to the testing and development team members.
  • Its a very simple system with very small learning curve
  • Generating the Java improves productivity and allows the product owner to work on separate artifacts


Bad Points

  • Currently its a very early beta release.  Not so much a criticism as a reminder that things might evolve in a breaking fashion at this stage.
  • I would like to see the ability to generate parameters out of the scenario files.  If not, then a way to edit the tests to introduce parameter driven testing.
  • Scrum and agile are iterative.  Adding to the original scenario files would mean generating the classes again.  This leaves the developer with the unpleasant task of transferring over changes. This might be solved if the inputs were the scenario file, and the finished test Java, with output that modifies and adds.  Running them would show the breaks if the parameters were also part of the generation.


Conclusion

I can’t wait to see a full version, or at least a release candidate version because I can see a future for this project.

References
Published at DZone with permission of Martin Harris, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Emma Watson replied on Fri, 2012/03/30 - 6:08am

I’m currently planning/working on tighter integration with maven (plugin), eclipse (plugin) and hudson (plugin). Moreover parameters in scenarios (and even something more than that) will be introduced soon.

Swing

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.