Unit Testing - Good for All

I am an avid unit test supporter. For my own projects I write unit tests at all levels for all classes; I don't consider a class complete without a matching unit test. But I get the bigger picture: because it's my code I see it from the perspective of developer, architect, designer, tester and stake holder. In the corporate world things are a little different. Unit testing is starting to see wide acceptance, but at best as a necessary evil.

• The Developer sees it as a waste of development time. A working reproducable unit test can easily double the testing time.
• The Architect ignores them as not his problem.
• The Development Manager has to continually balance schedules and decide whether there is time to write 'correct' tests.
• The Designers don't want to know about them.
• The Project Manager does not want to have to justify the push-out to the schedule they cause.
• The Test Manager is only interested on how many tests there are and that they have all passed, and is generally only interested in adding to that tally.
  
• The Stake Holders see no value in them and resent the potential effects to time and budget.

For unit testing to reach its full potential, each and every group needs to see the value to themselves and the project as a whole.

• The Developer has the involvement in creating and maintaining unit tests. Surprisingly they often feel that it gives them the least gain. This could not be further from the truth. Changing their development style encompass unit testing provides important of gains:
  1. Perspective: The developer gets to exercise all the functionality of any given class in the way that they see its clients using it. By writing a unit test for each class before it is ever called from elsewhere, you get the all important second perspective on the code design phase – often revealing aspects that could be changed or improved.
  2. Javadoc: Unit test code works well for examples of use in the Javadoc.
  3. Self Documentation: Developers commonly use classes and packages by example. The best and least likely to be abused examples will be in the unit tests attached to the class. If you need to use the target class in a different way, update the unit test first - both to test the usage and to provide a valid example for the future.
  4. Level of Confidence: The developer can release the class for use knowing it meets a clear group of tests. Since these tests run regularly, they can also be confident that changes to the code or dependancies do not effect the expected uses for the class.
  5. Issue Resolution: When problems are reported in testing, reproducing them can be quite convoluted. By updating the unit test to reproduce the error, it is easier to debug and prove fixed.
  6. No Error Deja Vu: In projects without unit tests it is common to have a problem fixed then come back on the next release. If you have added unit tests to isolate problems before resolving them you can be confident they will not return without being noticed until too late.
• The Architect should consider unit tests as part of the overall technical design. Current practice is to have the developer totally in control of unit tests. This works fine for smaller systems and stand-alone classes. It is less than practical in real-world corporate projects where the information required to run a particular test is much larger than the test itself. To test a close account service, the unit test needs to open the account and set conditions to both stop closure (outstanding invoices) and to allow closure again (cancelled invoices). If left to the developer this can be a daunting task. Don't leave your developers out in the cold! If the unit test structure is part of the architectural design, test frameworks can be built up that make individual tests easy to create and read.
• The Designer also has an important role to play also. By providing valid real-world examples as part of the design document the designer can ensure that the unit tests will use real information and as such are much more likely to work in the final product. The designer should also be on the lookout for variations so that they can be documented for the testing process. Note that all this is already a by-product of the design operation - one simply has to be conscious to record everything.
  
• The Project Manager is trained to look at the big picture. Competent unit testing means less errors -  more than making up for the additional development time. In addition the increased level of confidence in product stability means targets more accurately met. Finally, questions on functionality implementation can be more quickly answered by developers viewing the unit test rather than reviewing the code. If the unit test does not excercise said functionality then it's implementation is incidental and not to be trusted.
• The Test Manager can use code coverage tools to measure the level of test coverage unit tests provide. The test manager should also have input in the review of test data to ensure that the unit tests provide for real-time situations. Lastly by using unit test pass as a pre-requestite for test releases the test manager can ensure a stable system before more advanced testing phases start.
• The Stake Holders simply need to be convinced that over the life of the project unit testing improves their bottom line. They will appreciate the higher level of confidence that unit tests provide for releases. Perhaps we need to research or instigate studies measuring the time saved by reducing the need for bug fixes during test and product release life against the onset of additional development time.