expect(mockBuilder.buildDoor(otherDoorData)).andReturn(new Door());
expect(mockBuilder.buildWindow(otherWindowData)).andThrow(new NumberFormatException());

is much easier to deal with than the following repeated a dozen times in your unit tests:

builder = new HouseBuilder() {
@Override
Window buildDoor(OtherDoorType otherDoorData) {
return new Door();
}

@Override
Window buildWindow(OtherWindowType otherWindowData) {
throw new NumberFormatException();
}
}

In fact the latter approach may not be possible if your builder class is final. You may also need to call a method more than once and have it return different values:

expect(mockBuilder.buildDoor(otherDoorData)).andReturn(new Door());
expect(mockBuilder.buildDoor(moreDoorData)).andThrow(new IllegalStateException(“You already have a door”));

I had another thought…

Couldn’t the same swappable behaviour be achieved by simply extending the builder with a mock builder and overriding the methods you don’t want to test? I.e. use the flexibility that say the template method pattern affords?

I’ve just completed a recent project involving a lot of “mapping” or “translating”. I opted for individual mapper classes due to their reusability across different scenarios – for example the mapping of a particular type that is a member of many different, and quite independent, objects.

In addition, the mapping classes were really pretty big and to have all of this logic in a single class would create a massive class. Not quite a monolithic block of code in a single method, but it would still have the feel of a retro procedural programming treat.

I guess for me I felt that the individual mapper classes were better aligned with the principles of single responsibility, separation of concerns, increased cohesion and reduced coupling, albeit for the cost of class explosion! Each mapper only knew about the input object, the resulting output object, and any child or member objects. It’s also simple to test – something which I did actually do.

Like everything though, it depends on the situation and it’s interesting to have another tool in the bat belt for this. I’ll definitely take this into consideration next time around.