Jakub Korab

A Better Builder

Jake — Tue, 13 Oct 2009 22:12:24 +0000

The builder pattern should be familiar to anyone who has needed to change data from one format to another. Often called assemblers, translators or similar, they’re found peppered throughout almost every project. The idea is pretty simple:

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.

Shared Items – August 27, 2009

Jake — Thu, 27 Aug 2009 13:31:53 +0000

Everything “Free” is Subsidized

August 27, 2009 – This is probably one of the most pressing issues of our time. It’s the reason why “proper journalism” is fading and why newspapers seem to have less and less actual content.

Shared Items – August 11, 2009

Jake — Tue, 11 Aug 2009 15:01:56 +0000

Are You Trying To Be a Robot?

August 7, 2009

Lost Generation

August 6, 2009

Shared Items – August 4, 2009

Jake — Tue, 04 Aug 2009 15:00:08 +0000

The Secret of World-Class Performance

August 3, 2009 – There’s an immortal truth here. One that my mum tried to get through to me when I was a kid, but which I didn’t understand until quite recently. Do what you enjoy or vice-versa. Everything else leads to mediocrity.

Testing the Untestable

Jake — Tue, 28 Jul 2009 22:25:12 +0000

Once upon a time you got sick of writing code and having it fail when you ran, or someone else did, and you learned to unit test your code.

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.

Shared Items – July 8, 2009

Jake — Wed, 08 Jul 2009 15:08:24 +0000

The Game Doctor: Another Way to Make Kids Hate Their Parents

July 2, 2009 – My mum would have bought something like this. Super fail.

Shared Items – July 1, 2009

Jake — Wed, 01 Jul 2009 10:43:13 +0000

Android Gets Scripting Support with Python, Lua, Beanshell; Ruby planned

July 1, 2009 – Superb. Just as I get an Android phone it turns out that I may get to write Groovy code for it soon.

Shared Items – June 23, 2009

Jake — Tue, 23 Jun 2009 15:00:09 +0000

Hemlock: Because immortality might not be such a good thing

June 22, 2009

Genetically Modified Turbine-Powered Rabbit

June 18, 2009 – Brilliant.

Project Coin Announces Second Candidate List

June 18, 2009 – Lists some of the proposed changes to the Java language in Java 7. Some of the stuff looks very Groovy inspired – in particular the features dealing with collections. Looking forward to this one. Along with closures, it should be a good release to remove some of the pain-points.

Computers still struggling with sporting schedules

June 18, 2009 – A real world application of the traveling salesman problem, with far more constraints than you could imagine. Who would have thought scheduling a league fixture was this hard?

Sonic lasers promise 1000 times faster PCs

June 18, 2009 – Cool.

My First Stand-Up

Jake — Sat, 20 Jun 2009 11:38:48 +0000

It’s done! After three months of hard work to build up a set I am officially a stand-up comedian!

The video suffered some technical difficulties during recording. Basically all the really funny bits are missing. Honest! You should have been there! No, not really… It starts with “There was a guy at the train station asking for change…”

I came off stage and had no idea what just happened. Did any of it make sense? Did I miss whole paragraphs? Who knows, who cares. They laughed -- hard -- and that was all that mattered.

For anyone who wants to give it a bash, it’s one of the best extreme sports out there. The fear lasts for weeks beforehand. The pressure to not-choke up, the distinct possibility of public humiliation and the endless self-doubt -- “is that joke actually funny?”, “should I really say that?”, “does this shirt bring out my eyes?” -- all brings together the perfect storm of adrenaline. Awesome!

All the guys out on stage that night were doing it for the first time, and we were seriously buzzing afterwards.

I can’t wait till my next run out! The best fun I have had in a very long time.

“When I told my friends I wanted to be a comedian, they laughed. Well, they’re not laughing now!” -- Bob Monkhouse

Shared Items – June 16, 2009

Jake — Tue, 16 Jun 2009 15:01:44 +0000

What Pair-Programing is Not

June 16, 2009 – Clear and simple explanation as to why pairing is a good idea. Easy to grasp when you do it, but not always as easy to explain to someone else.

Complete implementation of MS LINQ for Java released

June 12, 2009 – No environment’s an island, and we finally get a LINQ implementation on the JVM. Well worth kicking the tires on this one, even if the underlying providers aren’t fully complete.

Oracle Coherence vs. GigaSpaces XAP

June 12, 2009 – Having just gone through an exercise in comparing these two similar-but-different products, this is pretty handy.

Keynote: The Future of Java Innovation

June 11, 2009

Expialidocious : Mary Poppins Electronica Remix

June 11, 2009 – Remixing at its finest. Both video and soundtrack. Amazing.

Futurama is Back, Baby!

June 11, 2009 – Awesome.