I suppose it might make sense to proceed like this:
Initial CRC card requirements gathering
General agreement on a VERY high level design
Pick a component to start coding
Prioritize the requirements for the component
Grab a handful of top priority items and write UnitTests for them
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.