Sometime back now they added the support for TestListener which solves this issue.

Unitils – TestListerer API

I don’t work with conventional databases much now, but was intrigued to see this post explaining how to extend unitils and use TestListeners to test ldap.  Neat eh!

Extending Unitils to test LDap.

                          

The test needs to perform a check that the result of transforming some xml is correct.  A reference file is available so we can use XMLUnit to perform a difference.  In my file there is a seconds attribute and because seconds vary with each parse we choose to ignore the value.  There are other ways to achieve this, but its more complex and uses more XMLUnit code. Using a google predicate simplifies this check.

First produce your output file and load the sample and output into strings. Normally for a test I produce a smaller sample xml file. Then using XMLUnit difference engine get all differences.

    Diff d = new Diff(expectedAsString, outputAsString);
    DetailedDiff dd = new DetailedDiff(d);
    List listOfDifferences = dd.getAllDifferences();

Next call a function to check that the only differences found are within the seconds attribute. This uses a predicates from google to perform the matching.

    assertTrue(onlyDiffsMatchThisAttributeName("seconds",listOfDifferences));
    }

    private static boolean onlyDiffsMatchThisAttributeName(final String attrName, Iterable it) {

    Iterable filtered = Iterables.filter(it, new Predicate() {

        @Override
        public boolean apply(Difference input) {

                final NodeDetail testNodeDetail = input.getTestNodeDetail();
                if (nodeDetail == null) return false;

                final Node node = nodeDetail.getNode();
                if (node == null) return false;

                final String nodeName = node.getNodeName();
                if (nodeName == null) return false;

                return !nodeName.equals(attrName);
            }
        });
        return (newArrayList(filtered).isEmpty());
    }

Note that what is happening here is the predicate is filtering away all the seconds matches. If anything remains in the list false is returned. Neat huh!

                          

# 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

                          

He also mentioned using the admin api to do full end to end integration testing.  The admin api has huge potential as its able to control gigaspace containers, deploy into them and collect statistics.  Its a powerful api.

This is documented on their site: http://www.gigaspaces.com/wiki/display/XAP7/Administration+and+Monitoring+API

Example unit test using GigaSpaceFactoryBean

The GigaSpaceFactoryBean does have javadoc: http://www.gigaspaces.com/docs/JavaDoc7.1/index.html. It can be used to provide a unit test with a gigaspace implementation for the duration of the test.

Step 1 Provide a spring definition of the GigaSpaceFactoryBean

<beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:context="http://www.springframework.org/schema/context"
xmlns:os-core="http://www.openspaces.org/schema/core"
xmlns:os-events="http://www.openspaces.org/schema/events"
xmlns:os-remoting="http://www.openspaces.org/schema/remoting"
xmlns:os-sla="http://www.openspaces.org/schema/sla"
xmlns:util="http://www.springframework.org/schema/util"
xsi:schemaLocation="
http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd
http://www.springframework.org/schema/util http://www.springframework.org/schema/util/spring-util-2.5.xsd
http://www.openspaces.org/schema/core http://www.openspaces.org/schema/core/openspaces-core.xsd
http://www.openspaces.org/schema/events http://www.openspaces.org/schema/events/openspaces-events.xsd
http://www.openspaces.org/schema/remoting http://www.openspaces.org/schema/remoting/openspaces-remoting.xsd
http://www.openspaces.org/schema/sla http://www.openspaces.org/schema/sla/openspaces-sla.xsd">

<os-core:local-tx-manager id="gs.transactionManager" space="testGigaSpace" default-timeout="1000" />
<os-core:space id="testGigaSpace" url="/./my-test-pu" />

<bean id="gigaSpace">
<property name="space" ref="testGigaSpace" />
<property name="transactionManager" ref="gs.transactionManager" />
</bean>

Follow with other beans needed by the test. I.e service beans and their dependencies.  Note that the space defined here will also need to be injected into services that need it.  So you will need to use the same bean id.  Careful separation of the spring files means you will be able to substitute a test space for the real one during testing.

Step 2 Write a unit test

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations = "classpath:/somewhere/sometest-pu.xml")
public class SomeGigaspaceTest {

    @Resource
	private ServiceUnderTest myservice;

    @Resource
    private GigaSpace gigaSpace;

    @Before
    public void setUp() {

        // Setup anything you may wish to be
        // in the space before the test starts.
        this.gigaSpace.write(stuff);

    }

    @Test
    public void testSomething() throws InterruptedException {

        ImmutableSet dataFromGS = this.myservice.getStuff();
        assertFalse(dataFromGS.isEmpty());
        assertThat(dataFromGS.size(), is(100));

    }

                          

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.

                          

I find hamcrest to be a much cleaner way of writing assertions.  This test demonstrates the use of its fluid interface with some simple collection assertions.  There are newer versions of Hamcrest and the collection package may have moved into core, but the version I use here (1.0) was available on maven.  Note the integration with Junit.  The hasItem and hasItems methods are sourced from Junit 4.8.1.

package org.testpatterns.hamcrestexamples;

import java.util.Arrays;
import org.junit.Test;
import static org.hamcrest.collection.IsArrayContaining.hasItemInArray;
import static org.junit.matchers.JUnitMatchers.*;
import static org.junit.Assert.assertThat;

public class CollectionExamples {

  //Hamcrest with Collections and Arrays:
  static final String[] array = { "A", "B", "C" };
  static final List<String> list = Arrays.asList(array);

  @Test
  public void oneThingInArray () {
    assertThat(array, hasItemInArray("A"));
  }

  @Test
  public void arrayOfItemsInList () {
  String[] expected = { "A", "B", "C" };
    assertThat(list, hasItems(expected));
  }

  @Test
  public void itemInAList () {
    assertThat(list, hasItem("A"));
  }

  @Test
  public void itemsInAList () {
    assertThat(list, hasItems("A", "C"));
  }

}

                          

for(String name: names.keySet()) {
    mymap.put(mymap.get(name),name);
}

Its inefficient because you have to fetch the keys and perform a lookup in the map with the key.

Instead using the EntrySet you can get all the keys and values in one hit. This saves having to perform the map lookup.

for (Entry<String, String> entry : entrySet) {
    mymap.put(entry.getValue(),entry.getKey());
}

                          

Be careful to check that your objects are consistent with equals though.  I have mentioned this before.

In the following method I am using the Objects.equal with a BigDecimal class.  It does not work because BigDecimal equals treats 0 and 0.0 as not equal, which is probably not what you need.

public boolean equals(Object obj) {
    if (obj == null) {
      return false;
    }
    if (getClass() != obj.getClass()) {
      return false;
    }

    final TestEquals other = (TestEquals) obj;

    return Objects.equal(this.bigDecimal, other);
}

The common solution is to use the compareTo method instead like so.

  final TestEquals other = (TestEquals) obj;
  if (this.bigDecimal != other.bigDecimal &&
      (this.bigDecimal == null
      || this.bigDecimal.compareTo(other.bigDecimal) != 0)) {
    return false;
  }
  return true;

I will be using this technique, especially where the object has many attributes but I will be testing the equals method.