Top Five Excuses For Not Unit Testing

People who don’t unit test always seem to have an excuse why.  Some of them are understandable misconceptions about unit testing.  Some of them are ridiculous.  But I have yet to hear an excuse that I would consider valid.  Here are the top five excuses I hear, and my responses to them.

I don’t have time to unit test.
Really? But you have to 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 considerable shorter.
The client pays me to develop code, not write unit test.
News Flash - Unit tests are code.  They are as integral to the application as 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 cost (see previous excuse) as well as maintenance cost.  If you are not writing unit tests, then you are doing your client an injustice by forcing them to incur extra expense.
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 code base.  Over time, this coverage will become more and more robust, and actually reduce future maintenance costs by preventing the introduction of regression bugs.
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.  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 well unit tested without QA, and I wouldn’t release a project that was thoroughly QA’ed without unit testing.
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 number 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, 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 any more.  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…

Are there other excuses out there?  Absolutely.  But they are just that - excuses.  I have yet to encounter a valid reason to skip unit testing.  If you think you have one, post it here.  I look forward to the challenge of changing your mind! :)


Returning visitor? Please login or register.

Great post Paul.  Unit testing is critical on every project.  Even if you cannot automate the unit tests there is no excuse for not manually unit testing.

I would love to hear your thoughts on an older post of mine discussing unit testing.


John Moore Posted on: Apr 16, 2009 at 06:31 PM

For me there are at least two possible valid reasons not to write unit tests:

1. If you don’t believe/plan/feel able to keep maintenance of unit tests in the long run. This one is soft, but I believe developers can’t be forced to write good unit tests. If your team don’t believe in value unit testing bring them they’ll do poor job creating them and it’s most likely not worth the effort.

2. If value unit testing brings to the project is lower than cost of developing them. “Good enough” doesn’t have to mean “exceptional” and sometimes investment into quality doesn’t bring any profit.

Pawel Brodzinski Posted on: Apr 17, 2009 at 04:19 AM

Pawel, you are correct.  If the team doesn’t believe in the value of unit testing, they will do a poor job creating them and they are not nearly as effective.  This, however, is a problem with the team, not the unit tests.  If the team doesn’t put forth the effort to write good code, well that isn’t a very good team in the first place, now is it?

In regards to the blogcast that Joel Spolsky had, there are several issues I take with it.  First of all, he attempts to lump all automated testing into unit testing, and this is simply wrong.  He says at one point that he is worries about moving a menu placement and breaking a lot of UNIT tests as a result.  It sounds to me like he is referring to automated integration testing, not unit testing.  Unit testing focus on a much lower level of code.  For instance, you could write unit tests that test how the menu code is created.  But you would rely on QA or UAT to determine if the menu is in the correct place on the resulting view.

Second, Joel also seriously over exaggerates the extent of the number of unit tests that have to be written.  If he has to write 1000 unit tests for a single new feature (as he states in his example), then he either has a very, very poorly designed feature, or very, very poorly written unit tests.

In my experience unit tests very rarely increase future maintenance and development time.  This is a misconception, and one that many people continue to believe by raising their own confirmation bias to an art form.

Paul Bourdeaux Posted on: Apr 17, 2009 at 03:01 PM

Hi John,

I enjoyed your blog very much, and I agree with much of it.  One thing that I would add is the importance of continuous integration.  You briefly mentioned it, but I cannot stress enough how much easier this makes life for the development team.  If unit tests are run with every commit, you have incredible fast feedback regarding the health of the unit tests.  The sooner you know that a tests is breaking, the easier it is to fix.

Paul Bourdeaux Posted on: Apr 17, 2009 at 03:08 PM


I wouldn’t put equals sign between “writing good code” and “creating unit tests.” It’s possible to create great code without a single unit test. It’s possible to have code with a lot of unit tests which is a piece of crap.

Of course when a team, or a part of a team, doesn’t believe in unit testing it’s a problem with people, not with unit tests. This doesn’t automatically mean the team sucks though. And this does mean implementing unit testing in this very team won’t bring much positive result.

This argument isn’t just about unit testing. You can safely generalize it to almost any software development practice. Code review, coding guidelines or pair programming (just to take three top of my head) won’t work either when people don’t believe in them.

Having said that, I don’t try to advocate for not writing unit tests. Actually we create them with target coverage 100% of public interfaces. On the other hand I resigned from doing code review since people lack will to do it. They’d probably do it if they had, but it wouldn’t bring great results. A case is similar.

And nonetheless they’re a great team.

Pawel Brodzinski Posted on: Apr 19, 2009 at 04:14 AM

ya, its nice opinion.
<a >Office Jobs</a>

Christopher Posted on: Apr 20, 2009 at 05:39 AM


Your point is well taken - the entire team must sign off on a particular facet of software development in order for it to be successful.  Your comparison to pair programming is a great one - we are split on our opinions of that here in my office. 

And choosing not to write unit tests does not equate to bad code, nor does writing unit tests equate to good code.  But I have seen better results over the long run from teams that practice unit tests than from teams that do not.  If faced with a team member who simply didn’t believe in unit testing (which has happened), I do my best to show them the benefits of unit testing first hand.  Sometimes it takes a couple of projects for them to see the light, but I have yet to work with an engineer who didn’t eventually turn from the dark side…

And truthfully, I suspect that you are part of an amazing team. ;)

Paul Bourdeaux Posted on: Apr 20, 2009 at 09:48 AM

“An ounce of prevention is worth a pound of cure”

Max Pool Posted on: Apr 20, 2009 at 11:20 AM


Well, it’s shocking and needed an immediate attention to sort out at the earliest.


Office Jobs
Jobs in the Office
Office Jobs Advice
Information for Office Jobs

Office Jobs

Garcia Posted on: Apr 21, 2009 at 12:11 AM

adunpjyk Posted on: Jun 20, 2009 at 11:40 PM

wjriywdz  utlegvwd tjtqynxd xbgycehv sapfifjw

jeqlqucq Posted on: Jun 20, 2009 at 11:40 PM

Leave A Comment

Please help us stop spam by answering the question below: