As a result, tests document behavior, not business rules.
But that's not quite what friedo said. He wrote that "the tests are the specification". A specification just describes behavior -- the reasons why that is the desired behavior provide helpful context for interpreting behavior or generalizing it to new situations, but they aren't the specification itself.
Assumptions creep into code because requirements are rarely well-specified. Therefore, they become open to interpretation -- which is why having that context and institutional knowledge documented becomes important. All TDD does is encourage developers to be explicit about how they are interpreting a requirement or specification, before they write the code.
When people say tests or code are the documentation -- it's a limited form, but it has the advantage over other types of documentation that they are, by definition, describing what actually happens, rather than what was desired or intended, which which may or may not have been updated and which the program may or may not fulfill. But that's still just a documentation of the spec, not the requirements.
What I find, personally, is that TDD helps brings focus. It's not a documentation technique; it's a task-management technique. There's a clearly defined concept of "done" and the code I write is limited to achieving "done" as directly as possible. The clarity of thinking through how to prove that something does what I expect also usually means that by the time I write actual code, I have a much better idea of what I need to write. That, too, saves time and improves the quality of what I write.
-xdg
Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.
In reply to Re^3: What is a testing plan?
by xdg
in thread What is a testing plan?
by hesco
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |