# unitils.properties

# Assign the SpringDataSourceFactory DataSource.
org.unitils.database.config.DataSourceFactory.implClassName= com.tek.design.unitils.SpringDataSourceFactory

Write your SpringDataSourceFactory and implement both DataSourceFactory and springs ApplicationContextAware interfaces. Then in the init method you will be able to fetch your spring DataSource bean from the application context using a service look up. Not ideal, but until future releases it will do just fine.

package com.tek.design.unitils;

import java.util.Properties;
import javax.sql.DataSource;

import org.springframework.beans.BeansException;
import org.springframework.context.ApplicationContext;
import org.springframework.context.ApplicationContextAware;
import org.unitils.database.config.DataSourceFactory;

/**
 *
 * Unitil's provides a way to override the default DataSourceFactory.  This class provides facility to
 * spring wire in the same datasource used by your ORM by fetching it from the ApplicationContext.
 *
 * Use the org.unitils.database.config.DataSourceFactory.implClassName property to supply this factory to unitils.
 *
 */
public class SpringDataSourceFactory implements DataSourceFactory, ApplicationContextAware {

    private static ApplicationContext appContext;

    private DataSource dataSource;

    @Override
    public DataSource createDataSource() {
        return this.dataSource;
    }

    @Override
    public void init(Properties arg0) {

        if (null == this.dataSource) {
            String dataSourceBeanName = "TekDesignDataSource";
            this.dataSource = (DataSource) appContext.getBean(dataSourceBeanName);
            if (this.dataSource == null) {
                throw new SpringBeanLookupException(DataSource.class, "Cant find bean named " + dataSourceName);
            }
        }

    }

    @Override
    public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
        appContext = applicationContext;

    }

}

Full unitils properties file:

# unitils.properties

# Provide a CSV of all used database schemas. ie schema1,schema2.
# The first schema name is the default one.
# If no schema name is specified in a dbunit data set the default one is used.
#
# A schema names are case sensitive when surrounded by database identifier quotes (e.g. “” for oracle)
#
# Example unitils description using a schema
#
#<dataset xmlns:frt=”FRUIT”>
#   <frt:APPLE NAME=”COX”
#                           DESCRIPTION=”[null]” />
#</dataset>
#
database.schemaNames=fruit,veg

# This property specifies the underlying DBMS implementation. Supported values are ‘oracle’, ‘db2′, ‘mysql’, ‘hsqldb’,
# ‘postgresql’, ‘derby’ and ‘mssql’. The value of this property defines which vendor specific implementations of
# DbSupport and ConstraintsDisabler are chosen.
database.dialect=oracle

# The dao tests often share the same data in the setup files, so its important to
# rollback between tests otherwise constraints will be violated.
DatabaseModule.Transactional.value.default=rollback

# Assign the SpringDataSourceFactory DataSource.
org.unitils.database.config.DataSourceFactory.implClassName=
com.tek.design.unitils.SpringDataSourceFactory

                          

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.

                          

One way to test a DAO method is to provide a data fixture written in java. This will provide a populated in memory database and immutable objects that contain the data inserted.  The immutable objects can then be used later for making assertions against the data returned from the DAO method under test.  This describes a similar pattern: Unit Test with in memory Db.  I wrote a more modern version using the EntityManager instead of Jdbc and SpringTests with Junit 4 but the principle is the same.

There are some rules for my data fixture:

• The data must not be inserted using the DAO as this means your relying on the DAO under test.  I used the entity manager providing direct insert statements and just executed the sql.
• The data inserted must be driven from some immutable holder objects that encapsulate that data.  This provides a robust test and some handy containers that are used later in the test.  This also means that the test has no need whatsoever to know anything about the data!  It just needs to make assertions that the data holders contain the same data as the model returned from the dao.
• Assert that default values are not used.  I have seen bugs because ’0′ was used as data in long type identifiers, then it turns out the code never set the variable.  My data holders validate their invariants.
• The fixture should be responsible for stringing together primary and foreign keys, avoiding problems with uniqueness etc.  I.e the fixture is aware of the database requirements.
• The fixture should allow for several generations of itself to be created.  Thus from the test, several rows of data and the associated graph can be created to provide a rich enough set.  Rich enough to provide good data coverage without being complex or slow.
• Finally labels, names and other data should be identifiable, this makes it easier to debug if required.

So with careful thought, use of the builder pattern for the main fixture, immutable object design and a hierarchy of data and object creation I arrive at the finished product.  The design is strong, the test works and it satisfies the above requirements, but I am not happy.

It took too long to hand craft all this code.  The fixture is big although easy to understand.  There has to be a better way.  So I look for an alternative.  What I want is something that provides the above as far as possible but lighter.  I envisaged, something where the data is configurable and you don’t have to write the complex fixture at all.

Unitils a possible shortcut

Quoting from the Unitils site: Unit tests for the database layer can be extremely valuable when building enterprise applications, but are often abandoned because of their complexity.
How true that is!

So my search took me through the links at the bottom of the page, until I hit upon Unitils: http://unitils.org/cookbook.html.  Instead of writing a complex fixture to encapsulate the data safely you write XML that describes the data needed for a given test.  This is associated with the class or method using a naming strategy, although this can be overridden by specifying files.  This could be handy if one dataset fits several test classes.  This is already easier than writing actual insert statements and can be achieved easily with the database schema browser and a text editor.  I am not interested in the mocking or database setup described there, whilst useful I had solved most of those issues with spring.  In fact unitils uses spring under the hood, so is probably using the same facilities I do in my work.  Unitils provides some powerful aid with the assertions in the test too, take a look at this!

ReflectionAssert

The reflection assert class provides a toolkit that addresses the kind of problems you often run into when making assertions against the data a DAO returns.  For instance lets say you have a model object with a primary key value.  This field is often hidden from you, and may not be used in the equals method.  In fact the equals methods on model objects are not always implemented or have some business specific implementation, so you can’t rely on them in the tests.  My solution was to use my own holder objects for data, and then to write my own validation routines against the model object.  Time consuming!

Take a look at these examples taken directly from the tutorial, (thanks guys!)

import static org.unitils.reflectionassert.ReflectionAssert.*;

// Exact field-by-field comparison
assertReflectionEquals(
  new Person("John", "Doe", new Address("New street", 5, "Brussels")),
  new Person("John", "Doe", new Address("New street", 5, "Brussels"));

// Ignore Null / 0 values in the expected object
assertReflectionEquals(
  new Person("John", null, new Address("New street", 0, null)),
  new Person("John", "Doe", new Address("New street", 5, "Brussels"),
ReflectionComparatorMode.IGNORE_DEFAULTS); 

// Ignore collection order
assertReflectionEquals(
Arrays.asList(
  new Person("John"), new Person("Jane")),
  new Person[] {new Person("Jane"), new Person("John")},
ReflectionComparatorMode.LENIENT_ORDER);

// Ignore null/0 values + collection order
assertLenientEquals(
  Arrays.asList(
  new Person("John"), null),
  new Person[] {new Person("Jane", "Doe"), new Person("John", "Doe")});

// Check only the firstName property
assertPropertyLenientEquals("firstName", Arrays.asList("John", "Jane"),
  new Person[] {new Person("Jane", "Doe"), new Person("John", "Doe")});

Comments on the assertion example

• Note the way its possible to ignore null and defaults like ’0′ and certain fields.  This should mean I can use constructors on my model and not have to worry about keys.  These are tested because you get data back in the child tables anyway.
• Note the system for ignoring order.  I use google multiset but this is even simpler than that.

General Problems that might still arise

I am not sure if my model is always going to be so accommodating.  I hope that visibility of appropriate constructors will allow the assertions I want to make via reflection.  I guess there is little impact in adding more for testing, but my design meant I did not have to worry about it because my assertions are made against an object provided by the fixture.  In fact the design of this object was to facilitate creation without complex constructors.  A constraint the model does not have to worry about.  i.e Only the DAO needs to create a model object  This also had the advantage of reducing the failure to one point, the DAO.  In the system above, you type data into the XML and into the test, so its possible to miss the match and the test will fail.

It will be interesting to see if its possible to work with nested objects and complex graphs. JPA or currently Hibernate is knitting things together so it may not be possible to create the objects required.  Its going to take a bit longer to finish this off, so I will explore further and post up my finished result later on.

If I had a request it would be for this framework to load a model object off the xml defining the data, and have an assertions like this:

public void validateModelLoadedFromTestDataAgainstReturnedModel(T y)

This would close the loop would it not?

Links

http://www.dallaway.com/acad/dbunit.html

http://www.theserverside.com/tt/articles/article.tss?l=UnitTesting

http://unitils.org/tutorial.html#Testing_with_JPA

                          

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.

                          

1. 21:45 Open Eclipse.
2. 21:49 Updates downloaded and maven re-indexed.
3. 21:53 Start tutorial, lots of downloads from maven after project creation.
4. 21:55 Restart eclipse to enable the runtime weaving, STS does not return…restarted it from the prompt, deleted the project and started again as it looked incomplete.
5. 22:00 Bumbling through the tutorial.  This is very easy, love the CTRL^space completion.  I have done quite a bit of Linux work, and this shell is very easy to use.
6. 22:14 Running the tests using roo> perform test. This runs maven, which fails because it cant find the integration test class, RsvpIntegrationTest.  Investigation from the bash prompt reveals that all tests pass under maven, so its not an issue with the project roo has created.  More download and fiddling about.  The test runs from eclipse too, so I move on.
7. 22:38 Website up! Selenium tests all pass.  Investigation of the functionality shows that its working!  Done in 53 mins not bad I think!

Roo Up and Running!

Conclusion

Yea easy, a quick look over the project shows its very neat and tidy. Most of the time was spent in download and the false start. The configuration easy to follow and the generated code would be easy to use. So yes, might have a proper look at Roo at some point!

                          

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.

                          

Have a read over the class, and then move on to read the steps to re-factor to better patterns. I have several designs here that focus on the setup stage of a test. As your tests get more complex you will find the patterns here support ever increasing complexity. In an Agile project you might move from one system to the next as the requirements ramp up. Then once you see where I am heading, I lay down a challenge.

Test anti-patterns project, contributors wanted!

If you have a Test Anti-Pattern that you would like to showcase. Check out my code from gitHub, add the new example and examples of how to re-factor the code. Blog it to your own blog with a reference to this page, or drop a comment. If we get enough I will setup a page with an index to all the blogs.

The code can be forked out with git from gitHub http://github.com/mhgit/TerribleJavaTestingMadeGood. It should be an easy start. Its a full maven project with a small dependency set and maven site reports already built in for test coverage. Its fully open source with the Apache 2.0 license. Once you have your new example, tell me about it by adding a comment to this page, and following the git forking instructions for making a git pull available.

I hope I never see another badly written test like this:

…but unfortunately I probably will…

package org.testpatterns.dupcodeexample.lineutil.unit;

  import org.testpatterns.dupcodeexample.lineutil.SimplePage;
  import java.util.HashMap;
  import java.util.Map;
  import java.util.Set;
  import org.junit.Test;
  import static org.junit.Assert.*;

  /**
  * Terrible Test SimplePage Function.
  *
  * @author martinh
  */
  public class TerribleSimplePageTest {

    @Test
    public void testPageAssembley() {

        String item = "-23456789-";

        Map<Integer, String> expectedLines = new HashMap<Integer, String>();

        expectedLines.put(1, item + item + item + item + item);
        expectedLines.put(2, item + item + item + item + item);
        expectedLines.put(3, item + item + item + item + item);
        expectedLines.put(4, item + item + item + item + item);

        SimplePage page = SimplePage.newInstance(item, 20);
        Map<Integer, String> actualMap = page.getMap();

        assertEquals(expectedLines, actualMap);

    }

    @Test
    public void testPageKeySet() {

        String item = "-23456789-";

        Map<Integer, String> expectedLines = new HashMap<Integer, String>();

        expectedLines.put(1, item + item + item + item + item);
        expectedLines.put(2, item + item + item + item + item);
        expectedLines.put(3, item + item + item + item + item);
        expectedLines.put(4, item + item + item + item + item);

        SimplePage page = SimplePage.newInstance(item, 20);
        Set<Integer> actualKeySet = page.getKeySet();

        assertEquals(expectedLines.keySet(), actualKeySet);

    }

    @Test
    public void testAddLines() {

        String item = "-23456789-";

        SimplePage page = SimplePage.newInstance(item, 20);

        Map<Integer, String> additionalLines = new HashMap<Integer, String>();

        additionalLines.put(1, item + item + item + item + item);
        additionalLines.put(2, item + item + item + item + item);
        additionalLines.put(3, item + item + item + item + item);
        additionalLines.put(4, item + item + item + item + item);

        page.appendLines(item, 20);

        Map<Integer, String> actualMap = page.getMap();

        Map<Integer, String> expectedLines = new HashMap<Integer, String>();

        expectedLines.put(1, item + item + item + item + item);
        expectedLines.put(2, item + item + item + item + item);
        expectedLines.put(3, item + item + item + item + item);
        expectedLines.put(4, item + item + item + item + item);
        expectedLines.put(5, item + item + item + item + item);
        expectedLines.put(6, item + item + item + item + item);
        expectedLines.put(7, item + item + item + item + item);
        expectedLines.put(8, item + item + item + item + item);
        assertEquals(expectedLines, actualMap);

    }
}

Fixture as a normal method: ImprovedSimplePageTest

I am not going to post up code for all the classes. Check it out from gitHub for that. So I just highlight the main steps and show the final full class.

The basis of the first pattern is simple. Most small tests like this just need one method for setup, this eliminates all the cut and paste. This might be run from an @Before, or @BeforeClass annotation, as part of the constructor or perhaps just from the test itself. These techniques will have to be applied depending on what you need to achieve. For instance if your setup is inserting into a database, you have to make sure your data does not violate db constraints. So the annotations might not help, plus you have the added complexity of getting hold of your database. A good pattern is to use an in memory db, but some of the annotations will cause the setup to get run before each test. So in a nutshell attempt to have one setup, and its not that important which system you use to run it, that will depend on what your doing.

Refactoring steps:

• Rename methods.

Have a good strategy for your test names if they are good enough you will not need to comment the methods. The pattern I use here is: [What is being tested]_[What is expected]. If you can’t fit it all into the name, the test is probably too big and needs breaking down. A test should be concise.

• Remove duplication.
There were two steps to this:
1. I Added this method: createLineExpectations to create expectations.

This allowed me to remove all the duplicated test setup that had been cut and pasted all through the class. I wrote this bad test, using TDD to come up with the supporting implementation, so even as I wrote it the test went through several iterations. During that process I left a chunk of unused map behind. Which just goes to prove that if your test is messy, its difficult to spot problems.
An unused chunk of code that hid in the duplications

  Map<Integer, String> additionalLines = new HashMap<Integer, String>();

  additionalLines.put(1, item + item + item + item + item);
  additionalLines.put(2, item + item + item + item + item);
  additionalLines.put(3, item + item + item + item + item);
  additionalLines.put(4, item + item + item + item + item);

2. Added constants and moved all the hard coded value out.

Collecting setup into an inner fixture class: LocalFixtureBasedPageTest

Its not long before the technique starts to breakdown. As you add more supporting methods it gets harder to see what is test, and what is setup. So the next stage is to move the setup into an inner class. This way, most ide’s will allow you to collapse the fixture hiding it away. When I read a test, I am mostly interested in the expectations, not the setup. Note that the constants have been moved into the fixture. So the fixture becomes an inner class that supplies everything to do with setup for the test.

    private class DataFixture {

        private final String ITEM = "-23456789-";
        private final int LINES_8 = 8;
        private final int LINES_4 = 4;

        Map<Integer, String> createLineExpectations(String item,
                int numLinesToCreate) {
            Map<Integer, String> expectedLines = Maps.newHashMap();

            StringBuilder sb = new StringBuilder();
            sb.append(item).append(item).append(item).append(item).append(item);
            String line = sb.toString();
            for (int i = 0; i < numLinesToCreate; i++) {
                    expectedLines.put(i + 1, line);
            }

            return expectedLines;
        }
    }

Fixture as a spring injected component: SpringWiredSimplePageTest

When a test gets more complex you sometimes end up with masses of complexity building up in inner classes. I sometimes use inner classes to build complex data requirements using the setter method chaining pattern for instance. Each inner class becoming a container for parameterized setup. The next level of complexity is needing to share the setup over many test classes.

These are your options.

1. Create a static helper class

Not a bad solution, but I hate having to access the methods via the class name. Static classes often collect unrelated methods too. Also, its often not possible to work with the restriction of being static.

2. Abstractions and class hierarchy.

This is often posed as a solution when you need to share the setup over many classes. In this case its a terrible solution. The abstraction gets further complicated because your using the wrong OO mechanism. It also means your test has to extend a class, in some situations, you are already extending to get at the internals of the object under test.

3. Use method injection to supply a fixture component.

If you break the fixture out to a component its easier to manage the complexity of the fixture away from the test with composition. You can have many components each doing something specific for a set of tests. You could even inject more than one component. The design of the fixture can use other OO patterns to keep it neat. For instance I once built a set of fixtures to supply ready made folder and file structures. They all extended an abstract and implemented an interface. The @Qualifier annotation was used to inject the correct implementation into the test. On occasion a test used two of the component implementations.

Refactoring steps:

• Move the Fixture inner class to its own component class. If you get many of these its worth putting them in a separate project.
• Add the @Component annotation from the spring project.
• Change the type giving a more descriptive name.
• Make the methods in the fixture public.
• Better names for methods and types now that the fixture is not near the code that uses it.
• Java doc for important methods.
• Addition of getters for fields instead of direct access.
• Improved createLineExpectations(int numLinesToCreate) by removing the dataItem, the fixture knows this data so no need to supply via method.
• Convert to spring test. This means its possible to load in the spring configuration and autowire the test

The test class markup to convert it into a spring test, and provide amongst other things auto wiring:

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations = "classpath:springAppConfig.xml")
@TestExecutionListeners({DependencyInjectionTestExecutionListener.class})
public class SpringWiredSimplePageTest {

Autowire the fixture, and spring will inject it:

@Autowired
    private PageDataFixture dataFixture;

Your test setup is then just called like this:

Map<Integer, String> expectedLines = dataFixture.createPageExpectation(NUMBER_LINES_ON_PAGE_4, NUMBER_DATA_ITEMS_IN_LINE_5);

Conclusions

Once you have a test that gives 100% coverage, there is usually some more time that needs to be spent on cleaning the code. There are some easy patterns that can help, there is nothing in this article that is complex or difficult to understand so there is no excuse for leaving it messy. Bugs hide in messy code and I think you would agree, the final result is very easy to read:SpringWiredSimplePageTest

Thanks to…

All the people I have worked with over the years, who have shown me better ways to write and test code. You know who you are. Many thanks.

                          

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!

                          

The spring integration project embodies principles found in the Spring Framework and Enterprise Integration Patterns (Hohpe and Woolf, 2003). The book and project are worth a look for anyone working in that space.

• Spring Integration Project
• Spring Integration in Action, Manning Early Access Program