Bad Tests Good Tests - Wasting Your Time

There are some things which are not worth unit-testing. Really, there are. Getters/setters and delegators are the best examples.

This post is a part of my new free book about tests. You can learn more here. Please share your comments (so the book is better).The idea for the book is to discuss examples of test classes and to present ways of making them better.

Take for example this test (which, as all other tests in this book is real, however obfuscated).

Hm…. What kind of error do we expect to catch by writing this kind of tests?

I often hear that the real reason for writing such tests is because of the future evolution of code. Once upon a time a simple getter or delegator method will be updated and then we will find out whether its current functionality has been broken. I do not share this view. First of all it goes against the YAGNI principle. I can’t give precise numbers but I would say that the vast majority (99%?) of such simple methods will not evolve. Which means that 99 times of 100 you wasted your time writing tests. Second, any mature developer understands that when introducing some logic into existing method she/he needs to review the tests and update them. Third, there is a chance that even if your unit tests won’t notice the change, your higher level tests will.
Fourth, the hope that the future change of such method will be caught by our test is… well, it is only a hope. The thing is that you can not predict the future evolution of the code. What if the code evolves like this:

Its not future evolution that drives unit testing getters/setters - its the code coverage gap that will allow far more complex logic to lie uncovered. I have a getter/setter unit testing chunk of logic that covers all simple properties of an entire class with a single line of test code. A class with more complex getters/setters might be covered with 4-5 lines of code.