Home » TDD » Excuses For Not Testing

Excuses For Not Testing

ppl-kid-044As I started my own journey into unit testing, I slowly began to realize that it was really easy to come up with reasons to NOT test my code as I was writing it, even once I understood what that was supposed to look like. The reason I think most programmers don’t unit test code, once they understand what it is they are supposed to be doing is that they don’t feel like they have permission.

To this I also answer, “How much permission do you need?”

Do you really need permission?

Do you ask for permission to compile and link the code?

Do you ask for permission to write every line of code to make the system do what it should do?

Do you ask for permission to run your code periodically to make sure it does what you had in mind when you wrote the code?

Do you periodically add code that makes you feel good but is not directly related to the task at hand? (Admit it, I don’t think I know of any programmer who doesn’t.)

Then why do we feel like we need permission to write unit test for our code?

Are you convinced that you need test?

We don’t write test code because we aren’t convinced it is necessary to do the job we’ve been given. We complain that our managers don’t want us to write unit test. But the problem is that you asked for permission in the first place. And, by asking for permission, you’ve basically told your manager that unit testing is optional. Your manager has said “no” because he thinks YOU think it is optional.

It’s not your manager’s job

It isn’t his job to understand that not testing will produce technical debt. He’s not even interested in understanding what technical debt is. All he cares about is this. When will this project be done?  When you say it is done, will it work as expected or will it have a lot of bugs that need to be fixed yet?

Most of the managers I’ve worked for in the past will accept whatever number I give them once they understand that when I deliver the software to them, it is going to work.  In fact, I’ve even gotten asked to do jobs BECAUSE my code tends to work more often than anyone else they know who could do the job.

Now, I will admit, that in some cases there are places where you’ve been explicitly told to not create unit test. But even here I will assert it is because someone asked management the question.


And so, we need to evaluate why it is we think creating unit test are optional. Probably because what we’ve been doing for so long seems to be working and, when we try to incorporate unit test, the process seems slower. And it is. Initially, writing unit test is slower just like writing using a new language or a new framework or anything else new is slower than what we know. But the ultimate efficiency that writing unit test as we code provides has been proven to more than offset the learning curve involved.

There is one other valid reason for not testing and that is, we simply don’t know how.  This is almost as big of a reason as not believing it is worth while.  But, I think if we thought testing was really worth while, we’d start testing and figure it out as we went along.

If you think about your career, I bet there are a lot of things you know now that you didn’t know when you started out.  The fact of the matter is, most of us learn on the job.  We start out with basic skills, but it is the day to day implementations that improve those skills.

Don’t let the good enough be the enemy of the perfect.

Don’t let the good enough be the enemy of the perfect.  Your first set of test will be garbage.  As you stick with it, you’ll wonder what you were thinking when you wrote your first test.  But this should not deter you.  This is what happened when you first started coding.  Maybe it is still happening.  No worries.  It is the practice that will make you better able to write tests and better able to write code that is testable.

And there is another reason we don’t test.  Most of the code you are currently writing simply isn’t testable.  But, that’s the subject for another post.

Other Places Talking About Testing Code


Other post in TDD
Article Name
Excuses For Not Testing
The primary excuse programmers give for not testing their code and why it's an excuse and not a reason for not testing.

Related Post

  • Why Johnny Can’t do Test Driven DevelopmentWhy Johnny Can’t do Test Driven Development Last week we looked at a few excuses developers give for not testing their code as they develop it (Excuses For Not Testing).  We finished that by mentioning that most of the code you […]
  • Dependency Injection Frameworks Are NOT Dependency InjectionDependency Injection Frameworks Are NOT Dependency Injection As you start your journey down the road of Unit Testing you will discover that part of what makes code testable is this concept of Dependency Injection.  As you explore further, you […]
  • Test Driven SpecificationsTest Driven Specifications Several years ago, long before the community was actively talking about Test Driven Development, I worked for a short time at a company as a “bug fixer.”  That was my role.  They […]
  • TDD Isn’t All About TestingTDD Isn’t All About Testing While the artifact of Test Driven Development is test code, what you get out of test driven development far exceeds the test themselves.  Maintainable Code By writing test first, […]
  • What Not To TestWhat Not To Test Many people believe that implementing Test Driven Development means that you need to have a test for every line of code in your system.  When  they start thinking about TDD in […]

About Dave Bush

Dave Bush is a Full Stack ASP.NET developer focusing on ASP.NET, C#, Node.js, JavaScript, HTML, CSS, BootStrap, and Angular.JS.Does your team need additional help in any of the above? Contact Dave today.

One Pingback/Trackback

  • Pingback: Dew Drop – February 26, 2015 (#1963) | Morning Dew()

  • Good point. But there is also another side of UTs. Some companies are so fixated they aspire to have 100% UT coverage and they make programmers write UTs for legacy code for no reason. Just for the sake of having UTs. I know some examples but not gonna tell names here 😉 Wonder if you had any simmilar experiences and what you think about this approach. I guess the 100% extreme is better than no tests at all, but it can make the developers very bored and feeling useless.

    • Actually, I think I’ll answer the 100% coverage question in a future post.

      Thanks for commenting.

  • My experience is that you don’t need permission to *write* unit tests. Everybody is *fine* with you writing unit tests.

    Just, you know, as long as it doesn’t take any extra time, or get in anybody’s way.

    If it takes you extra time, then managers and co-workers are going to be breathing down your neck. If you say “I’ve written the code, and now I’m making sure it works,” they’ll say “Well, but our other developers don’t bother with that. Check it in! Send it to QA! Ship it!” And make no mistake – while you’re building up your testing chops, or working with codebases that aren’t built for testability, it WILL take you extra time. Heck, even if you finish the whole thing in *half* the time, and you go, “Here, I have the code AND the tests,” then a lot of people will go, “Hmmm, but wouldn’t he have finished EVEN SOONER if he hadn’t bothered with the tests?”.

    And your test code can definitely get in other people’s way. If your coworkers don’t understand why you’ve introduced new layers of abstraction into their perfectly-clear code, they’ll be frustrated. If you sever dependencies that made quick hacking easy for other programmers, the next time they touch the code they’ll put it right back. If somebody else’s changes break the build because they haven’t updated the tests to match, it’s much easier for them to take the unit test out of the build then to figure out how to keep your work current.

    You don’t need permission to write tests while you code if testing is analogous to listening to music while you code – hey, whatever you feel works for you. But the moment you feel like you’re affecting your coworkers, the team, the schedule – well, that’s where the feeling that you “need permission” comes from. You think testing’s the right thing to do, but (a) it’s not entirely your call to make, and (b) you don’t want other people to be angry at you, or respect you less, for the work you’ve done.

    Now, framing this as “needing permission” is also problematic. You don’t want to have to get widespread approval every time you want to do decent work. But at the same time, saying “I don’t need permission” in the sense of “I’m going to go ahead and do this and if the rest of the team doesn’t like it, then tough beans” is not going to be a major step forward. Whatever accomplishments you manage, you’ll be clawing every step of the way, and you’ll be setting yourself in opposition to your team and your workplace.

    It’s a tough, tough problem. :-/

    • I enjoyed the tone of your comment 🙂

      Just a few comments. My experience has been quite different from what you’ve outlined. I brought testing to the organization I’m currently at, I’m still largely the only one doing it, but what I’ve found is that the other programmers are at least interested in what it is I’m doing. A couple are trying it out.

      Also, BECAUSE I test, MY code has fewer bugs. Don’t think that doesn’t get noticed. Even before I started practicing TDD, I tested (manually) frequently. As a result I got projects others didn’t because my code is more likely to work.

      I think many programmers think that the only thing that counts is how fast we can get the project done. But that isn’t what is most important to everyone. If you write code, but it has to cycle through several debug cycles before it can be deployed, or worse, has bugs that are discovered once it has been released to production, but you have a co-worker who took more time than he “should have” but the code works when it is released, or at least has a minimum of bug fixes that have to be implemented. Who is really faster?

      My mom had a saying, “The faster I go, the behinder I get.”

      • And I yours! 🙂

        Barring differences of personal experience, I agree with your comments, and your conclusions, and to a large extent with the original blog post as well.

        I think a lot of the issue is that many of the obstacles to testing are *cultural* obstacles. So if I, a programmer, believe that my co-workers care primarily about how fast I work, I’ll feel like I need permission to do anything that will take longer – EVEN IF my belief is entirely wrong, and my co-workers would understand my time/quality/maintainability tradeoff and agree with it. Basically, if there’s pressure felt *anywhere* in the system (and I do think there always is), and on the other hand you aren’t feeling that the culture has any particular respect or interest in testing, then it’s very natural to feel that testing is in conflict with the pressure and the culture – even if that’s not true at all! (The same thing is true of all kinds of other “quality/craftsmanship” issues – good naming; refactoring; more time spent on design; better documentation; better tools…)

        Which is why I agree with your conclusion: You can’t let yourself be stopped merely because you’re not certain of explicit support. You should go ahead; see what it takes to bring in testing; work the way you think a good, professional developer *should* work. You’ll be happier and less frustrated; your work will be closer to what you want it to be; and you’ll be bringing in positive change, even if it isn’t adopted by many others. I recently wrote a bit about this on my blog: ( http://todo-needstesting.com/2015/02/18/becoming-the-unit-tests-gal/ ).

        What I was trying to say, though, is that when you’re blazing a trail and being an agent of change, you also need to be alert, and notice when you’re stepping on other people’s toes. That’s the failure mode of “I don’t need permission,” and it’s important to watch out for it.

        • Maybe. I think we tend to THINK we are “stepping on toes” when we aren’t. You can be bold. The trick is to not be a jerk. Now, if your manager outright *tells* you he doesn’t want you to practice TDD and you can’t convince him that it will both be faster and produce better code in the long run, it may just be time to start looking for the next gig.