Why Automated Software Testing Matters
In preparation for my talk next month at API Strategy & Practice, I’ve been thinking a lot about testing. Ever since I started writing automated tests a few years ago, I’ve found it to be one of the most useful tools for building maintainable software, but I still meet developers all the time who don’t write tests. Sometimes it’s because their boss (or the business team) won’t let them, sometimes it’s because they’ve never explained the benefits to them, and sometimes they just don’t care.
Fortunately, if the reason you’re not writing tests is one of the first two, there’s hope. You can point to real business value generated by testing, and it doesn’t take a huge software system or a long period of time to do so. Just remember that your time as a developer is valuable, so when you say that you can save yourself (and future devs) time, that has real dollars attached to it.
The Benefits of Testing
As you can see in the diagram below, the cost of writing no tests or of manually testing every case is lower initially. This is because setting up an automated test suite and getting developers familiar with a test-driven workflow will take some time. Eventually though, maintaining code without tests will lead to costly production bugs, and a manual testing strategy scales linearly (as you add more code, testers must spend more time doing tests).
Automated tests actually make maintaining your code cheaper, and here’s how:
1. Testing helps minimize the number of bugs released
Bugs are expensive and production bugs are the worst offenders. According to the IBM System Sciences Institute, fixing a production bug costs 100x more than fixing one at design, and over 15x more than fixing a bug at implementation. Automated tests can help developers catch edge-case bugs before they make it into production and force other developers to drop everything and fight fires.
2. Automated test suites help prevent regression
In addition to catching new bugs, a strong automated test suite can help prevent regression. As Eric Elliot says, “Manual QA is error prone…It’s impossible for a developer to remember all features that need testing after making a change to refactor, add new features, or remove features.” Testing becomes even more important when multiple developers are working on the project over a number of years. Newcomers can’t safely work on code that doesn’t have tests. While you can rely solely on manual tests, this cost grows linearly as the number of features increases, while automated tests can be written once and run very frequently for little to no cost.
3. Writing testable code improves overall quality
Code quality is another long-term investment that pays off for large software systems. Unit testing can dramatically improve quality when working with developers who are still learning about encapsulation, dependency injection, and scoping, and it is even more advantageous in weakly typed languages. When every new class must have unit tests, it forces developers to stop and think about their architectural choices.
4. Tests enhance documentation
Good code should be easy to read and at least partially self-documenting, but there’s almost always room for use-case based documentation. That’s where testing comes in. Good test suites give other developers (or maybe just future you) a better idea of what the code was intended to do.
5. Tests help guide code reviewers
Finally, as an important part of the development process, reviewing code can be tedious and prone to error. Having tests gives the reviewer a place to look for potential errors or missed edge cases. During code reviews, I often start with the tests, ensuring that they are well-written and don’t miss any important cases before I look at the actual code.
If you’re still having trouble convincing your boss or coworkers that tests are worth your time, reach out to me on Twitter. I’d love to pick up the conversation there.