Tuesday, February 12, 2013

The main obstacle in writing unit tests

I am an advocate of unit testing and try to implement them as much as possible. In the beginning of a software project, it is relatively easy and most of my tests pass. As my code gets bigger and bigger, tests start to fail. What is interesting is that the pass/fail behavior is not smooth, i.e. the number of passed tests might be lower than a month ago although I have written many new tests:

As my unit test base gets larger, the main reason of failure becomes out-of-date tests that need to be updated to match the design. In the messy middle portion of the project, I realize that I spend more time updating tests than fixing bugs found by my tests. There is so much oscillation that I'm on the verge of loosing hope and think about abandoning unit tests. If I persevere, I eventually reach a point where all my tests pass, but it takes a lot of will power. That is for me the main unit test challenge.

Bonus tips:
  • How do you know if you have good coverage for your new code? Try removing a line or a constraint check. If all tests still pass, you don't have enough code coverage and you probably need to add another unit test.
  • Testing only public members leads to tests that can withstand constant code refactorings and internal implementation changes, while still making sure the overall functionality stays the same.
  • When approached poorly, unit tests can achieve the opposite results, stealing valuable time and complicating the testing process.

No comments: