UserStories + AcceptanceTests are basically the same thing as a UseCase.
- UserStories have a name (the story); UseCases have a name.
- UseCases have pre-condition/post-condition clauses; AcceptanceTests have setup and checks.
- UseCases have steps; AcceptanceTests stimulate the system and then verify that certain steps have occurred.
How do extensions and variations fit in? They are either additional AcceptanceTests or additional stories. Does it really matter as long as we know the system handles it?
UserStories + AcceptanceTests can be looked at as executable UseCases. Sounds like something good to have your case tool do. The AcceptanceTests bring UserStories to the engineering level.
Another realization I had is that if you do UseCases and automated AcceptanceTests you are essentially doubling your work. There is duplication between the UseCases and the AcceptanceTests. I think there is a good case to be made that UserStories + AcceptanceTests are more efficient way to work when compared to UseCases + AcceptanceTests.
You could try to prove this to yourself. Go ahead and use UseCases, but automate your AcceptanceTests. The automation must be done to a level that your customer can understand the AcceptanceTests. You might see the duplication that I saw.
--JamesGrenning on the XpMailingList
How do you run a Use Case? A use case is a picture not a test. <-- UseCase is not a picture. UseCase is a text.
Could UseCases incorporate tables to be fed to a runner for the FrameworkForIntegratedTest?