RSS Feed Subscribe to RSS Feed


Software Quality via Unit Testing

The following post is based on a talk I gave at Desert Code Camp 2013. See also the associated slide deck.

Software quality is critical to consistently and continually delivering new features to our users. This articles covers the importance of software quality and how to deliver it via unit testing, Test Driven Development and clean code in general.
Read more

Tags: , , , , , , , , , ,

Spring MVC Hello World with Continuous Deployment

Oh dear, yet another ‘Hello World!’. But although the functionality is trivial, this little SpringMVC project is complete enough for me to use as a template to bootstrap more complex projects. It consists of:

  • HTML/JSP client
  • SpringMVC server using a Controller/Service/DAO design
  • Maven for build and dependency management

This is an updated version of an older project I created, with the following enhancements:

  • Added a full suite of automated tests (unit, integration and browser based)
  • Added placeholders for JavaScript and images (both can be a little tricky to put in the correct place with SpringMVC)
  • Incorporated into a continuous deployment environment

More details below, but you can find the full source code on this GitHub repository

(Previously I had the code deployed on a CloudBees instance at, but CloudBees have since unfortunately shut down their free tier).

Read more

Tags: , , , , , , , , , , ,

Add log4j logging for a unit test in IntelliJ

In IntelliJ

  • Click: Run -> Edit Configuration
  • Select your test configuration (or add a new one)
  • In VM parameters, add
    (Or wherever your log4j properties file is)

That’s it. The test should now run with log4j logging (although obviously you need to have the necessary log4j jars available).
This example uses a windows file format, but will work equally well with *nix.

I use this approach for turning on MyBatis logging for individual tests. See here for a basic setup of a log4j.xml file to enable logging with MyBatis.

Tags: , , , ,


EasyMock is an open source library for creating, and defining the behavior of, mock objects as part of your unit tests. This article describes how to use EasyMock (v3.0), including its record/playback approach, after setting the context with an brief introduction to unit testing in general and the associated need for mock objects.
Read more

Tags: , ,

Hamcrest Matcher

As a follow up to the Hamcrest post I made yesterday, I wanted to post an example of my own Hamcrest matcher implementation. This matcher tests if a string contains a specified number of substrings.
An example usage could be:

    String sql = "select a,b,c from tableA";
    assertThat(sql, hasNumberOfSubstrings(",", 2));

See the source code below. I have been reading up on OSS licenses recently and decided to release this using the same license as Hamcrest – the new BSD license.

I have also attached a jar which includes the associated unit tests, although you will need the hamcrest-unit-test project to compile, which can be downloaded as part of the hamcrest all-in-one jar.
Read more

Tags: , , ,


Hamcrest is a framework for writing matcher objects. Matchers have a variety of uses, but are particularly useful when writing unit tests. Instead of using JUnit’s assertEquals methods, we use Hamcrest’s assertThat construct with one (or more) of the many Matchers available. For example



    assertThat(a, equalTo(b));

A small change in this example, but Hamcrest’s benefits are many, enabling you to write much more flexible tests that are easier to read and have more meaningful failure messages.
Read more

Tags: , ,

OSCON Day1: Test Driven Database Development

The first tutorial at OSCON was on Test Driven Database Development. The idea was to use pgTAP to write unit tests to check database correctness, including table structures, views and stored procedures. As a fan of Test Driven Development (TDD) for regular code, the concept of using it on the database tier makes a lot of sense.

Unfortunately I had a lot of problems getting the required software setup working, which included PostgreSQL, pgTAP, Test::Harness, make and perl. Ultimately I wasn’t able to get the examples running due to imcompatabilities between PostgreSQL and pgTAP on my Macbook Pro (OS X 10.5.8) and ended with this error:

dyld: Library not loaded: /usr/local/lib/libxml2.2.dylib
Referenced from: /Library/PostgreSQL/8.4/lib/postgresql/pgxs/src/makefiles/../../src/test/regress/pg_regress
Reason: Incompatible library version: pg_regress requires version 10.0.0 or later, but libxml2.2.dylib provides version 9.0.0

I considered trying to upgrade libxml, but there were suggestions that this could cause my machine to not boot! I even considered upgrading to OS X 10.6 (Snow Leopard), but decided that this was a little too close to shaving yaks.

I would really like to get more familiar with pgTAP at some point, but I will have to put on hold for now…

Update: I managed to get some input from David Wheeler, worked through the technical issues and got all the tests running. Thanks David! Despite the earlier setup problems, I came away with a very positive feeling about TDDD and pgTAP and can see it playing a part in any future database schema development I do.

Tags: , , , ,

Selenium talk at SF JUG

I attended another great San Francisco JUG meeting tonight, this time on How to use Selenium with Maven/Ant to automate testing of web apps.

The talk was given by Chris Bedford, from Build Lackey Labs – “Automating the Monkey Work Out and the Quality In!”. Overall, I thought this was a great talk by Chris. He clearly has a huge amount of experience creating automated tests and integrating them with build tools and he gave a well structured, interesting, well delivered presentation. I have posted a copy of Chris’s slides and I think the video will be posted on the SF JUG site at some point, but I have also posted my notes from the presentation below…
Read more

Tags: , , , , ,

Groovy: Cool but slow

I have been learning Groovy recently (as part of Project Euler, a series of Maths programming problems). For the most part, I love it. I particularly like
the easy syntax. Java without the crud!

  • System.out.println becomes simply println
  • for (int i-0; i<10; i++) becomes for ( i in 0..9 )
  • Accessor methods are autogenerated and used

Sure, the poor IDE support is a little annoying, especially the lack luster code completion and debugging capabilities, but I am sure it will improve soon (especially with SpringSource on the case).

But then I started to notice some slowness when using it. So, I performed a simple performance comparison and the results shocked me.
I wrote an identical loop in both Java and Groovy (see the code below) which simply loops a million times.

  • The Java version took ~5ms
  • The Groovy version took ~500ms

I was shocked! Could Groovy really be a 100 times slower? I had heard rumors about Groovy being a bit slower than Java, but I hadn't expected it to be this dramatic. Surely this is drastic enough to stop Groovy being used in serious, production quality projects?

I discussed this with a friend who is a Groovy advocate. He made the following points:

1. I was running with an older, slower version of Groovy

This is true. I ran the tests in Eclipse 3.5, with v1 of the Eclipse Groovy plugin, which uses v1.5.7 of the Groovy compiler.
However, when I downloaded the latest version of Groovy (Version: 1.6.3 with JVM: 1.6.0_13) and ran from the command line, it still took the Groovy code ~200 ms. A huge improvement, but still ~40 times slower than Java.

2. It is an artificial, unrealistic test, as these kind of huge loops are not normal in most programs

This is also true. But although artificial, it is still a straight comparison. Also, these kind of loops aren't so unusual in Project Euler type problems (at least in my crude brute force solutions!).

There are also some more detailed Java/Groovy performance test results here and here.

So, overall, I think the performance is a big issue. But not enough to stop me using it for pet projects. I am even going to keep trying to use it for Project Euler - it will be more motivation to avoid the brute force solutions. It is however, enough to stop me using it in any serious production apps.

For the record, here is the exact code I ran:
Java version

		long max = 1000000;		
		long start = Calendar.getInstance().getTimeInMillis();
		for(int i=0;i

Groovy version

		long max = 1000000;		
		long start = Calendar.getInstance().getTimeInMillis();		
		for(int i=0;i

It is also worth pointing out that when I changed the Groovy code to use proper Groovy syntax, as in for (i in 1..1000000) is was substantially faster (although still significantly slower than Java), but I have left it as is, for a apples vs apples comparison.


Exceptions versus Return Values

In a previous post here, I blogged about checked exceptions and how I felt they are a useful tool in your Java toolbox. It is generally accepted that errors, or unrecoverable events, should be dealt with using unchecked exceptions and that recoverable problems, or contingencies, should be dealt with using checked exceptions.

However, there is another option for dealing with recoverable problems, i.e. using return values.

Read full article & Comments


Checked Exceptions

The use of checked exceptions in Java is still widely debated. This post contains thoughts on their use by Java experts such as James Gosling, Joshua Bloch (Effective Java) and Bruce Eckel (Thinking in Java), before countering some of the arguments against their use, such as how I don’t believe they break encapsulation, and that their use shouldn’t be limited to truly exceptional conditions. It finishes by looking at when alternatives to checked exceptions should be used. The overall slant of the article is that there are many reasons why Exceptions, including checked Exceptions, should still be a part of your Java arsenal.

Read full article


Running Hibernate unit tests with Maven

I recently converted a project I have been working on to use Maven. After setting up all the dependencies in the pom, I got everything compiling fine but ran into problems getting the unit tests to pick up the hibernate config (hibernate.cfg.xml) and hibernate mapping (*.hbm.xml) files. With hindsight, it is straightforward, but it took me a while to figure it out so I thought I’d post the solution here.

Initially, I had my hibernate.cfg.xml file in the following directory


And when I first tried to run my hibernate unit tests (mvn test), I got this error:

SessionFactory creation /hibernate.cfg.xml not found

Some checking of the maven docs and some forums revealed the following possible solutions:
1) Copy the hibernate.cfg.xml file to


This works, however I think it is a hack as the target folder is generated rather than being somewhere you should actually manually create files.
2) The next solution I found suggested moving the hibernate.cfg.xml to


This works well as the contents of this folder are copied to the base level of the my-app/target/classes folder so it is basically a ‘more correct’ solution than the first.
3) The next and I think best solution was to create a new, duplicate hibernate.cfg.xml inside


This allows a different hibernate.cfg.xml file to be used for testing and, for example, facilitates connecting to a different database (such as hsqldb) for testing while continuing to use your regular database (such as MySQL) for the app itself.

A couple of points to note:

1) The hibernate mapping files (i.e. the *.hbm.xml files) should also be in the resources folder (in whatever directory structure you choose) to ensure that these too are accessible by the unit tests.

2) I am not (yet) using Spring with the hibernate components, which would likely have changed the above setup.


Tags: , ,


Came across this really neat tool that can actually find bugs in your code. It uses ‘static analysis’ to find instances of bug patterns – code instances that are likely to be errors. I was pretty skeptical until I ran it on some code and was impressed by the results. It found loads of possible problems. I’ll definitely be using it again.

Check it out at

Update: Found recommendations for another tool called JLint, which is supposed to be particularly good for spotting potential deadlocks so perhaps worth using when testing threaded code.