While collaborating on a new article I was recently pointed in the direction of Behavior Driven Development (BDD) by Chris O’Dell. I only thought I had a vague idea of what it was before and I got so absorbed in Behavior Driven Development on Wikipedia and Dan North’s Introducing BDD today that I missed my stop on the tube. I never miss my stop on the tube!
There are two main points that stood out for me.
I usually develop software inside out. Start with the model and then add the user interfaces on top. Dan North tells us that the first thing that we should do is get the user interface going and then show it to the customer/user to get immediate feedback. This is actually far more sensible as the user interface is what the users see and use, so they can tell you if it’s right or how it needs to be changed. Then you can develop the model to suit, rather than the other way around.
For while now I have been looking for a good way to record acceptance criteria with user stories and I think I’ve found it. Dan gives and example of an ATM:
To illustrate, let’s use the classic example of an ATM machine. One of the story cards might look like this:
+Title: Customer withdraws cash+
As a customer,
I want to withdraw cash from an ATM,
so that I don’t have to wait in line at the bank.
So how do we know when we have delivered this story? There are several scenarios to consider: the account may be in credit, the account may be overdrawn but within the overdraft limit, the account may be overdrawn beyond the overdraft limit. Of course, there will be other scenarios, such as if the account is in credit but this withdrawal makes it overdrawn, or if the dispenser has insufficient cash.
Using the given-when-then template, the first two scenarios might look like this:
+Scenario 1: Account is in credit+
Given the account is in credit
And the card is valid
And the dispenser contains cash
When the customer requests cash
Then ensure the account is debited
And ensure cash is dispensed
And ensure the card is returned
Notice the use of “and” to connect multiple givens or multiple outcomes in a natural way.
+Scenario 2: Account is overdrawn past the overdraft limit+
Given the account is overdrawn
And the card is valid
When the customer requests cash
Then ensure a rejection message is displayed
And ensure cash is not dispensed
And ensure the card is returned
Both scenarios are based on the same event and even have some givens and outcomes in common. We want to capitalize on this by reusing givens, events, and outcomes.
Of course there is a lot more to BDD, than I have described here, but these are the inspirational particles for me.
There are two main points that stood out for me.
I usually develop software inside out. Start with the model and then add the user interfaces on top. Dan North tells us that the first thing that we should do is get the user interface going and then show it to the customer/user to get immediate feedback. This is actually far more sensible as the user interface is what the users see and use, so they can tell you if it’s right or how it needs to be changed. Then you can develop the model to suit, rather than the other way around.
For while now I have been looking for a good way to record acceptance criteria with user stories and I think I’ve found it. Dan gives and example of an ATM:
To illustrate, let’s use the classic example of an ATM machine. One of the story cards might look like this:
+Title: Customer withdraws cash+
As a customer,
I want to withdraw cash from an ATM,
so that I don’t have to wait in line at the bank.
So how do we know when we have delivered this story? There are several scenarios to consider: the account may be in credit, the account may be overdrawn but within the overdraft limit, the account may be overdrawn beyond the overdraft limit. Of course, there will be other scenarios, such as if the account is in credit but this withdrawal makes it overdrawn, or if the dispenser has insufficient cash.
Using the given-when-then template, the first two scenarios might look like this:
+Scenario 1: Account is in credit+
Given the account is in credit
And the card is valid
And the dispenser contains cash
When the customer requests cash
Then ensure the account is debited
And ensure cash is dispensed
And ensure the card is returned
Notice the use of “and” to connect multiple givens or multiple outcomes in a natural way.
+Scenario 2: Account is overdrawn past the overdraft limit+
Given the account is overdrawn
And the card is valid
When the customer requests cash
Then ensure a rejection message is displayed
And ensure cash is not dispensed
And ensure the card is returned
Both scenarios are based on the same event and even have some givens and outcomes in common. We want to capitalize on this by reusing givens, events, and outcomes.
Of course there is a lot more to BDD, than I have described here, but these are the inspirational particles for me.
Comments
Post a Comment