I suppose it might make sense to proceed like this:

	1 Initial CRC card requirements gathering
	1 General agreement on a VERY high level design
	1 Pick a component to start coding
	1 Prioritize the requirements for the component
	1 Grab a handful of top priority items and write UnitTest''''''s for them
	1 Code them, test them, and iteratively add more

Then when you have multiple components, write your FunctionalTest''''''s to test operation between components.

So, you could look at your UnitTest''''''s 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 UnitTest''''''s, but it seems to me that the CustomerTest''''''s 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.  UnitTest''''''s include a lot of testing of lower level processes that have no direct connection to the stories.

See AgileRequirementsDocumentation

-- SteveJorgensen
----
CategoryTesting