Re:On Programming Deadlines
by stonemetal on Tuesday November 01, 2011 @11:07AM
(#3182373)
I always hear that TDD is good for documentation, but most of my unit tests cover odd corner cases, weird error conditions and the like. It certainly isn't a show of what to do. What do you do with your unit tests that make them high quality documentation?
That's often true of tests that were only used to check the validity of code, not its design.
In many uses of TDD, you will use somewhat broader specifications to test things. "The login system accepts any user with a valid name by returning '1' and returns '0' if the password isn't the right one". You can have a test to verify that without using special corner cases, and a test such as this one will likely look like any other normal use of your library or function.
If you develop all your requirements using TDD, then both the corner cases and the standard cases should be sitting in the test suite. The standard cases can act as documentation and a design tool while corner cases are really more there to insure things work absolutely right.
I mention this, because these three objectives--design, regression-proofing, and documentation--can be achieved in various other ways besides writing tests first, and it can be helpful to separate them in your mind even if you choose to practice TDD with great discipline.