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

Tumbler Report - Scenario Detail Page

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.