Better diagnostics in TDD

Automated tests gain more and more popularity in our field and our company. Avoiding being slowed down by tests becomes crucial. Steve Freeman has a nice talk on infoq.com with many advices for maintaining the benefits of automated testing without producing too much drag. One seldomly discussed topic is test diagnostics and immediately caught our attention. In short your aim is to produce as meaningful messages as possible for failing tests. This leads to the extended TDD cycle depicted below.

There are several techniques to improve the diagnostics of failing tests. Here is a short list of the most important ones:

• Using assertion messages to make clear what exactly failed
• Using “named objects” where you essentially just override the toString()-method of some type in your tests to provide meaning for the checked value

  Date startDate = new Date(1000L) {
      @Override
      public String toString() {
          return "startDate";
      }
  };
  
  

• Using “tracer objects” by giving names to mocks/collaborators in the test, e.g. in Mockito-syntax:

  EventManager em1 = mock(EventManager.class, "Gavin");
  EventManager em2 = mock(EventManager.class, "Frank");
  // do something with them
  

Conclusion

By applying the extended TDD-cycle you can drastically reduce guessing of what went wrong and find regressions much faster without using debug messages or the debugger itself.