I’m writing an article for an agile software magazine about how to use programmer tests in place of some or all written documentation, and I’d appreciate some feedback on a very early outline for the article. This is what I intend to cover:
- Different audiences for documentation
- Application programmers — users of our libraries
- Maintenance programmers — modifiers and extenders of our libraries
- Components of a good test
- Good names
- Clearly defined setup, processing, and asserting sections
- Test sufficiency — do I tell the whole story with my tests
- Capturing design decisions
- Covering interesting use cases
- Showing error behavior
- Interactions with the environment
- Test organization for different audiences
- Application Programmers want to find common scenarios easily
- Maintenance Programmers want to follow original developer’s train of thought
- What prose and UML are needed to supplement these tests
- Future directions in Tests as Documentation (Automation topics mostly)
Obviously this is still pretty rough. I intend to use the tests for a Caching block I just wrote for Microsoft Enterprise Library along with pseudocode for the library to show the design decisions. The goal is to show devs how to create tests that will server as documentation.
Does this sound remotely interesting? Any suggestions about other things to cover?
And for those of you in St. Louis, I’m going to be giving a talk on this subject at this month’s XPSTL (9/1).