One thing struck me about Steve's comments that I simply had to explore. He stated, that for "trivial code with few dependencies...it doesn’t matter whether you unit test it or not." He doesn't stress this position. In fact, he states that he is perfectly OK with those of us who take the time to write tests for trivial code.
However, I still feel these tests offer significant value to the code base and to the developers who must work with it. First, writing these tests benefits the developer:
- TDD is a practice which focuses the thinking on creating the simplest solution that can work one step at a time. It helps me think out of the box and sometimes produces an even simpler solution than the one I started to jump to. Eventually, I can break down harder problems because I have so much practice at it with easy problems. As Kent Beck says in his TDD book, you should always be capable of moving at a slow pace when necessary. TDD of a trivial problem is a kata!
- Existing tests can serve as a template for a new test to drive a design change or a defect correction. Call me lazy, but when the previous dev already has gone to the trouble to create all of the test setup, mocking, etc. it can save me time when correcting a defect or extending a behavior. Yes, these happen even in classes I considered to be trivial.
- I am firmly convinced that trivial code often becomes more complicated (perhaps over-complicated if we don't watch). For many systems I've worked on,it happens sooner than I think it will. It is worth the small effort to write the tests to assist in the later refactoring. Why not do it while the context of the original required behavior is fresh in your mind?
- Yes, you could add tests after realizing they are needed. But that doesn't produce the same kind of tests and ignores the Red-Green-Refactor design cycle which I contend still has value for trivial problems.
- Have you ever discovered that your "simple" class actually has too many responsibilities? It is so much easier to refactor into multiple classes with tests on the behaviors.
- Yes, the source code expresses the actual behavior, but tests developed as part of TDD record what the developer thought the behavior was supposed to be.