“Should I write automated tests for my code?”
“Yes, of course you should. Testing is good and we should all do more of it.”
This sounds reasonable, doesn’t it? I’ve heard many conversations that start this way, and I see a number of posts on Stack Overflow that are closed as opinion-based when people ask, “should I write unit tests for xyz?” The secret here is that the answer isn’t always yes, nor is it opinion based. The only person who knows the answer is you.
Why test at all?
Before talking about how you decide what to write automated tests for, it is worth remembering why we do automated testing. “Because my boss tells me to.” “Because the build will fail if my coverage is less than xx percent.” Ok, sure, but what is your boss’s aim when making you write tests? Automated testing provides predictable, repeatable tests every time they are run. So well-written tests are incredibly effective at finding regression bugs. For your stakeholder, it is about ensuring that you haven’t broken any of the existing behavior.
A Question of Risk
The question of whether we should write automated tests for a particular piece of code comes down to a question of risk. Looking at the code, we should consider the likelihood of a bug being introduced into that code. Let’s, for example, consider a simple Java object: is it worth writing unit tests for the setters and getters? This is simple code (generally one line) where the code is unlikely to change after initial development and almost all developers will find it impossible to accidentally introduce a bug.
Alternatively, let’s consider code that parses an xml file against a specific, custom schema. Now this is code that is likely to change and get more and more complex as the schema evolves, so here the likelihood of introducing a regression is high.
Next, we need to consider the impact of the bug. For this we assume, however unlikely, that a regression has been introduced into this code. What is the impact to the customer? What is the impact to your business?
Finally we need to consider the company’s appetite to risk? Are you in a safety critical industry? The level of risk you are willing to accept will be a lot lower than someone working on an internal system used by only a handful of people. Having considered all of this, is the risk greater than the company’s appetite for risk? If so, let’s write some automated tests.
When Not to Write Automated Tests
Let’s discuss a couple of examples of cases where we might not want to write automated tests. We have already mentioned getters and setters. These are great examples of code that doesn’t change often and is very simple; it’s easy to spot errors during review. Take a company intranet in a small company, for example. There might be 10-20 users who can, when spotting an error, walk over or message the developer and it can be fixed quickly. Here the investment in automated testing is not likely to see a return.
Get Started
I have made my case for how to handle automated testing here (and there’s more information on that subject in our recent webinar). However, I bet you have some code that you think I really wish we had better tests for. Let’s talk about kick-starting your test coverage for that code. Get a free trial or schedule a demo and we will show you how Diffblue Cover can give you the tests you want.
