This shift in thinking is due in part to Liz Keogh’s Step Away from the Tools and Dan North’s Who’s domain is it anyway?. Both of these got me thinking about how I’m using the term BDD (rather loosely) and how much of an investment I’m making in a specific tool (Cucumber).
More Meaningful Planning
Having meaningful planning meetings with their customer/product owner is one thing with which many teams struggle. Too often, we go too fast, don’t uncover enough detail, use the wrong language, don’t understand “done” and leave too many loose ends.
To combat this we draw screens, discuss workflows, ask leading questions and a variety of other techniques. I felt that while I was doing these things, I was still frustrated with the other part of the planning process. I’ve never liked traditional tasking and I’ve never like the idea of having to translate all of the data gathered with the customer into some other form only to express it later in a test in yet another form.
What if I wrote my tests during the planning meeting?
I decided that changing the way I gathered conditions of satisfaction, defined “done” and discussed workflows with my product owner would give me the biggest boost in value delivered, so one day I did just that.
For the following examples, assume that we’re adding a feature to an e-commerce website.
As a user I should be able to manage addresses so that I don’t have to enter my information more than once
As I’m discussing the feature with my product owner, I will discuss with them the possible scenarios, including workflows, required to use the feature. Some scenarios for this feature might include:
- When I am on my account page
- When I am creating a new address
- When I am deleting an address
These scenarios might have scenarios of their own:
- When I am editing an address
- When I successfully edit my address
- When editing my address fails
So far I’ve been able to ask the product owner something like “So when I’m editing my address, and I miss some required fields, what happens? What do I see? Where do I go? What are the required fields?”. I can also draw pictures to explain the workflows and ask more questions “What’s on this page? Where is the error message displayed? Do I see error messages for the fields that are missing?”.
For each scenario, I can capture assertions that come from answers to the questions I’m asking:
- When I am on my account page
- I should see a link to “My Addresses”
- When I click on the “My Addresses” link from my account page
- I should be on my addresses page
- I should see “My Addresses” in the page heading
- When I am on my addresses page
- When I have existing addresses
- I should see each address listed in format xyz
- I should see an “edit” link for each address listed
- When I don’t have existing addresses
- I should see help text explaining how to add an address
If you’re an RSpec user, you might be thinking, “Hey this looks like RSpec!” and it does. During the planning meeting I can capture these scenarios and outcomes and then use them nearly verbatim for my RSpec acceptance tests. Even better, when I run my tests, I can use the “documentation” format that RSpec gives you to output that’s almost identical to the scenarios above.
The conversation required to really define these scenarios and outcomes is challenging, but at the same time, very rewarding. I have also found that it’s pretty powerful to be able to sit with the product owner and view two nearly identical documents side-by-side knowing that one is automated test output.