Too many people are writing too many articles trying to direct others’ thinking on their own testing strategies. I am guilty of this and would like to contribute to reversing this trend.
- test until fear is transformed into boredom (Phlip Plumlee)
- if you don’t like something about the test, then try interpreting that as a sign of a design problem—usually an unhealthy dependency in the production code (The “driven” in test-driven development)
- faster-running tests tend to provide more value because they shorten the feedback cycle, so if you’re not sure what else to do, try to make tests execute more quickly (Lean thinking)
- when in doubt, write another test (Common sense)
If you do these things, then you’ll discover the tests that you need.1 You can do this.
In the final analysis, remember that we test in order to gain confidence and that they pay us to generate profit, not to write tests.2
If you’re thinking of a test that will help you gain confidence, then just write it. If you’re thinking of a test that’s clearly more expensive than dealing with the fallout from the corresponding defect, then don’t bother.3
You’ll sometimes feel strange. You’ll sometimes encounter choices that follow these guidelines, but feel wrong. When that happens, ask a trusted adviser for help.↩
OK, this part is complex, so it’s subject to endless debate. Even so, I think you can agree that most people, most of the time are paid by their employers to “produce value” and that tests are an investment in producing more value per unit time and not the valuable product itself.↩
If you don’t trust your own judgment yet, then give yourself the chance to gather more experience. And remember that good judgment comes from experience, while experience comes from bad judgment.↩