Skip to main content

Unit Test are at least as Important as the Coding Itself

Posted by schaefa on October 12, 2004 at 2:08 PM PDT

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

As described in a previous blog about jUnit tests a unit test can test even advanced components like a transaction manager in a J2EE server. It just needs some imagination and persistence.

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.

Happy testing - Andy

Related Topics >>