public class HouseBuilder {
    public House buildHouse(OtherHouseType otherHouse) {
        House house = new House();
        // copy a whole bunch of properties from the otherHouse....
        for (OtherWallType otherWall : otherHouse.getWalls()) {
            house.addWall(buildWall(otherWall));
        }
        return house;
    }

    private Wall buildWall(OtherWallType otherWall) {
        Wall wall = new Wall();
        // copy another whole bunch of other properties....
        // do something fancy every third Tuesday of the month...
        for (OtherWindowType otherWindow : otherWall.getWindows()) {
            wall.addWindow(buildWindow(otherWindow));
        }
        return wall;
    }

    private Window buildWindow(OtherWindowType otherWindow) {
        Window window = new Window();
        // you get the idea....
        return window;
    }
}

It’s OK for translating small object graphs, but for non-trivial work, these things can turn into huge heaving masses of code. Because they’re pretty quick to knock out, they’re generally untested as the above code doesn’t really lend itself to it. Take the buildWall() method above – you can’t really exercise the “every third Tuesday” case easily without running through buildHouse(), and then calling buildWindow(). It becomes a pain to construct the data model to pump into test cases, and as we know, anything that’s not easy or highly visible doesn’t get tested. Did I just say that? Oops. Sorry, industry secret.

One strategy that’s applied is to write builders for each object type, i.e. HouseBuilder, WallBuilder, WindowBuilder. These are then either wired together via dependency injection (ugly as it exposes internal mechanics), or hard-coded in with a setter to substitute a dependency at test time. There’s also the drawback of a morass of tiny classes proliferating in a package somewhere. Not necessarily a bad thing, but when doing this sort of work there’s typically a good amount of refactoring, as well as use of utility classes to enrich data when moving between formats. Personally, not a big fan of this approach.

So, here’s a cool little trick:

public class MuchImprovedHouseBuilder {
    private MuchImprovedHouseBuilder delegate;

    public MuchImprovedHouseBuilder() {
        delegate = this;
    }

    void substituteInternalBuilder(MuchImprovedHouseBuilder otherBuilder) {
        delegate = otherBuilder;
    }

    public House buildHouse(OtherHouseType otherHouse) {
        House house = new House();
        // copy a whole bunch of properties from the otherHouse....
        for (OtherWallType otherWall : otherHouse.getWalls()) {
            house.addWall(delegate.buildWall(otherWall));
        }
        return house;
    }

    Wall buildWall(OtherWallType otherWall) {
        Wall wall = new Wall();
        // copy another whole bunch of other properties....
        // do something fancy every third Tuesday of the month...
        for (OtherWindowType otherWindow : otherWall.getWindows()) {
            wall.addWindow(delegate.buildWindow(otherWindow));
        }
        return wall;
    }

    Window buildWindow(OtherWindowType otherWindow) {
        Window window = new Window();
        // you get the idea....
        return window;
    }
}

All of the translation is done in one builder class. On construction, a private field defines a “delegate”. Think of it as a placeholder that will do the “other bits” of the translation and set it to “this”. A package scoped setter allows a test to overwrite the builder with a mock. So with a bit of reference fiddling, we can then test one method at a time, without having to worry about the implementation details of the other methods in the class. All of the non-public methods are given package scope, so they can be tested straight out of your favourite test framework. So, you can now do this in live code:

HouseBuilder builder = new HouseBuilder();
House house = builder.build(otherHouseType);

And at the same time write tests like this:

HouseBuilder builder = new HouseBuilder();
HouseBuilder mockBuilder = EasyMock.createMock(HouseBuilder.class); // the classextension version of EasyMock
EasyMock.expect(mockBuilder.buildWindow(isA(OtherWindowType.class)).andReturn(new Window());
EasyMock.replay(mockBuilder);
builder.substituteInternalBuilder(mockBuilder);
Wall wall = builder.buildWall(otherWallType);

Simple, and you don’t have to stick in any new tools to achieve it.

You read the JUnit docs, and wrote tests for those classes which contained discrete, self-contained code. And quickly realised that the world doesn’t work like that.

Code relies on other code. Often very complex code. And you discovered dependency injection. You abstracted out the collaborating class, and injected it in to the code. Great!

Now you could use stubs – code which always behaves in a certain way – as part of your test, and discretely use them to test the top level code. Awesome! For about two weeks.

The stubs became too inflexible, and every time you changed the interface of the class being stubbed, you had to change the stub too. Not only that, having the stubbed code behave the same way every time was too inflexible. What if you need to test how the top-level code reacts when its collaborators throw errors?

So you looked on the net and you learned about mock objects. It was like getting into a hot bath. Now you could dynamically define the behaviour of collaborating classes in every test. You could test exception handling! Excellent! Until once again, it wasn’t.

Because the world doesn’t work like that. Your code style develops. You want to use other patterns, and behaviours, that don’t fit well with the idea of injection, and which are a code-level implementation detail. Sometimes you just want to instantiate a class and use it. And not have to test it along with the code that uses it. Maybe it’s builders. Maybe it’s a stream that you want to write to. Conversely, you don’t want to litter your Spring config with objects of a tiny ganularity just for the purposes of testing. And you find that your testing tools aren’t enough. Not only that, they are now driving the design of your code.

What if you could write code at the level of abstraction that makes sense to you? Static helper methods? Builders? Package private classes that get instantiated from inside your code? What if you want to wire the objects in your application at a granularity that makes sense?

“Surely, you must be smoking!” I hear you say. “That is a pipe dream reserved for dynamic language programmers, not us grunting around at the coalface in Java.” Well, actually, no. The latest generation of unit testing tools allow you to do just that! With Java!

JMockit is one of the latest toolkits in the evolutionary chain of mocking tools. It depends on the instrumentation APIs in Java 6 to enable behaviour that was previously unattainable. One of the prerequisites is that you are using the latest 1.6 JDK for your code, but if you are – rock and roll. Let me demonstrate:

Let’s say that you are writing an application that blatantly violates the trademarks of MTV’s favourite show and tricks out rubbish cars. Here’s your main code:

package demo;

public class PimpingService {

    private CarDao carDao;

    public void setCarDao(CarDao tradeDao) {
        this.carDao = tradeDao;
    }

    /**
     * Loads a car and pimps it, saving it and returning.
     * representative of a lot of code out in the wild.
     *
     * @param carId The primary key of the car to load.
     * @return The pimped ride.
     */
    public Car pimpRide(Long carId) {
        Car unpimpedCar = carDao.findCar(carId);
        Car pimpedCar = PaintShop.resprayWithFlames(unpimpedCar);

        if (pimpedCar.getValue() > 100000) {
            ElectronicsWizard wizard = new ElectronicsWizard(24);
            pimpedCar = wizard.makeFullySick(pimpedCar);
        }

        try {
            carDao.save(pimpedCar);
        } catch (IllegalStateException isx) {
            // roll back our changes
            pimpedCar = unpimpedCar;
        }
        return pimpedCar;
    }
}

You’ve got some pretty interesting usage patterns here:

• a dependency injected DAO
• use of static methods
• object instantiation

The first is pretty straightforward to mock up, but the others, not so much.

Let’s take a look at the other classes:

package demo;

public final class Car {
    private final Double value;

    public Car(Double value) {
        this.value = value;
    }

    public Double getValue() {
        return value;
    }
}

package demo;

public class CarDao {

    /**
     * Finds a car by its primary key.
     * @param carId The primary key.
     * @return A car if found, or null.
     */
    public Car findCar(Long carId) {
        // normally there'd  be some kind of jdbc thing here
        return new Car(100000d);
    }

    /**
     * Saves a car.
     * @param car The car.
     */
    public void save(Car car) {
        // ...
    }
}

package demo;

public class PaintShop {

    /**
     * Resprays a car, increasing its value.
     * @param car The car.
     * @return A resprayed version of the car.
     */
    public final static Car resprayWithFlames(Car car) {
        Car resprayedCar = new Car(car.getValue() * 2);
        return resprayedCar;
    }

}

package demo;

public class ElectronicsWizard {

    private int multiplier;

    public ElectronicsWizard(int multiplier) {
        this.multiplier = multiplier;
    }

    /**
     * Makes a car fully sick.
     * @param car The car to make fully sick.
     * @return A fully sick car.
     */
    public Car makeFullySick(Car car) {
        return new Car(car.getValue() * multiplier);
    }

}

So, as we run the code, things happen. We first load the car, and then we keep changing its value depending on what operations we run on it.

Let’s exercise it using JUnit and JMockit. This code uses JUnit 4 and JMockit 0.98.

package demo;

import mockit.Expectations;
import mockit.Mocked;
import mockit.integration.junit4.JMockit;
import org.junit.Before;
import org.junit.Test;
import org.junit.runner.RunWith;
import static org.junit.Assert.assertSame;

@RunWith(JMockit.class)
public class TradeServiceTest {

    @Mocked
    private CarDao mockCarDao;
    @Mocked
    private ElectronicsWizard mockWizard;
    @Mocked
    private final PaintShop unusedMockPaintShop = null;
    private PimpingService pimpingService;

    @Before
    public void setUp() {
        pimpingService = new PimpingService();
        pimpingService.setCarDao(mockCarDao);
    }

    /**
     * Checks that happy path to pimping cars.
     */
    @Test
    public void testPimpRide() {
        final Long carId = 1L; // this is the id that we'll look up
        // the ride we'll expect to get back from the process
        final Car fullySickCar = new Car(300000.0);

        new Expectations() {
            { // static block

                // set an expectation on this mock that it will be invoked with
                // a car id
                mockCarDao.findCar(withEqual(carId));
                Car foundCar = new Car(100000.0);
                returns(foundCar); // return value from last mock call

                // this static method will be called next
                PaintShop.resprayWithFlames(withSameInstance(foundCar));
                Car resprayedCar = new Car(200000.0);
                returns(resprayedCar); // set its return value

                new ElectronicsWizard(24);
                returns(mockWizard);

                mockWizard.makeFullySick(withSameInstance(resprayedCar));
                returns(fullySickCar);

                // we're done
                mockCarDao.save(withSameInstance(fullySickCar));
            }
        };

        // all that's left is to invoke our service and see what happens
        Car resprayedCar = pimpingService.pimpRide(carId);
        assertSame(fullySickCar, resprayedCar);
    }

}

So what’s going on here?

• We import a few JMockit classes (line 11) to help us with the testing. Because of the way that JMockit operates, there are bits and pieces that are required to integrate the toolkit with the testing framework being used. Here, we import the JUnit version.
• You need to create placeholders (lines 14-19) for each of the classes that you will be mocking, regardless of whether you want to instantiate them, such as in the case of our unusedMockPaintShop, on which we will just be calling static methods.
• You define mock objects behaviour in an Expectations block. This makes use of a syntax similar to JMock, where all your code is defined in a static block (line 38). If you are used to EasyMock, you’ll immediately notice the change in style. You use static methods of the Expectations class immediately after the expected method calls to define how the mock object will behave. Line 44’s returns(foundCar) is an instruction for the mockCarDao used on line 42.

The rest pretty much looks like a standard unit test. What about some different behaviour from the instantiated class?

    /**
     * Checks that the electronics wizard won't get called in if the paintshop gives us a
     * car with a small value amount.
     */
    @Test
    public void testPimpRideElectronicsWizardNotCalled() {
        final Long carId = 1L;
        // the car we'll expect to get back - look at the new value
        final Car resprayedCar = new Car(50000.0);

        new Expectations() {
            {
                mockCarDao.findCar(withEqual(carId));
                Car foundCar = new Car(100000.0);
                returns(foundCar);

                PaintShop.resprayWithFlames(withSameInstance(foundCar));
                returns(resprayedCar);

                // its return value is < 100,000 so no wizard here
                // if the wizard was invoked, you'd get an error:
                // Unexpected invocation of: demo.ElectronicsWizard#ElectronicsWizard(int)
                // it's @Mocked, remember?

                mockCarDao.save(withSameInstance(resprayedCar));
            }
        };

        Car tradeReturnedFromService = pimpingService.pimpRide(carId);
        assertSame(resprayedCar, tradeReturnedFromService);
    }

That’s all well and good. But what about testing how our code will handle exceptions?

    /**
     * Checks that no wizard work will be done if respraying gives us a
     * car with a small value amount.
     */
    @Test
    public void testPimpRideElectronicsWizardNotCalledSavingBreaks() {
        final Long carId = 1L;
        final Car foundCar = new Car(100000.0);

        new Expectations() {
            {
                mockCarDao.findCar(withEqual(carId));
                returns(foundCar);

                PaintShop.resprayWithFlames(withSameInstance(foundCar));
                Car resprayedCar = new Car(50000.0);
                returns(resprayedCar);

                mockCarDao.save(withSameInstance(resprayedCar));
                // dao throws a humorous antipodean complaint here
                IllegalStateException isx = new IllegalStateException("Ooh bugger");
                throwsException(isx);
            }
        };

        Car tradeReturnedFromService = pimpingService.pimpRide(carId);
        // the service should have just returned the car it found
        assertSame(foundCar, tradeReturnedFromService);
    }

That’s nowhere near what you can do with JMockit, but it should give you a good taster. Code that was previously untestable, can now be dealt with as easily as a straightforward class with injected dependencies. Go forth and code in whatever way makes sense to you, DI or not, content in the knowledge that it’s all good and testable.

The standard unit test has three basic phases:

• Setup (@Before)
• Test (@Test)
• Tear down (@After)

The first sets the test environment into an expected state, the second runs the test and checks that the outcome is as expected, while the final one clears up any test resources.

How does this relate to database testing? Let’s say that we have a DAO that performs a particular select statement. Our test should be to retrieve a particular number of records from a known set. Easy enough. The precondition of course, is that you have a known set to begin with.

It’s ALL about the environment.

Most large development projects go like this: The database guys update the schema. The developers write the code. The developers need a particular data set to exercise the various use cases so they add it to the schema. It all becomes a bit messy.

Eventually, very complex data sets are set up by everyone concerned in a primary schema that keeps getting updated. The database schema generally is not version controlled, as it is constantly being redefined using DDL statements run by the DBAs. Most of the time you will be lucky to get a backup of a schema, with all of the data truncated, as the schema and supporting code (i.e. the application) moves between environments.

Getting back to the test. You set up your data by hand in the master schema so that there were three items in the widgets table where some condition was true. You write your test, it runs against the schema, pulls out the expected three widgets and everything is great. You check in the tests. A week later your colleague, Bob, adds another widget to satisfy his test condition. Your test all of a sudden returns 4 items and the test breaks.

Of course, Bob didn’t actually run your test because he was too busy with his own and the test suite isn’t clean anyway because everyone is falling over each other.

Sound familiar?

What about inserts? The precondition: no sprockets were in the table, the test: insert a sprocket, the postcondition: a sprocket is in your table. Kind of hard to test under the above conditions isn’t it? For one thing, the exact data of the test sprocket may be in the table, so checking by value may give you false positives, while deleting it may get rid of more records than you wanted. What about concurrent tests? With a group of developers running the same tests, they start tripping over each other very quickly and the whole effort becomes an exercise in frustration. At this point the development manager throws up his hands, says that this automated testing thing is a load of bollocks and to get back to your work because they didn’t deal with all this when he was doing VB. Somewhere else, Kent Beck sheds a tear…

Let’s examine what goes on in Ruby on Rails. One of the best ideas that was popularized by this framework was its method for database unit testing. A developer’s workspace has multiple environments by default – development, test and production. You develop against the development schema, designing table structures, and playing with the user interface to your heart’s content. When you run unit tests, the following happens – the schema from development is copied into the test database with no data in it. The framework imports version controlled sets of test data (saved as YAML files) into this new schema. Whenever a test is run, it is guaranteed that the database will be in this state. Any changes a test makes are visible only within the scope of this one test. The tear down step cleans out your changes. This makes life so much simpler, especially if you have been working in the nightmare scenario above.

So how do we get the same sort of effect in a corporate development environment?

You need multiple database schemas in order to unit test your db code.

Pause and re-read that line. It’s not negotiable. Probably two per developer. One with sample data to use while you work on the user interface. The other, a temporary one for unit testing. A whole development team using the one schema does not work. Most projects do it, but that doesn’t mean that it’s a good idea.

Some suggestions for how to manage this. The DBAs have their own schemas. The full DDL for the database is kept in version control. After each change, the full database DDL is dumped and checked in. No UPDATE TABLE statements. Ever. This way you are guaranteed that if you ever want to get a baseline of your system, you can also rebuild the database as it existed at this time. I worked on a very large telecoms project with a huge development team, and this worked. Well.

The test data for your environments is stored in version control – at the very least, as dumps of insert statements. For unit testing purposes, a dedicated unit test framework is beneficial. DBUnit performs the same task in Java as described above for Rails – it loads test data from dumps (a number of formats are supported), and guarantees that the test database exists in the expected state when each test is run.

To test your database code, refresh your test schema with the one from version control – typically using your chosen build system. Ant tasks are generally pretty good for this. Now run your test cases. Gorgeous! No tripping over other people, and your tests are guaranteed to work the same each time. No excuses for a red bar.

So why is unit testing databases so difficult if it doesn’t have to be? Most of the time it involves process change and getting out of bad habits, not just a tool. And change means convincing people. Generally, managers do not understand what benefit there is in multiple database schemas, as it is seen to increase complexity and therefore risk, and DBAs like to have full control over what is going on on their servers. The topic of databases and processes is also a great one for religious zeal.

The process outlined above should explain the hows and whys to the individuals involved. The changes above mean a little bit more setup initially, but a saner development process.

A nice side effect is how easy upgrading databases through your environments can become. Run the latest DDL against a fresh schema, get the differences between it and your target environment using a database compare tool, and fire it off. Beautiful.

I love stats. I don’t know what it is. They’re like horoscopes, or something. Pinch of salt and all that, but you can’t not read them. Even better with diagrams

They have a commercial product called AgitarOne that is worth checking out, which runs on your intranet and you can do a whole bunch of stuff in, but they also have a free version called JUnit Factory. You can either upload your code to them via your browser or via an Eclipse plugin. Code In, Tests Out! Superb!

It’s not a substitute for development time testing, but still a great tool for your professional arsenal. How cool will you look when you put a test suite around that nonsense you have been given to work against

There’s a great interview with Alberto Savoia from Agitar on the Business of Software conference site that goes into the how’s and why’s.

Enter the mock object. According to Wikipedia – “mock objects are simulated objects that mimic the behavior of real objects in controlled ways”. And thanks to freely available Java toolkits such as EasyMock and jMock, making them available to your tests is as easy as plugin in a Jar file into your IDE. I’m a heavy user of EasyMock, so what follows is a simplified example of a jUnit test testing the middle tier of your typical DI-based application.

The following example deals with the following classes:

• WorkItem – a simple value object
• WorkItemException – an exception
• WorkItemService – an interface of a middle tier class
• WorkItemDao – an interface to the data layer of our application. This is what we are going to mock up.
• WorkItemServiceImpl – an implementation of that class. This is what we are going to test.
• WorkItemServiceImplTest – our test class

First, let’s get the uninteresting classes out of the way. Our WorkItem is just a bean that gets passed between the layers:

package jkorab.example.mock;

public class WorkItem {
 int workItemNo;

 public int getWorkItemNo() {
    return workItemNo;
 }

 public void setWorkItemNo(int workItemNo) {
   this.workItemNo = workItemNo;
 }
}

The WorkItemException is an exception that gets thrown:

package jkorab.example.mock;

public class WorkItemException extends Exception {
  private static final long serialVersionUID = 1L;
}

Now we come to the class that normally sits in the business tier of our application:

package jkorab.example.mock;

public interface WorkItemService {

  /**
   * Trivial method. Given a workItem number > 0, returns a workItem instance.
   * Used to show how you might test the wrapping of an exception.
   *
   * @return WorkItem or null.
   */
  public abstract WorkItem generateWorkItem(int workItemNo);

}

Let’s take a look at the interface of the class it uses to do its work:

package jkorab.example.mock;

public interface WorkItemDao {

  /**
   * Given a workItem number > 0, returns a workItem instance.
   * @param workItemNo workItem number
   * @return WorkItem if workItemNo > 0.
   * @throws WorkItemException if workItemNo <= 0.
   */
  public WorkItem getWorkItem(int workItemNo) throws WorkItemException;

}

Our example is, as is the spirit of most tutorials, pretty contrived. The top tier of our application wants to load a WorkItem, so it passes a work item number to the service tier. The service tier gets the work item, and if it cannot find it, returns null. The DAO on the other hand, gets a work item number and it the number is less than or equal to 0, it throws an exception, otherwise it loads the WorkItem.

Here’s the implementation of the WorkItemService:

package jkorab.example.mock;

public class WorkItemServiceImpl implements WorkItemService {
  private WorkItemDao workItemDao;

  public void setWorkItemDao(WorkItemDao workItemDao) {
    this.workItemDao = workItemDao;
  }

  /* (non-Javadoc)
   * @see jkorab.example.mock.WorkItemService#generateWorkItem(int)
   */
  public WorkItem generateWorkItem(int workItemNo) {
    WorkItem workItem = null;
    try {
      workItem = workItemDao.getWorkItem(workItemNo);
    } catch (WorkItemException workItemException) {
      // log and continue. we'll return null.
    }
    return workItem;
  }
}

The class here is doing what the interface “said on the tin”. In addition it has a setter so that the DI container can supply it with a DAO implementation. That’s where our hook is that will enable us to test the service without an actual DAO implementation.

The first thing we need in order to write a test class is a mock DAO. This is the component that the service class will call. In addition we will also need a mock control. Think of this as a component that instructs your DAO as to how it should behave – kind of like a way of programming your Tivo/Set top box/VCR (for those who still have one ).

MockControl control = MockControl.createControl(WorkItemDao.class);
WorkItemDao mockDao = (WorkItemDao) control.getMock();

WorkItemServiceImpl service = new WorkItemServiceImpl();
service.setWorkItemDao(mockDao);

The MockControl class is used to get an instance appropriate to the interface we are mocking up. From this, calling getMock() will return to us an implementation of our DAO interface which we then set on the instance of the class we are testing. This would normally be done in the setUp() method of your jUnit test class, so that each of your tests is guaranteed to get a mock instance in a fresh state, which you can then play with.

In our test method, we can then get on with doing some work. First, we tell our DAO exactly how we would like it to behave:

// set the methods that you expect to be called
mockDao.getWorkItem(1);

// set the return value
WorkItem returnedWorkItem = new WorkItem();
returnedWorkItem.setWorkItemNo(1);
control.setReturnValue(returnedWorkItem);

// reset the control object to play back our script
control.replay();

The last line tells the mock control object that the mock DAO is now in a state where the test can be run on it.

WorkItem workItem = service.generateWorkItem(1);
assertNotNull(workItem);
assertEquals(1, workItem.getWorkItemNo());

// verify that the methods we expected to be called on the mock object
// were actually called
control.verify();

The last line tells the control object to check itself to ensure that all the methods that we told it would be called were in fact called. It will throw an Exception if they weren’t causing our test to fail.

The behaviour described above can be used to test the behaviours of your service class under any circumstances. We can mock up the throwing of an Exception, unexpected behaviours, whatever we want. Here’s the full test class:

package jkorab.example.mock;

import jkorab.example.mock.WorkItem;
import jkorab.example.mock.WorkItemDao;
import jkorab.example.mock.WorkItemException;
import jkorab.example.mock.WorkItemServiceImpl;

import org.easymock.MockControl;

import junit.framework.TestCase;

public class WorkItemServiceImplTest extends TestCase {
  private MockControl control;
  private WorkItemDao mockDao;
  private WorkItemServiceImpl service;

  public void setUp() {
    control = MockControl.createControl(WorkItemDao.class);
    mockDao = (WorkItemDao) control.getMock();

    service = new WorkItemServiceImpl();
    service.setWorkItemDao(mockDao);
  }

  /**
   * Checks that a WorkItem will be returned if the class receives a workItem
   * number greater than 0.
   *
   * @throws WorkItemException
   */
  public void testGenerateWorkItem() throws WorkItemException {
    // set the methods that you expect to be called
    mockDao.getWorkItem(1);
    // set the return value
    WorkItem returnedWorkItem = new WorkItem();
    returnedWorkItem.setWorkItemNo(1);
    control.setReturnValue(returnedWorkItem);
    // reset the control object to play back our script
    control.replay();

    WorkItem workItem = service.generateWorkItem(1);
    assertNotNull(workItem);
    assertEquals(1, workItem.getWorkItemNo());

    // verify that the methods we expected to be called on the mock object
    // were actually called
    control.verify();
  }

  /**
   * Checks that a null will be returned if the class receives a workItem
   * number equal to 0 rather than throwing an exception.
   * @throws WorkItemException
   */
  public void testGenerateWorkItemNullValue() throws WorkItemException {
    // set the methods that you expect to be called
    mockDao.getWorkItem(0);
    // set the control to throw an exception
    control.setThrowable(new WorkItemException());
    control.replay();

    WorkItem workItem = service.generateWorkItem(0);
    assertNull(workItem);
  }
}

This is a great way to test, not only because of its simplicity, but also it being future proof. Let’s examine another way of writing the same tests without using mock objects:

WorkItemDao mockDao = new MockDao() {
  public WorkItem getWorkItem(int workItemNo) throws WorkItemException;
    WorkItem returnedWorkItem = new WorkItem();
    returnedWorkItem.setWorkItemNo(1);
  }
};

WorkItemServiceImpl service = new WorkItemServiceImpl();
service.setWorkItemDao(mockDao);

WorkItem workItem = service.generateWorkItem(1);
assertNotNull(workItem);
assertEquals(1, workItem.getWorkItemNo());

At first glance, coding up an anonymous class looks like less work, but consider the following:

• if your class is more complex than this (and to be honest, most are) then you will end up with potentially dozens of anonymous implementations.
• if the DAO has more than one method, you will end up with a lot of code that does nothing.
• if the interface on your DAO changes then you will end up with a lot of tests that won’t compile, because your classes no longer match the interface.

This just isn’t the case with mock objects. Mock objects are created at runtime, and you only have to define the behaviours that you are interested in. The technique can also be used to test existing code – refactor your dependencies to an interface, use DI or a constructor if this isn’t an option, and voila, a testable class. 100% code coverage, and future-proof. No more excuses.

If you are interested in more info on mock objects check out the MockObjects blog.