Blogging Pubbitch

In a galaxy far, far away there was a tool that I really liked, but never pushed into my builds. Nevertheless, it changed the way that I thought about code, and how I thought about my tests.

That tool? Agiledox.

The idea is simple: a class under test ("Foo") is normally tested in a class that's named after the class under test ("FooTest"). If the test names reflect roles and responsibilities, we can automatically generate documentation. The way to do this is to take the test names, strip the word "test" from them and un-camelcase the names. That is:

public class FooTest extends TestCase {
  public void testShouldDoThis() {}
  public void testShouldDoThat() {}
  public void testOnTuesdayShouldMeltdown() {}
}

becomes:

Foo

• Should do this
• Should do that
• On tuesday should Mmeltdown

Now, the twist is that there's something missing here: an explanation as to why the Foo class was written in the first case. The class under test sometimes contains a meaningful top-level javadoc. It makes sense to drag that in too.

Voila! Documentation!

Docs on their own are pretty meaningless, but I like the fact that this is a handy way to drive a conversation about OO design, testability and code quality.