I think we should seriously consider start review the test code on a continuous based as part of the general reviewing process. The reasons for this are:
- The quality of the unit test code is not very high. 3/4 of the refactorings I have done so far on the Nertarchive project has been on test code.
- The the automatic tests are a powerful component in the development process QA, and the best way to ensure the quality of these tests are to review them. Compared to the main code which get's verified though the various test, the automatic tests needs some other QA mechanism.
- Defining functionality: Test code is a powerful mechanisme for defining functionality/acceptance criteria, and this aspect of the test code should be part of the general feature complete reviews.
- Describe functionality: I can be difficult for developers and reviewers to understand the the higher level meaning of classes and methods. Here the test code can again help us, by providing a different specification of what a class or method does/should do. If the test code is included in the general feature reviews, the reviewer would gain a better understanding of the ideas and overall design of the main code of documentation.
- Highlight design: The test cases is a very good example of how the main class/unit may be used. A bad test code design or readability can in many cases be a symptom of a badly designed main class interface. In this way the test code can be a powerful tool for spotting class which should have their api refactored (I stumbled into the CleanupIF vs. Singleton issue this way).