Writing Unit Tests Is Your Job, So Quit Making Excuses

For whatever reason, I have seen the topic of unit tests appear in my daily reading frequently the past few days. Because I am in that kind of mood, I wanted to rant on unit testing. First, let’s look at some of the articles that caught my attention. One article talks more about the psychology of unit testing and starts with an interesting paragraph:

The philosophy of economics, and psychology, and morality, all overlap in studies that show how people will readily abandon moral responsibilities if they are given ways to avoid the stigma of doing so. This leads me to feel more justified in my belief that programmers do a poorer job of reading, understanding, and implementing a specification when someone else has the responsibility of verification.

To put this more simply, if you do not have the responsibility to test your own code, it will be of lesser quality. I have seen this in practice, and I would have to agree. Code that does not have unit tests almost always has more defects than code that is unit tested. So, why do programmers avoid writing unit tests? There are plenty of excuses, and the second article has a good list of them. From that post comes my favorite excuse:

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 than 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.

Read that last sentence again, “your job is to develop working software, you need to be able to say that your code is functional.” As a software developer, can you really say that you have done your job without providing unit tests?

If you are not writing unit tests, you are not providing any proof that your code actually works. You are doing yourself a disservice and any developer that maintains your code will complain at length about it.

Another classic excuse is that it takes too much time to write unit tests or there is not enough time in the schedule to write the tests. The schedule excuse appears a lot as project scheduling is never as good as we would like. When I first started writing unit tests ages ago, I believed that the schedule excuse was OK. As I continued through my career, I realized that there were more defects in my code that did not have unit tests. I also realized that fixing the defects was harder if there were not unit tests. I know this is anecdotal evidence, but when so many people in our industry say the same things, the anecdotal evidence becomes more than just coincidence.

An interesting side benefit of creating testable code is that the design typically ends up easier to deal with. I think this has to do with the fact that your code becomes more component-oriented. You need to break many of the dependencies that quick-and-dirty coding tends to introduce. If your code is hard to test, it could point to design flaws or at least unnecessary complexities.

So, if you are a software developer, even if you are just learning the trade, test your code. It is your job to show that your software is working. Quit complaining, get over it and start writing unit tests.

Enhanced by Zemantahttp://static.zemanta.com/readside/loader.js

10 thoughts on “Writing Unit Tests Is Your Job, So Quit Making Excuses”

  2. I’m a bit on the fence with this one.

    I do agree that testing on various levels should be built into the code from the start, but many shops don’t provide the proper environment/culture for it.

    I know that comes across as another excuse, but try coming to my company and explain:

    1.) why the schedule has so much time devoted to testing (hell we hate showing the hours for requirements gathering )
    2.) nearly everyone either can’t agree on testing methodology or are at the same level in their experience with it.

    But on the flip side of the coin, I take the “how important is it” test. If I’m doing a project for a client or for a large system, I’m MUCH MUCH more inclined to have some type of unit tests (or semblance of them). However if it’s a small project or one that’ll go through many iterations very very quickly, I’m less likely to do so.

    _Why was well known for not writing tests for many of his very popular ruby libraries, as he didn’t like unit testing and had some valid points as to why.

    Like

    1. Bdog2g2

      For most corporate environments, unit testing is extremely important because the original developer is typically not the same person maintaining the code after 1 year. Regarding the testing methodology and culture, that is definitely a problem. If people cannot agree, then maybe the decision must come “from above”. This leads into cultures that do no support unit tests. You need to get management buy-in for unit testing as a requirement or heavily recommended.

      Like

  3. The ironic thing is that only developers/leads/architects who are really passionate about their work will ever read this. There’s no way to reach the huge number of devs who don’t really know the benefits of unit testing (or any QA processes) yet. After about 2 years of convincing I’ve finally managed to show my superiors some important benefits of UT and I feel good.

    My answer to people who say it takes too much time to unit test is ‘You’re either doing it wrong or your design totally sucks’. I do agree with Bdog2g2 that devs do need a supporting environment as well.

    You can’t really do much about the bad apples. There will always be enough to ruin the pie.

    Like

    1. Elroy

      It is wonderful that you were able to convince your superiors. That is how the knowledge spreads. Those people who have not really learned or heard about the benefits are probably developers that do not read many books or blogs. They will be very difficult to convert. The only thing you can do is keep teaching people with every team you join.

      Like

  4. I only recently started using unit testing rigorously. I think I would have been much more productive in the last decade had I started employing them earlier.

    Like

    1. DGentry

      I would agree 🙂 I was not a good testing developer before I discovered unit tests. I could code, but I hated clicking through the applications to test my code because I would have to do it again later when I made changes. When I learned about unit tests, I fell in love with being able to test my code with a single command. I also saw how some of my code changed in order to make it testable. It is an interesting process.

      Like

  5. Test do not generate business value. They help to reduce development costs.
    They are justified as long as fixing regressions in project is more expensive than maintaining test suite.

    Like

  7. I absolutely agree with you Rob.

    Rinat, I think that unit tests do add business value. Automated testing in my experience does provide a business benefit because the custom gets a better quality outcome for about the same amount of time considering that limited or no testing causes more expensive delays down the line.

    Like

Comments are closed.