Andreas Schaefer's Blog

Unit Test are at least as Important as the Coding Itself

Tom talked in The Problem with Unit Testing about Unit testing. Even though that I agree with most of it I disagree with the view that Unit Testing is only a safety net. The only person responsible of the quality of the software is the author himself and he/she should be held accountable for that. Therefore, in my opinion, writing Unit tests is not just a good habit but an essential part of the deliverables. Ommiting the unit tests is like designing a car engine and installing into the finished prototyp untested. Nobody in the car industry would do that so why are developer still doing it?

The basic problem of unit testing is that managers do consider unit tests as a nice to have item rathar than an essential component and leave it to the developer to decide if they want to do it or not. So the experienced developer might say that he does not need because he knows what he is doing and the rather unexperienced developer does not know about Unit tests or does not know how to code it. Nevertheless no developer is immune against bugs and regressions and so should write units tests. It also helps to reduce regressions and so the gain from Unit tests increase every time a change is made without a regression. I think of a software developer as a professional that delivers good software so that he/she can be pride of. I would be embarassed, and was quit often in the past when I delivered software untested, if a stupid problem would make a product fail because of my bug. We, the software developers, should take pride in our work and not let allow our bad work habit getting us a bad reputation like, for example, a lawyer or is it already too late for that?

Here is a list of items I think are important for Unit Tests:

• Unit tests are tests and probably the best tests you can get because it is on a pretty low level so that more code can be covered and fewer bugs can hide
• Unit tests are written by developers which now their code the best. Of course, developer tend to write units around their bugs but, I think, they can learn to be more malious with their code
• The time spend on a unit test (except for a prototyp that is actually thrown away later) is saved before the software is delivered and the savings from that test will only grow over time
• Unit tests will let a developer write more new code than without
• Unit tests can test nearly everything even a GUI

Everything we code contains bugs and all the tests we can come up with leave a chance for a bug to remain undetected. The same also applies to the car industry where even Honda makes recalls of their cars to fix a problem. Please remember the 80/20 rule saying that if you can catch 80% of the bugs with 20% of the effort we are in good shape and will do great. This can only be accomplished if there is a unit test framework available, which should be setup when the project starts. In addition such a framework will remind developer to write unit tests and eliminates many of the exuses not to write them.

The test-first or test-driven development does not only deliver unit tests but also use them to help design your code because the tests act as the devil's advocate making sure that the design works when used in a client. The unit test is the client. If a developer cannot work this way then do not but still should write the unit tests later.

Comments

• I suspect Andreas and I are in "violent agreement", which is what happens when two engineers loudly arguing suddenly realize they are on the same side of the argument. I am a very big proponent of unit tests but, like Andreas, have had to deal with organizations which don

  Posted by: tball on October 12, 2004 at 02:20 PM

• I suspect Andreas and I are in "violent agreement", which is what happens when two engineers loudly arguing suddenly realize they are on the same side of the argument. I am a very big proponent of unit tests but, like Andreas, have had to deal with organizations which don't consider them a developer engineer's responsibility. The point I was (poorly) trying to make is that if unit tests had another name which didn't sound like a QA department's responsibility, we would have more support for our creating and maintaining them. I just haven't been able to come up with a better name. Apparently "safety net" is a bad choice. :-)

  Posted by: tball on October 12, 2004 at 02:22 PM

• I am glad to hear that. I also use this blog as an opportunity to talk about the importance of unit tests and that the developers are responsible to provide them. In the past I saw too many managers complain about buggy code delivered late and still refusing to give time to setup a unit test framework and to require unit tests as part of the deliverables. Nevertheless this is not an acceptable excuse for developers not to write unit tests because he/she should know better. The name unit test probably should not be changed but people should be made aware of that testing does not start with QA and that every contributor has to provide his/her part.

  Posted by: schaefa on October 12, 2004 at 03:16 PM

• Unit tests can NEVER be more important than the code being tested for real code.
  For your pet hobby project maybe, but when there's money involved the only thing that counts is the deliverable code which gets sold to the customer.

  Test code (and other test mechanisms) help a lot to make that deliverable code better but they are NOT more important.

  If you have 10 hours to build something and you need 5 hours to make the test code and 7 to write the production code your manager won't be happy if the production code is 2 hours late because you considered it less important than the test code...

  Posted by: jwenting on October 13, 2004 at 11:18 PM

• Balance!

  That's what I want to say.
  

  Posted by: hotjuneshen on July 29, 2005 at 01:02 AM

This work is licensed under a Creative Commons License.