We are just starting out on a greenfield project and are driving our
development from executable acceptance tests using an outside-in/BDD
approach (SpecFlow + nunit + htmlUnit). We were previously using
stories and TDD, but no executable scenarios, as a fairly agile team.
Although we have a long way to go things are going OK at the moment
and we feel it is bringing some real focus to the development process.
However a lot of the early stories are largely admin type CRUD - for
example functionaility to set up user defined entities and their user
defined properties within the system and to provide a mechanism for
relating these entities to each other.
I have read Gojkos excellent blog post on the anatomy of good
acceptance test (http://gojko.net/2010/06/16/anatomy-of-a-good-
acceptance-test/) after having attended the agile testing meeting on
which it is based. Although I thought I understood what makes a good
test where a business rule needs elaborating I am struggling with this
infrastructure stuff - this manifests itself in difficulty in coming
up with the "So that I can ..." bit of the story as the infrastructure
stuff is only there to support the meat of the application which is
capturing entity specific data to support the business.
A lot of the scenarios are of the form:
Given the system doesn't have something
When I create something (using the web interface)
Then visiting a listing page shows the thing I created
I keep in mind that the scenarios are there to facilitate
communication but they seem to state the obvious or do you need to
start with the simple stuff to tease out the edge cases. I am also
aware that some of the tests are tending towards scripts using the
driving the UI.
Does anyone have any advice about how to write tests for this sort of
stuff or any experiences in starting out with BDD they can share.
Thanks in advance
Neil
Cross posted to the agile testing uk