I am a software engineer, database developer, web developer, social media user, programming geek, avid reader, sports fan, data geek, and statistics geek. I do not care if something is new and shiny. I want to know if it works, if it is better than what I use now, and whether it makes my job or my life easier. I am also the author of RegularGeek.com and Founder of YackTrack.com, a social media monitoring and tracking tool. Robert is a DZone MVB and is not an employee of DZone and has posted 107 posts at DZone. You can read more from them at their website. View Full User Profile

Writing Unit Tests Is Your Job, So Quit Making Excuses

08.16.2010
| 7465 views |
  • submit to reddit

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.

 

From http://regulargeek.com/2010/08/13/writing-unit-tests-is-your-job-so-quit-making-excuses

Published at DZone with permission of Robert Diana, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Luigi Viggiano replied on Mon, 2010/08/16 - 7:40am

I totally agree.

 There is a common metaphore about software industry and construction industry (which doesn't always fit very well). So that's why we have architectures, builds, models, design, patterns, blueprints, etc. Following that metaphore, we could say that unit tests are the pillars (and the scaffolding) of software, as they help you to build and to keep your structure up. Would you buy a flat in a building without pillars?

Developing means writing tests and the code (possibly TDD). 

Writing code without test (the "code and fix" way)... I call it "scripting". Good for a kennel or for a garage, not for the house inside which you want to live.

Steve Bohlen replied on Mon, 2010/08/16 - 11:23am

IMO much of this boils down to what the commonly-understood (among your entire team) meaning is for 'done'.  If by done we mean "written and compiling" then testing is indeed someone else's responsibility but if by 'done' we mean "written, compiling, and running with the minimum possible defects" then everyone needs to test their code SOMEHOW.

If this this by writing automated unit tests, then fine.  If this is by launching the software and clicking every possible combination of UI widget to ensure proper behavior of the software, then fine too (although much less efficient,  of course).

Someone pointed out to me quite a while ago that the proper definition of "a professional" is someone who takes full responsibility for their work.  How its even remotely possible to do this in the absense of testing your work to determine that its "correct" is something that this "profession" will have to come to grips with if it ever hopes to be considered a profession in anything other than name alone.

Jakob Jenkov replied on Mon, 2010/08/16 - 1:18pm

Testing is like quality control in a manifacturing plant. You prove to yourself that your code works, and catch a few bugs here and there too.

 

I've also heard the argument that "I don't write tests, because I don't write buggy code".
That argument completely ignores the proof-aspect of testing. Maybe there are no bugs
in your code, but how can your manager, or your customer know that for sure?

Stephane Vaucher replied on Tue, 2010/08/17 - 11:51am

I agree that a developer should test his code. Furthermore, he should automate his tests as much as possible. One additional I see concerns the capacity of a developer to adequately define the contracts he wants to test. Already, many developers have problems understanding the usefulness of pre/post-conditions and invariants (which all should be tested). I see two situations:

  1. A developer might not be thinking in term of contracts. Learning to think in contracts takes time and some never really invest in their personal development processes.
  2. A developer might not consider his contract official until he delivers a lot of code at which point, he might have already gone on to other things. In this case, bringing in another person, a client of this contract, can be very useful. If this client (eg. the guy in the next cubicle) defines what he understands of the contract, then I believe the contract would be better tested.

 A more fundamental issue (not a problem) with unit testing is that it is a verification step. It is not validation (especially if done by the developer). The added value of someone on the outside doing tests, is that he implicitly does some validation.

For those who talk about proving that code works. Technically, you cannot prove anything by testing, you can only try and find counter-examples (falsification). However, it is the only cost-effective way to develop software.

David Matějček replied on Fri, 2010/09/10 - 6:01am in response to: Steve Bohlen

... If this is by launching the software and clicking every possible combination of UI widget to ensure proper behavior of the software, then fine too (although much less efficient,  of course).

No,  it is not fine - it is not reliably repeatable and noone does these tests again and again with the same precision. This is both pros and cons, because automated tests cannot cover every state of the application (and the data). Quality code should be tested automatically in some reasonable granularity and a "distance of view" and also manually before releasing - then, a group of testers should consist from the people which know much about the functionallity to people which don't know anything about it (these people may even find very complex and improbable bugs).

Every bug found by the customer is very expensive:

  • customer will say the software is buggy (and maybe another sw is not) - bad for the reputation
  • customer reports the bug
  • your servicedesk accepts the report and posts it to your team
  • you have to reproduce the bug
  • you have to describe the bug to your project manager
  • you have to fix the bug (and you must not break up anything else!)
  • you have to create the patch or another version, write changelog, distribute (it depends on the severity of the bug, but who makes this decision?)
All these steps you have to make, but you won't see a coin from the customer, even more, your reputation is harmed!

King Sam replied on Fri, 2012/02/24 - 10:24am

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.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.