If you are into unit testing, you may find EasyMock quite useful. It is very valuable for making hard-to-test-code testable.

For example I recently was adding tab-switching via keyboard to Riena. The state of each tab is kept in an interface named INavigationNode which has about 40 methods (!). Creating a mock by hand for such a big interface would not be fun at all. With EasyMock it just takes is a call to:

ISubApplicationNode nodeA = EasyMock.createMock(ISubApplicationNode.class);

The code for determining the next tab, depends strictly on the isSelected property. Manipulating the return value of this method takes just another EasyMock call:

EasyMock.expect(nodeA.isSelected()).andReturn(true);

This tells EasyMock that nodeA.isSelected() will be called once and should return true.

After everything is set-up I switch from ‘record’ to ‘play-back’ mode:

EasyMock.replay(nodeA);

Here’s a full example of a test case:

  protected void setUp() throws Exception {
    super.setUp();
    handler = new SwitchSubApplication();
    nodeA = EasyMock.createMock(ISubApplicationNode.class);
    nodeB = EasyMock.createMock(ISubApplicationNode.class);
    nodeC = EasyMock.createMock(ISubApplicationNode.class);
  }
 
  public void testFindNextSubApplicationAtoB() {
    EasyMock.expect(nodeA.isSelected()).andReturn(true);
    EasyMock.replay(nodeA);
 
    ISubApplicationNode[] nodes = { nodeA, nodeB, nodeC };
    assertSame(nodeB, handler.findNextNode(nodes));
  }

This post barely scratches the surface. Curious? Read this nice EasyMock introduction.

Image: (c) *Micky/flickr. Licensed under creative commons.

Tags: riena, testing, tips

The other day I experienced an unexpected light bulb moment concerning unit testing. Maybe this one is obvious to most of you, but I wish someone would have told me earlier. So here goes.

My biggest gripes with unit testing has been that I couldn’t get any satisfactory answers to these two questions:

1. Why should I practice Test-First?
2. How do you test the tests?

Concerning the first issue, well we discussed some papers that where trying to answer that question when I attended a software quality course at university. The gist of the results were: There is no statistically significant difference in code quality between Test-First and and Test-Later. (Sorry can’t find links to the papers atm. Holler if you want me to find them and I’ll do some more digging.)

The second issue is discussed often as well: If tests are code and code should be tested, doesn’t that lead to more and more tests? This is sometimes referred to as the stack overflow of unit testing.

The revelation I had was this: These two questions answer each other! What’s the easiest way to test a test? A broken implementation. Where do you get a broken implementation? Just use an incomplete implementation. If you practice  Test-First all your implementations start off incomplete by definition. This means that each assertion in your test is guaranteed to fail at least once, giving you the confidence that the assertions actually perform significant work.

I am often surprised that assertions that I expect to fail actually go through just fine. This usually means one of two things: Either the functionality is already there by some fluke (cf. accidental correctness), or my test is incorrect. In either case I can then fine-tune and adapt the assertions to make sure that they fail and thus test some missing functionality.

Two conundrums solved.

Tags: first, test, testing, tips, unit