If you’ve made it this far into our unit testing guide, then you probably agree that writing unit tests is a good thing. We’ve covered a few tricks in writing tests for code that is hard to test, to hopefully remove some of the barriers that might keep you from writing tests. But often, developers still don’t write as many unit tests as they should. Why is that?

Before we address the reasons that we often hear for not wanting to write unit tests, let’s pause to remember why we write tests in the first place. We want to ensure that our code works today, and we want to prevent it from breaking in the future, whether a breaking change is made by a teammate or by our future selves. 

By writing automated unit tests and running them as part of every build, we can ensure that we aren’t inadvertently changing the behavior of the code. As Martin Fowler has aptly pointed out, “Imperfect tests, run frequently, are much better than perfect tests that are never written at all.”

Top “Why I’m Not Writing Unit Tests” Excuses

1. “I don’t have time to write all of these unit tests.”

How long does it take to write one unit test? Sure, the first unit test in a project is the hardest because it requires the infrastructure to be in place. But after the first one is finished, the simpler unit tests that come after can take under five minutes to write.

Just because you don’t have time to write tons of unit tests doesn’t mean you have a good excuse to not write any. Developers often plan to come back and write unit tests later, but this rarely actually happens. The time pressure making it hard to write a test suite won’t evaporate at a later date, so find a few moments here and now.

2. “It’s ok if I don’t write unit tests; QA will catch the bugs.”

Having a good independent QA team does means that any bugs left in early on won’t reach the customer. However, the turnaround time for the bug to be found, reported, triaged and returned from QA to the developer to be fixed is definitely going to be measured in days if not weeks. If the bug gets found as part of the build process it is much quicker, easier and cheaper to fix.

Let’s also remember that QA will report a bug based on the user behavior. Unit tests help the developer understand where the bug is, and therefore what should be fixed. If QA report a bug talking in UI terms on a big product with multiple interacting parts you may spend a significant amount of time finding the root cause of the bug. However, if a unit test fails, you instantly know where the issue is.

3. “Unit tests slow down development due to maintenance.”

It’s true that we need to look after our unit tests. They will need updating, adding to, and sometimes replacing as the product grows and changes. It is worth remembering that every time a unit test fails, it means that the behavior of the code has changed. Each time this happens, you should be making a conscious choice about whether you have introduced a bug or a desirable change in behavior. Each change will still give you some work, but knowledge is key: Without the unit test, you might not know that you have changed the behavior of the code.

4. “Our unit tests are unpredictable. Sometimes they fail for no apparent reason.”

It’s painful when this happens, and you can count on getting a new failure just before you want to ship a product. The real question is: is your product unpredictable, or is the test wrong? If it’s your product then you’re going to have the same challenges debugging customer issues that you do debugging your tests, except you might not have access to the customer environment. Either way, this is something that needs investigating and fixing.

As we’ll discuss further, when you’re unit testing, perfection is not required. Instead, get on with writing a few test cases and see the rewards they grant you further down the line.

Check out the rest of the guide: