Organizing Acceptance Test Cases

Something not being discussed on OrganizingTestCases, though the XP books clearly push in the direction of automated acceptance tests.

So, a straw man: if you are going to code acceptance tests with xUnit too, keep them in a different package hierarchy from the rest of the code. I dont mean a different directory, I mean organize them differently. There is no requirement for acceptance tests to access non-public methods so feel free to organize them differently, eg grouped by iteration. Secondly, consider having one test class per UserStory. User stories are intimately tied to their acceptance tests, so this seems natural. Javadoc the class with the user story. A little less XP (folk prefer cards) but it doesnt smell that bad. Finally, for all acceptance tests that can't be driven automatically, record the results in a file with a simple format (eg csv from excel). A standard acceptance test class for non-automated tests can then be written to grab the pass/fail statuses from the file, so that all results can be tracked together.

(nb this isnt all my idea, you can see some of this organization in AcceptanceTestExamples. I think the emphasis on using the framework to pull all test results together was RonJeffries', but I can't find the reference. Anyone? I think if you want to take these 'tool supported stories' a little further though, it would be worthwhile using an '@story' javadoc thingy to allow you to pull together estimates from the acceptance test classes)

Ok it does smell a bit. It discourages some of the flexibility in user stories that you get by using cards. But hey, its a straw man. Anyone got a torch?

--BrianEwins

This page has been dormant since 2001, and I think we've discovered a bit more about OrganizingAcceptanceTestCases since then. We've certainly got more tools for writing them.

I don't recommend OrganizingAcceptanceTestCases by user story or grouped by iteration. These are both artifacts of the implementation process, not of the resulting system. I would group them by feature, which is a construct related to how we think of the system we're building (or, eventually, have built).

--GeorgeDinwiddie