Saturday, 20 June 2009

Make Fake/Stub objects simpler with proxies.

I recently wrote a convenience component. It's a Java dynamic proxy creator with a default handler that simply delegates any methods called on it to a provided delegate, throwing an UnsupportedOperationException if such a method isn't implemented. Why? Because I was sick of writing huge Fake implementations of medium-to-huge interfaces when I needed a fake, not a mock, and I was frustrated with using EasyMock as a convenience to create Fakes and Stubs. This delegator allowed me to implement only the parts of the API provided by the Interface, and just not bother with the rest. This was useful for such things as factories or other "lookup" components which I was going to feed (in my tests) from some static hash-map.

This gets back to my new motto: I hate boilerplate. If I have to implement every interface method in a fake object, then I'm going to go crazy implementing public String getFoo() { return null; } all over the place. Especially since that method will never get called in my test, and in fact if it does, I want it to fail noisily. So I could write public String getFoo() { throw UnsupportedOperationException("Test should not call this method"; }. That's great, but if I have to do that for a component that's got thirty methods, my test classes are going to be littered with this. Instead, I can do:

public class MyTestClass {

  private final hMap<Long> BAR_CACHE;

  public void classInit() {
    BAR_CACHE = new HashMap<Long>();
    BAR_CACHE.put(1, new Bar(1, true));
    BAR_CACHE.put(2, new Bar(2, false));
    BAR_CACHE.put(3, new Bar(3, true));
    BAR_CACHE.put(4, new Bar(4, true));

  public void testFooValidityCount() { 
    BarFactory fooDep = Delegator
        .createProxy(BarFactory.class,new FooDelegate());
    Foo foo = new Foo(fooDep);
    assertEquals(3, foo.getCountOfValidBars());

  ... more test methods that need to look stuff up...

  public static class FooDelegate {
    public void init() { /* ignore */ }
    public Bar getBarWithId(int id) { BAR_CACHE.get(id); }

If we assume that FooFactory is an insanely long interface, then this allows me to do a very clean Fake implementation with only a few bits of implementation. Otherwise, a FakeFooFactory could be longer than all the test code in this testing class. The other thing I like about this, is that - especially if you're testing code that uses dependencies you're not intimately familiar with, nor have access to the source, you can quickly implement an empty delegate and let the exceptions in the test guide you towards the leanest implementation. You'll get an exception any time your delegate is missing a method used by your System Under Test on your dependency. Handy.

Essentially, the Delegator is simply a pre-fab proxy InvocationHandler, with some reflection jazz in the invoke() method to lookup methods on the delegate, or throw... but it saves a bunch of extra boilerplate. I've had fake classes so large THEY needed tests. This is a much nicer approach for non-conversational dependencies (where mocks would be better). I tried to do this with EasyMock, but the implementations were really awkward due (ironically) to the fluent interface style. This is just a rare case where it's cleaner to just have a minimal implementation.

Unfortunately, the code I wrote is closed-source for my employer, but it's simple enough that everything I've done above should let you implement your own.

... and remember, kids... Mocks, Stubs, and Fakes are all Test Doubles, but they're all not the same thing.


Mark Levison said...

Christian - you've got me a little confused. What about this doesn't EasyMock do for you? Can't you feed it an interface and implement only the bits you care about?

Christian Gruber said...

So, apparently I have had moderated comments for years and not known it.

But to answer, there's nothing "wrong" wtih EasyMock - it does the job - specifically "nice mocks." I just find (or found) it fairly hard to easily, readably, and conveniently stage nice mocks. Some things have improved over the years, and Mockito is something I really appreciate for doing convenient stubbing and "test spies." But regardless, this pattern was simple adn easy, and it distinguished my mocks from my stubs. Especially where I find people over-specifying their mocks, or using mocks to stub things out and then verifying where they shouldn't.

Hmm. I don't want to make this a mocks vs. stubs rant - I just tend to not like to use mocks where I need a pure stub - that is, I"m not validating the behaviour and interaction with the collaborator - the collaborator is literally just there to satisfy the dependency.