Technical Debt in Unit Testing

The notion of technical debt has become quite famous to describe the effort that bad software quality induces on your developing new features on the long term. The higher the debt, the more difficult it is to maintain your software. By paying off debt however (fixing issues with your code quality), you can reduce this impact. This helps managers understand the impact of short-term fixes on the long-term success of your project, which is often not very tangible for non-techies.

But the same problem applies even more to unit testing. If you don’t do unit testing right, it’s in fact even better (and more efficient) to not do it at all (read more here: Why you shouldn’t write a single unit test, before you know how to do unit testing right)!
So let us try to pin down this notion of technical debt in the context of unit testing:

The Cost of Bad Unit Tests

First of all, we have to think about the money we lose when we define bad unit tests. I’ve detailed the characteristics of a bad unit test in this article already: 5 Bulletpoints how to spot Bad Unit-Tests. Essentially, a bad unit test does not help you identify bugs, but just cost a lot of time for keeping this test up to date. As someone has to pay you money to spend time on these tasks, this increases the cost of unit testing in your project in the long run. If you don’t apply a structured method such as equivalence class partitioning (read more here: 2 Methods that help you save 60 % of your effort in Unit Testing) to define your tests, it might also happen that your test suite is missing some crucial tests that cover an essential part of your software. As a result, you can might ship your software with severe defects, which costs you a lot of money in production.

The Cost of Bad Unit Test Code

Most money is however wasted on bad unit test code. If you don’t understand what’s going on in your test code, or even how to adapt it, you regularly run into the following issues: How to identify whether a failing test is actually due to a bug in the software, or just a bug in your test code? How to find out which parts of your test code you have to adapt once the underlying requirements change? How to use test code to locate defects? All these issues usually cost a lot of time (and thus money) if you have written poor test code. Unfortunately, they happen on a regular basis, as the whole purpose ofunit tests is to identify and locate defects in your software, and keep tests up to date.

Paying off Technical Debt to make Tests meaningful again

Defining technical debt however has no meaning without specific measures that you can apply to pay off this technical debt. By spending time on the following tasks, you can actually pay off the technical debt in your unit tests and reduce the effort in the long term:

1. Delete bad test cases. By regularly checking your test suite for unnecessary and outdated unit tests, and deleting those test cases, you can reduce the effort you have to spend on maintaining bad unit tests in the long term.
2. Use practice-proven methods to define new unit tests. Read more on them in this article: 2 Methods that help you save 60 % of your effort in Unit Testing
3. For improving you unit test code, you can apply a number of best practices. I’ve summarized the most efficient ones in here: Clean Unit-Testing – die Kunst, wartbare Unit-Tests zu schreiben. To make it easier for you to apply them to your unit testin project, you can also use the following checklist: The Ultimate Checklist for Better Unit Testing

The next time you have to explain why you have to spend time on improving your unit tests – try to use this notion of technical debt for unit testing. And let me know the reactions in the comments section below.

Image by macrovector on Freepik