If you work on rocket engine software or some kind of life-critical software, you can ignore this post.

Still here? I wanted to sum up my thoughts on testing, as someone who works on fairly ordinary software from day to day.

I think testing is very beneficial, and software without tests is not much fun to work on, because you’re afraid of breaking it; and maybe not even knowing that you’ve broken it!

However, I also agree with DHH’s post on test driven development: http://david.heinemeierhansson.com/2014/tdd-is-dead-long-live-testing.html that the rhetoric has gone too far in some circles.

I think it’s best viewed as a graph:

Initially, adding a little bit of testing gives you big benefits: first and foremost because now you have a test framework to hang new tests on, which is a great way to grow it.  As you discover bugs, add tests to ensure they never happen again!  This keeps the test suite growing organically, and gives the tests a sense of purpose, rather than just slogging through the whole codebase, adding tests for everything.

As you add more and more tests though, the returns on time/coverage/effort probably begin to flatten.

This is – very roughly – in line with the Pareto principle, also known as the 80/20 rule.  In the case of testing though, my feeling is that it’s often better to skip that difficult 20% part – unless you have a lot of extra time on your hands.

Like most everything else about software development, it’s driven by the economic necessities of the people and businesses involved, and therefore there are compromises involved.  Aiming for the maximum amount of benefits with the least amount of coverage is the sweet spot for testing.