I am a personal fan of using tests as documentation. It really is the only way we can guarantee that the documentation is up to date. Of course, that assumes that your tests all run succussfully
The book does not specifically address how to do that because each tool is different. The easiest way is to name your tests very distinctly, and make sure each test has one specific purpose. Test management is very important so that you can actually retrieve the information you need when you need it.
Co-author, with Lisa Crispin: Agile Testing: A Practical Guide for Testers and Agile Teams (Addison-Wesley, 2009) www.janetgregory.ca
How do you feel about the use of agile tests as a form of documentation, and does the book emphasize how one might best do this?
Just to add to Janet's answer - we have a small section in the book titled "Tests Are Great Documentation". My team has had good success using FitNesse tests as "living" documentation of how the system actually works. We might get lazy about keeping static written docs up to date, but when the FitNesse tests fail, we have to fix them and keep our build "green".
We were heavily influenced by Brian Marick's emphasis on using examples to create tests and drive coding, and we emphasize the use of examples in the book also.
Co-author, with Janet Gregory: Agile Testing: A Practical Guide for Testers and Agile Teams (Addison-Wesley, 2009) http://lisacrispin.com
Hang a left on main. Then read this tiny ad:
professionally read, modify and write PDF files from Java