Top 10 Excuses Programmers Gives to Avoid Unit Testing

Though everyone loves unit tests and everyone agrees with the benefits they bring in, when the time comes to write them, you will see a lot of excuses, even from some of the more experienced and senior developers. At the heart of the problem of not writing unit tests or enough unit tests are two things, first is time pressure i.e. you don't have enough time to complete coding forget about writing unit tests. This problem comes due to erroneous estimation i.e. only estimating time for coding and not including unit testing as part of development.

This is also our first excuse, so we'll see it in a short while. The second reason is laziness and ignorance i.e. you don't know to write unit tests but don't put enough effort to learn the tips and tricks.  In this article, I have shared some of the most common excuses given by programmers for not writing unit tests.

Btw, if you are serious about Unit testing and just looking for a good resource to learn unit testing in Java then I highly recommend you check out Learn Java Unit Testing with JUnit 5 in the 20 Steps course by Ranga Rao on Udemy. It's a good course to learn JUnit 5 in easy-to-follow steps.

10 Common Excuses Programmers Gives to Avoid Unit testing

Anyway, let's continue with the common excuses programmers give to avoid Unit testing in their projects.

1. I don’t have time to unit test.

Really? But do you have time to fix your mistakes later?   The simple fact is that nobody, not even you, can write bug-free code.   Unit tests greatly speed up the time it takes to identify a bug because they narrow the suspect code down to a very specific unit.   

Other types of testing, such as Quality Assurance or User Acceptance Testing, identify problems at a much higher level, forcing the developer to spend extra time plodding through the various units looking for the root cause.

Unit tests can also serve as verification that the bug is corrected without having to go through the hassle of creating a new application build and deploying it for further testing.   Simply put, unit tests speed up overall development.   It might take slightly longer to create each new feature, but the development time for the entire application, from inception to delivery, is considerably shorter.

2. Programmers are paid to develop code, not to write a unit test or comments.

You must understand that unit tests are code. They are as integral to the application like any other piece of code you are writing and should be included in the original estimate and statement of work.  It might also help to mention to the client that unit tests lower both development costs (see the previous excuse) as well as maintenance costs.  If you are not writing unit tests, then you are doing your client an injustice by forcing them to incur extra expenses.

3. I am supporting a legacy application without unit tests.

That still doesn’t preclude you from writing your own.   Granted, you are not going to be able to go in and write tests to bring the entire code base up to an acceptable level of coverage.   You most likely don’t have the time or resources to do that.   But as support issues are raised, write the unit tests for any code that you modify.

When I am working on a support task, one of the very first things I do is write a unit test to recreate the bug.   When the unit test starts passing, I know that I have fixed the problem.   Now, not only have I resolved a bug, but I have added some unit test coverage to the codebase.  

Over time, this coverage will become more and more robust, and actually, reduce future maintenance costs by preventing the introduction of regression bugs. suck up and fix it

4. QA and User Acceptance Testing is far more effective in finding bugs.

No arguments there.   But Unit Testing is far more effective at preventing bugs.   Just because my smoke alarm is better at detecting potential fires doesn’t mean that it is safe to leave the stove on all the time.

Both QA and UAT are smoke alarms - they alert you to potential existing trouble.   Unit testing is turning off the stove when you are done - it helps you prevent trouble.  Unit testing, QA, and UAT are all important parts of the testing process, and they each play very different roles.  

Trying to replace one with another doesn’t work.  I wouldn’t release a project that was a good unit tested without QA, and I wouldn’t release a project that was thoroughly QA’ed without unit testing.

5. I don’t know how to unit test, or I don’t know how to write good unit tests.

Well, this is probably the most valid excuse that is out there.   The sad truth is that a great many numbers of developers and engineers do not know how to unit test.   I didn’t when I started.   And nothing discourages a developer more than struggling to write bad unit tests.   Luckily there are resources out there.

There are so many books, courses, webinars, conference presentations, blogs, etc on writing good unit tests that the inability to write them simply isn’t going to cut it as an excuse anymore.   When someone offers me this excuse, I don’t look at it as a roadblock, but rather as a teachable moment.

It usually only takes a time or two of seeing how well-written unit tests can help one develop code to turn them from the dark side. If you are serious about learning tips and tricks of writing good unit tests then read Test Driven. It will teach you how to unit tests and how to improve them slowly.

6. QA will do the testing

It’s not my job to test code – I don’t know at what stage a software developer decides that he can just throw code over the wall. If your job title was simple Coder then maybe there’s an excuse. But as your job is to develop working software, you need to be able to say that your code is functional.

7. I write GUI code

Some programmers give excuses that they write GUI code which is difficult to test and automate testing is even more difficult. Well, that's not true there are always some tools to test GUI e.g. if you are writing JSP or HTML using JavaScript, you can always test using Selenium and other similar tools. It is just a matter of finding the right tools.

8. Unit testing is slower and painful

It's true that if you have tons of unit tests in your project and if they execute as part of the build then it will take some time but with the advent of Jenkins and similar continuous integration tools, you don't need to worry about that.

Once you make a check, Jenkins can start building automatically and alert you if any of your existing unit tests failed without you doing anything. I suggest you reading Continuous Delivery by Martin Fowler to learn more about Jenkins and other tools.

9. Unit tests are hard to maintain

This one is certainly a genuine point but that is not good enough to deter you from not writing unit tests. Many developers who even write unit tests fail to maintain them and with more modification in code either those tests are not relevant or fail, but again with the automatic build and test tools like Jenkins, you will immediately know which tests need change as part of the recent change in code.

10. Unit testing is boring

It is boring only if you don't know how to write a unit test and how to test your code, but once you know that it is the most exciting thing for a programmer. You would love to write automated tests to test your code, you will hate the traditional main() method way of testing Java code because of the flexibility and power provided by unit tests. You can use even stubs and mocks to test something which is not yet available.


These are some of the most popular excuses for not doing unit tests, I am sure you have also used one of these excuses in the past. If not, then either you are a professional, disciplined developer or simply lying. Btw, unit testing is also one of the things which separate an average developer from the superstar developer. The latter always finds innovative ways to test their code automatically and more consistently.