Why write this test?
Why should I write an automated test?
- to give myself a way to play with the code now
- to provide an easy way to investigate the code in the future
- to suss out any mistakes in a small knot of complex logic
- to force myself to think deeply about the code under test - only a test can cause one to continue looking at code past the point of boredom, which is necessary to find the nuanced bugs
- to continue asserting correct behavior long after one forgets about the code (and after leaving the project)
- to provide a dynamic documentation on intention
- to allow early performance testing (loop it a million times and see how long it takes)
- to sharpen my thinking about how this program will be used, how it could go wrong
- to force the contract to be as simple as possible. If it is hard to test, it will be hard to maintain and debug as well.
When might I not write an automated test?
- it will interfere with my flow and I cannot think of a quick way to get a test on it. Especially so when I'm working on a very unknown domain and/or technology.
- I am working with a complex stateful machine with a difficult interface, and the time to write a proper test would be exorbitant. Examples: database procedures, some fiddly web browser behaviors.
- when the coding is purely cosmetic or prose
- when I have sufficient initial tests.
- when refactoring code that has good tests
Believe it or not, there is a moderation to be had in testing - each new test carries weight and requires maintenance. The goal is to have the fewest tests with the best results.