Most of the examples on the Concordion website are technical in nature, so I've put together a short business-focused example. Please take a look.
I'm not trying to push Concordion on you. You can do something similar with other test frameworks. It's really the approach that I'm trying to get across: focusing the acceptance tests on goals, not solutions; and decomposing behaviours, keeping each test as isolated and simple as you can.
While I'm here, let me join in the 2x2 matrix fun:
The user-interface (UI) of an application is a solution, not a goal. I often see people writing test scripts in terms of direct user interface interactions (e.g. using a record/playback/verify tool like Selenium) unaware that by doing so they're locking themselves into a particular design.
If, instead, they hid the scripting behind goal-oriented acceptance tests they would leave themselves a lot more freedom to change the solution. I guess not all teams need that kind of freedom. But I wonder how many even know there's a choice?
Sunday, 9 March 2008
Acceptance Test Driven Development
Posted at
5:10 pm
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment