Tim Ottinger of Object Mentor brought up a great point recently on the testdrivendevelopment yahoo mailing list stating that he has noticed that a lot of people doing TDD are doing it more localized, unit tests only (Test Driven Development) rather than starting at a higher level with Acceptance Tests that drive the design / requirements.

Indeed, this can be a diffilult concept for people new to XP to grasp. Acceptance Tests are at such a high level, it is easy to believe that one can’t write an acceptance test until the system under test is complete. However, this is pretty much the same excuse that is given on unit tests, I even remember when I discovered unit tests I thought it was something to be done at the end of the process (the old waterfall cycle of plan, code, test, repeat).

I admit I subscribed to the belief of Acceptance Tests last for a little bit, but finally did the acceptance tests first ona few projects and realized just how powerful it can be to do the AT up front. In fitnesse, I can set up a workflow of how I percieve the system to run, and even write the fixtures for it, but of course I’ll get either all red or some yellow indicating it’s not passing. From there I have a clear point of view of where design needs to go from there, and begin to break down the AT into small pieces (not literally, but more like “the functionality this section is trying to verify”) and begin writing unit tests.

I’d love to hear other people’s experiences doing acceptance testing up front.

If you're new here, you may want to subscribe to my RSS feed. Thanks for visiting!


This entry was posted on Tuesday, July 25th, 2006 at 8:38 am and is filed under Agile Software Development, Test Driven Development. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.