Andreas Schaefer's Blog

Unit Test are at least as important as the Code itself: Part II

In one of the comments to the original blog about Unit Tests I was told that tests can never be as important as the code itself. I want to use this opportunity to explain a little bit more why I still think that developers should pay way more attention to testing even thought that test code is not delivered and/or sold.

In our complex world many items are more than what is visible to us and we often take these hidden things for granted. For example our good old money the paper bills are quite simple and consists of a piece of paper with the issuing country, the currency and amount printed on. The money is a proxy for a value we can use to exchange against items we like to buy. Despite the fact that our money is pretty worthless the general acceptance as a proxy of a certain value makes it so sought after. In order to keep our trust into our money intact countries spend a lot of efforts on fighting counterfeiting. This hidden service, and other services, keeps a printed piece of paper valuable. In contrast during the German Hyperinflation in 1923 the government started to print excessive amounts of money inflating their currency and making it more or less worthless.

Now when I choose software I expect two things:

• The software is doing what it says it is doing
• The software is working and does not harm my hardware, software or any data

Of course, there are more attributes I am looking for like the price etc but these two are very important. Like with money these two attributes determine the value of the software and my level of confidence into it. If software is doing something else that what I need it for or when it is buggy or even worse compromise my computer and data it render useless to me. In my point of view it does not matter how much time and effort was put into its creation. In addition most of the software I am using has a certain history allowing me to choose certain software based on the experience I had with previous versions or with other software from the same vendor. So I dumped the Internet Explorer and replaced it with Mozilla's Firefox even thought it is a beta version.

Unit Tests helps to make software reliable, helps to detect problems early and prevents regression. Tests do not guarantee a bug-free software but it makes a huge difference in the user experience with the software when bugs only appear once and overall the product seems to be quite stable. If tests are writing in a test-driven-development style meaning you write your tests ahead of the actual coding it helps you to design you code towards the client's needs. Finally, late testing like done by the QA department or the customer costs more time and money that when it would be found by the developer. With it the costs of software development can be reduced with good and early testing and frees the developer to work on new and exciting features rather than fixing nasty bugs.

To make a long story short Unit Tests are a part of the software shipped even the test code is not part of it. The tests influence will be visible in the product in a very pleasant experience improving the value of your software more that one might think. Good tests will change the delivered code in many ways and so, indirectly, it is shipped, too. In case the tests fail to do so there are most likely not worth the disk space they are stored on. I do not deny the fact that the success of software does not only depend on the reliability of but also on the marketing and timing. Nevertheless it would be a pity if you loose customers because of buggy software after you got their attention and willingness to give it a shot.

Comments

• Unit tests are a great way to test the contract of your methods. You can actually test how your code behaves when fed with parameters that are close to the edge of said contract.
  When coding in a team unit tests are essential. If you change the behaviour (and maybe the contract of the method), running somebody elses unit tests give you an idea how much code of your team you will break. The alternative to that is to catch these issues during system testing. But in that testing stage it is unlikely to find elusive bugs since you feed the system with the same values over and over again(system testing is very much routine; people have their test plans and stick to it).
  Selling unit tests to PHB is another problem. Usually I try to convince them by telling them that we save a considerable amount of bug testing and that we'll catch a couple of elusive bugs before they make it into the product. And I have a couple of examples stolen from projects that went south due to lack of unit testing.
  Selling unit tests to the techies is another beast. Thankfully, I don't have to argue. I can tell them to do so:)
  Everybody writes short snippets of code in order to find out if that recursive method that spans 5 classes and 40 methods remotely does what it is expected to do. If you organize these snippets into a unit test(just an interface away with JUnit) then you can repeat these tests as part of the build process. Outcome WILL change with each new 3rd party lib, new JRE, new servlet/EJB container and whatnot.

  Posted by: bfandreas on November 05, 2004 at 02:40 AM

• Test Driven Development isn't Unit Testing.

  It is much more fine grained. 'Proper' (old style) Unit Testing is fairly coarse grained... eg Make an object, do a bunch of stuff to it, check if it fell over.
  Whereas TDD (especially with JUnit) is about exercising Methods in isolation.

  I think its a shame, the original TDD (or TDD-lite) is a good concept. Figure out what tests you need to write, then figure out what you need to know to write them. It kind of 'explores' the problem domain, and much earlier than most people are used to doing. In practice however it gets dragged into the whole sloppy coding morass that is XP.

  The key difference being that in theory you're supposed to *think* about the tests in advance. However with XP thinking before doing anything is frowned upon, and you're supposed to boldly leap in, boots and all. Shame that.

  Posted by: rickcarson on December 01, 2004 at 07:13 PM

• There seems to be a growing movement to ship unit tests with commercial software or at least be able to show one's testing effort with various coverage reports.

  -- david
  www.testdriven.com
  www.agitar.com

  Posted by: dvydra on December 01, 2004 at 08:51 PM

This work is licensed under a Creative Commons License.