Easy 2 Test == Less Reason to Test ?

Some classes are incredibly easy to test:

public class Name {
  private final String first;
  private final String last;

  public Name(String first, String last) {
    this.first = first;
    this.last = last;
  }

  public String getFirst() { return first; }
  public String getLast() { return last; }
}

Should we write unit tests for these simple classes? Kevin “pottymouth” Bourrillion brings this up as well:

If we write tests for these idiotic classes, we’re wasting time; if we don’t write tests for these idiotic classes, we find out later that they’re buggy because, say, we forgot to use a null-safe equality check for a nullable field, or something.

So what do you do? Do you test trivial code?

The Testing Suite Spot

Let’s look at an advanced diagram showing code complexity:

Some code feels too trivial to test, so we don’t test all of those getters and setters. Other code is awful legacy crap that is damn near impossible to test. The tests become so convoluted, time-consuming, and hacky that we don’t bother.

Random Observations

• If you wait until code gets really complex before writing that first test, it is generally too late. It is damn hard to retrofit existing code with good tests.
• Most code starts out pretty simple. You may feel like you are wasting time testing this trivial code, but complexity sneaks up on you.
• Writing that first stupid trivial test helps ensure you lay a foundation for ongoing testing. Are your build scripts up-to-snuff? Does you continuous integration build run the tests? Do you publish test results? Putting these features in place on day 1 is easy, when the code is “too trivial to test”. Procrastination makes all of these things much harder.
• Testing as you go helps avoid complexity in the first place. People who never write tests do not grasp this concept.

I believe the last bullet is the most important. Code that is “too hard to test” is often that way because you did not write tests as the code evolved rotted.

Should We Test Trivial Code?

Back to the original question. Should we write tests for trivial code? I don’t see much harm in writing a handful of trivial tests for each class. I see far more harm in writing too few tests. Even if classes never evolve beyond simple POJOs with a few getters and setters, writing trivial tests wastes very little time. If the code happens to grow and require new features, having those first few tests gives you a better starting point.

As a learning exercise, writing tests for trivial classes is the first step towards understanding how to write tests for the really hard stuff. The stuff that really needs testing.

Posted on Thursday, November 1st, 2007 at 10:11 pm in Java, Software Development.