88Pro Thinking

Documentation as for as the code is concerned can be achieved at many different levels. Comments, Program Specification, Special Comments which can be converted to documents using tools (JavaDoc) are some of them. However no one would disagree that, as the code evolves over time and when ownership changes, the documentation doesn’t evolve with it most of the time. Always people feel lazy to update the documents and thus there is always a gap between the documents describing the code and the code itself. If there is a discrepancy between your documentation and code, at the end of the day code matters.

For any developer to understand the intent of the original developer who wrote a piece of code, all they have to do is to go through the test cases he/she has written for that piece of code. This enables anyone to improve, bug fix, include feature of an existing piece of code without fear of breaking the intent because

1. Unit Tests written will make sure exiting functionality is not broken, while the code is changed.
   
2. Developer can understand the intent of the existing code by going through the unit tests.
   

As the code evolves, new unit tests will be added or existing tests will be modified (in the case of bug fixing). Therefore unit tests always reflect the current state of the code’s functionality and it’s always updated and parallel with the code. Can you get any more updated document which describes the code accurately?

Update: Top 12 Reasons to Write Unit Tests

posted by 88Pro / Wednesday, May 26, 2004