Unit Test As Documentation

I suppose it might make sense to proceed like this:

1. Initial CRC card requirements gathering
2. General agreement on a VERY high level design
3. Pick a component to start coding
4. Prioritize the requirements for the component
5. Grab a handful of top priority items and write UnitTests for them
6. Code them, test them, and iteratively add more

Then when you have multiple components, write your FunctionalTests to test operation between components.

So, you could look at your UnitTests as being good documentation of the requirements, and perhaps just a tad easier to read than the code itself.

Does this sound right? -- SteveMaring

---

Almost. I think it should never be too difficult to extract the requirements from the UnitTests, but it seems to me that the CustomerTests are much better as a documentation of requriements because they are designed to be potentially readable by a non-programmer, and because they are directly driven from the story cards. UnitTests include a lot of testing of lower level processes that have no direct connection to the stories.

See AgileRequirementsDocumentation

-- SteveJorgensen

---

CategoryTesting