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.

                          

From a scrum point of view BDD can be used to turn the definition of done into a test artifact. The team produces scenarios for each task. With JBehave a scenario file describes the required behavior and test steps it will need to pass to be considered done. I.e Given some prerequisites, perform some action and expect some results. See the JBehave project for more detail as this is only a simple example.

BDD in 4 hours?

So scenarios are just text files describing the required functionality in terms of expected behavior. Even before development though, its possible to run them and see the pending expectations. Lets wizz though a simple example showing who in a scrum team is responsible for what. I already have a project that I use to explore test patterns so I thought I would just introduce it to that.  If you want the working version just take a fork from github.

Nb. I have a data fixture used in testing a complex page component. So whilst not a pure scenario I can make its existence part of the Givens. In this project, its likely that no real given is required, but a developer would add it during the build.

First the product owner and tester produce a simple scenario file describing behavior and expectations.

Given a data fixture
When a page is created with 20 items on a page
Then expected lines on a page is 4 with data items in a line 5

Next developers write a harness and flesh out the steps required to meet the behaviour.

We need to bootstrap the scenario and add steps to it. The general idea is to have a scenario test, that then includes the steps. This is one way of bootstrapping in the steps, other ways are available including a spring system that uses SpringStepsFactory. I ran into problems with the spring system as my project uses spring 3 and JBehave is still locked into spring 2.5.6. In addition I am using junit 4.8 and spring 2.5.6 requires 4.4. This is ultimately an issue as on many projects. I would not want to tie in those older versions. In fact other ideas in my project prevent me from doing this too. So in my timebox I avoid the issue and bootstrap manually.

The Bootstrap test class

public class SimplePageScenario extends JUnitScenario {
	public SimplePageScenario() {
		super(new MostUsefulConfiguration() {
			@Override
			public ScenarioDefiner forDefiningScenarios() {
				return new ClasspathScenarioDefiner(
						new UnderscoredCamelCaseResolver(".scn"),
						new PatternScenarioParser());
                        }
                });

		addSteps(new SimplePageSteps());
        }
}

Before adding the call to addSteps()) running the scenario shows the steps that are pending.

(org/testpatterns/scenarios/example_scenario.scn)
Scenario:
Given a spring data fixture (PENDING)
When a page is created with 20 items on a page (PENDING)
Then expected lines on a page is 4 with data items in a line 5 (PENDING)

Finally the developers fill in the Steps class adding sections that match against the scenario keywords, Given, When and Then. Development is done until the behavior passes the test.

public class SimplePageSteps extends Steps {

	private SimplePage page;

	private final PageDataFixture dataFixture = new PageDataFixture();

	@Given("a data fixture")
	public void givenASpringDataFixture() {
		notNull(dataFixture);
	}

	@When("a page is created with $itemsOnAPage items on a page")
	public void createPage(int itemsOnAPage) {
		page = SimplePage.newInstance(dataFixture.getDataItem(), itemsOnAPage);
	}

	@Then("expected lines on a page is $linesOnAPage with data items in a line $itemsInALine")
	public void validatePage(int linesOnAPage, int itemsInALine) {
		Map expectedLines = dataFixture.createPageExpectation(linesOnAPage, itemsInALine);

		Map actualMap = page.getMap();

		ensureThat(actualMap, is(expectedLines));
	}

}

Good Points

• I like the potential to get key scrum members interacting. The collaboration between the testers and product owner is an important one as it should flesh out questions about behaviour at an early stage. Similar benefits occur when the development team starts to get to grip with the behavior.
• Having a simple scenario artifact means the product owner can get involved with something that actually becomes part of the continuous integration.

Bad Points

• The bootstrap is clumsy. Having to add steps means that after producing the new scenarios development have to get involved before the pending steps appear. There are other ways to bootstrap. The spring system is a step in the right direction, in fact I would like to use injection throughout the application. This still does not solve the problem of having to edit something before the steps appear. I would prefer that once the scenario is in place, steps are automatically found as they are written, and appear as not started until they are cut.
• Extending Junit Testcase is also a problem. Its highly likely that in more complex projects we would need mocking techniques or spring based tests. These have their own runners brought in with the @RunWith annotation. It would be better if there were some way to bootstrap the behaviour into any other test framework.
• In my 4 hour timebox I did not get the reporting working. Unfortunately the reporting requires more coding, and setup and is far from being just a bit of maven configuration.
• When running from maven things did not work until I configured the maven-resource-plugin to copy over the scenario files. This should have just worked out of the box.
• Most of my 4 hours was taken up with configuration which was compounded by the slim documentation.

Conclusion

Attempting a behavior driven approach using scenarios is worth doing. I could see the benefits. Not sure if JBehave is the solution for me though. Difficult to configure, and incompatibilities with other frameworks would put me off at the moment. I will find some time to have a look at easyb another java BDD system next.

                          

Sometimes JPA entity classes get hijacked.

Say for instance you have a need to pass entity classes to another system, via JAXB.  Its possible to use DTO objects for the transfer or you could just annotate the the entity classes.  In the example below, I wanted to fetch something from a database via JPA and write it into gigaspaces.  It soon gets messy your Entity classes start to become a hub in the middle of your application with things dipping into some of the classes and annotating them and throwing them here and there.

Lets look at a simple one from my example system.  This one is only used by gigaspaces and hibernate, it could get much messier than this if I chose to add one or two more technologies.  I am deliberately leaving the imports in the examples so you can see where it all came from.

import com.gigaspaces.annotation.pojo.SpaceClass;
import com.gigaspaces.annotation.pojo.SpaceId;
import com.gigaspaces.annotation.pojo.SpaceRouting;
import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.Id;
import javax.persistence.Table;
import javax.persistence.Transient;

@Entity
@Table(name = "HOUSE")
@SpaceClass
public class MessyHouse {

    private String id;
    private String name;
    private String address;
    private String pageId;

    public MessyHouse() {
    }  

    @SpaceRouting
    @Transient
    public String getPageId() {
    return pageId;
    }

    public void setPageId(String pageId) {
    this.pageId = pageId;
    }

    @Id
    @GeneratedValue
    @Column(name = "HOUSE_ID")
    @SpaceId(autoGenerate = false)
    public String getId() {
    return id;
    }

    public void setId(String id) {
    this.id = id;
    }

    public String getAddress() {
    return address;
    }

    public void setAddress(String address) {
    this.address = address;
    }

    public String getName() {
    return name;
    }

    public void setName(String name) {
    this.name = name;
    }
}

Some things I dislike about what I have done here

• See the block I have marked below SpaceRouting.  In this class I wanted to change the Gigaspace routing strategy, so I have a method that has nothing to do with the persistence.  Does adding annotations break the “A class should have only one responsibility” design goal?  No perhaps not, but adding a whole method that is a Gigaspace concern does.
• As you add more and more annotations from different technologies things get messy very quickly.
• I have a JPA based DAO that uses this class.  I also have a set of gigaspace processing units that use this class.  Both systems are impinging their own design requirements on the class.  At the moment they are deceptively similar.  Gigaspace insists upon a default constructor, and getters and setters for all fields you wish to persist.  Hibernate is not quite as strict.  What if Gigaspaces relaxes that rule later and allows you to annotate the fields instead?  Or perhaps added some other design restriction.  Its unclear by looking at the class what things are there for hibernates soft contract and what gigaspace is insisting upon.
• If my gigaspace experiment gets big (not that likely!).  I might want to split off the gigaspace into its own project and use it as a component.  Ah! so what about the MessyHouse class then?  Where should that live?  Indeed its going to be in the wrong project wherever I decide to keep it.

This is one solution that I put to you.  Create a class for the gigaspace fields, and compose a House class into it.  With composition we can neatly separate the concerns.  Well almost.  Gigaspace may store these objects and need to restore them at some point.  I believe to do that it creates House, and populates it.  Then it creates GsHouseWrapper and injects House into it.  To do that you need a setter for the house but at least we have a class with Gigaspace design constraints and another with Hibernate peculiarities.  Check out the classes below and let me know what you make of the design.  Are there alternatives?

Also, currently there is a problem with the design below. The delegation methods fail with an exception. i.e house.setId(id); fails when writing the object to the space. I need to submit a ticket with the Gigaspace crew to figure out why.

The refactored classes.

package javapuzzlers.compose;

import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.Id;
import javax.persistence.Table;

@Entity
@Table(name = "HOUSE")
public class House {

    private String id;
    private String name;
    private String address;

    public House() {
    }

    @Id
    @GeneratedValue
    @Column(name = "HOUSE_ID")
    public String getId() {
        return id;
    }

    public void setId(String id) {
        this.id = id;
    }

    public String getAddress() {
        return address;
    }

    public void setAddress(String address) {
        this.address = address;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }
}

package javapuzzlers.compose;

import com.gigaspaces.annotation.pojo.SpaceClass;
import com.gigaspaces.annotation.pojo.SpaceId;
import com.gigaspaces.annotation.pojo.SpaceRouting;

@SpaceClass
public class GsHouseWrapper {

    private House house;
    private String pageId;

    public GsHouseWrapper() {
    }

    public GsHouseWrapper(House house) {
      this.house = house;
    }

    @SpaceId(autoGenerate = false)
    public String getId() {
        return house.getId();
    }

    public void setId(String id) {
        house.setId(id);
    }

    @SpaceRouting
    public String getPageId() {
        return pageId;
    }

    public void setPageId(String pageId) {
        this.pageId = pageId;
    }

    public GsHouseWrapper(House house) {
        this.house = house;
    }

    public String getName() {
        return house.getName();
    }

    public String getAddress() {
        return house.getAddress();
    }
}

                          

Release Announcement: 13/11/2009

5 cool things available in Spring 3.0

1. Java 5 fully used throughout the whole API. In 2.5 the core is still Java 1.4 compatible, 3.0 is written in and requires Java 5.0. This means much greater use of generics. Unrelated but they have also included many performance enhancements.
2. SpEL. Spring Expression Language gives access to nested bean definitions and system properties via #{…} syntax in property values. These dynamic #{…} expressions and static ${…} placeholders can also be used to inject property settings via the @Value annotation. This should much simplify property setting.
3. Comprehensive REST support. Spring 2.5 MVC is an excellent pattern. The simplicity of annotated controllers results in very clean implementations. 3.0 takes this system further by building in Restful support and a RestTemplate for clientside REST.
4. Spring 3.0 UI Field Formatting. Springs formatting system has always been useful in web and desktop applications. Its an effective way to remove a lot of boilerplate code from a system. This new system of annotations allows common formats to be applied to classes, model properties and methods. Check it out its very cool.
5. Many enhancements migrating to java.util.concurrent including ThreadPoolExecutorFactoryBean which exposes the native ExecutorService interface. The concurrent package is very good indeed, so bringing more support into spring is just fantastic.

Of the 5 mentioned here its only the tip of the iceberg as regards new features. This release is very rich. As usual with spring its when you have something to solve that you really appreciate it.

                          

I used Spring STS for a few months before starting at Lab49, and found it to be a good distribution over the standard Eclipse build. It has lots of extra productivity features for Spring based development some of which are not available by downloading Spring plugins and adding them to a normal distribution.
The things I like best are:

• The edit, navigation and search systems now support the spring annotations. So now you can navigate and search for beans declared via annotations.
• Ability to include new XML domains in the spring configuration from a popup list.
• The enhanced XML editing support now has inline error checking.
• This XML editor also supports completion and checking of class and bean names.
• Roo shell looks interesting too.

Roo and Roo Shell
The Roo system looks great. Its a system to generate and support a JEE system. The roo shell can be used to configure JEE components. You can have a basic website up in seconds. Like Groovy and Grails you get spring standards built in, and your not dependent on the Roo system once your finished.

I am going to take a proper look at it at some point.

                          

Release Announcement: 19/11/2007

I don’t want to review all the improvements that were made, but thought it would be interesting to pick a favorite feature and explain why for me its the best feature. Perhaps some of the few remaining projects out there will move up and start taking advantage of this fantastic framework. After all, with the release notice for 3.0 RC1 back in September soon there will be reasons to upgrade again!

I have seen a few of these upgrades through now, and so far they have all been straightforward. The work is not in the upgrade, its in the work to use the features. This can be done over time to reduce the impact. The last one I did for instance was mainly re-factors to use generics which is never a bad idea, and conversion of tests to use the new annotation based Junit 4 framework.

So, my top 5 candidates for Favorite Upgrade Feature.

1. Takes advantage of new language features in Java 5 and 6. This includes adherence to JDBC 4.0, JTA 1.1, JavaMail 1.4 and JAX-WS 2.0. The addition of Generics in the high level API is a particular boon. The core is still compatible with Java 1.4, but the addition of Generics in the higher level API’s means you can take full advantage of generics in most of the important areas. If your already on Java 5 you can get rid of masses of warnings, or all those dangerous suppressions. The code gets cleaner and more of your casts will be checked upfront. For me this is a huge development productivity enhancement.
2. Greater use of annotations in configuration. This is particularly useful for wiring of web services and the MVC controller. The new @Qualifier annotation is essential when Auto-wiring beans and needing to choose from multiple beans of the same type. Not such a massive deal for me, as I like the way that xml provides a map of the application. Well if its well structured it does. There are some places that annotations are excellent though and the MVC layer is just that, as it allows you to see exactly what a controller is doing. What it responds to, and how it redirects. The new way to implement the get, post, redirect pattern is awesome more detail in the MVC API Documentation.
3. Better JDBC Support including better handling of errors and the new SimpleJDBCTemplate. Oh! and the addition of named parameter support is very handy indeed.
4. New annotation based support the Junit and Nunit integration testing. This includes new classes for spring integration testing, and removes the need to extend from the TestCase framework. The net result of this is greater test flexibility, easier configuration and the ability to easily inject fixture dependency and share test support utilities.
5. Increased performance. Not sure what the specific changes are but I quote from their website: We recommend upgrading to Spring 2.5 from all previous Spring 2.0.x versions in order to benefit from the new features as well as the significant performance enhancements that Spring 2.5 has to offer.

For me the winner is point 1, Java 5 language features, but it was a hard decision. I have seen an incomprehensible test framework re-factored into something manageable. It was made possible by point 4. The simplicity these two features bring to the code should be argument enough to begin your upgrade in the next iteration. Go for it!