I recently published the article There is no Agile, in which I stated that the principles of ‘Agile’ are nothing more than “a collection of good ideas, based on years of collective experience, for improving how we do our jobs.” As an example, consider testing. Thorough testing is a ubiquitous principle of ‘Agile;’ thus, by logical extension, writing tests is a fundamentally important part of writing software well.
In short, if you write software, and you’re not writing tests, then you’re not doing your job.
I don’t mean not doing your job like a waiter who doesn’t take your order quickly enough; I mean not doing your job like a surgeon who operates without washing his or her hands. As in completely unacceptable performance.
As a corollary, if you’re not writing high quality tests, then you’re doing your job poorly. If you don’t achieve appropriate test coverage then you’re doing your job poorly. If you focus excessively on verification, and ignore the other benefits that tests can provide, then you’re doing your job poorly.
Several authors and accomplished software writers have cataloged the ways that thorough testing will lead to better design, the ability to refactor, improved resilience in the face of changing requirements, fewer defects, etc. In order to justify not writing tests the costs would have to overshadow these advantages.
I can’t think of a valid argument for not writing tests, although I’ve heard many attempts:
- “It takes too long.” Consider that around 75% of the time spent on average software projects is bug-fixing and maintenance.
- “This code won’t change.” It will. And it should.
- “I know my code works.” Will it work with my code? With the code you write six months from now? When the functionality changes? (see above)
- “It’s a prototype.” Fine. Throw it out when you’re done and use what you learned to write tested code.
- “It’s not testable.” Unlikely. Far more likely you simply haven’t though of a way to test it.
- “That’s what QA is for.” This statement shows so little respect for the people you presumably work with it warrants no response.
- “I can’t be bothered.” McDonald’s is hiring.
In my experience, people who denounce the value of tests are nearly always people with little experience writing tested code. It’s time we stop allowing ourselves to determine how we do our job based on who has the biggest ego, who can shout the loudest, or who is the most resistant to change.
All this leads to the question that every single person reading this should be asking: writing high quality tests can be very difficult; how do we teach that?
