Does writing "Given" "When" "Then" BDD style test cases scale up to larger, end-to-end scenarios

Question

Traditionally, structured test, especially long scenarios are commonly written in the step, expected, actual format. Behaviour Driven Design replaces this with the style of "Given", "When" "Then", for example

Given a working ATM

And invalid credit card

When the card is inserted

And a cash withdrawl is requested

Then no cash should be provided

And the card should be retained

I want to start use BDD on complex scenarios on a project, and the question that I have is: Does this new style of test case work for larger, real world, end-to-end scenarios or is it more appropriate for simpler "atomic" or unit test style test cases?

Answer 1

I don't see why it wouldn't scale. It's conceptually simple (which naturally makes it self open to scalability.) I would be weary though - the more complex a test is, the less effective it is. If you have tests you're worried about being too complex "Given, When, Then" (I almost abbreviated that to GWT but realized that would confuse people haha. Ahem...) then you may want to consider splitting that test into smaller components that will give you more feed back.

In other words, what makes it complex? Does it have input chaining which is the complexity? If it is, then you have a definite rationale for making multiple tests out of it. Another common introduction of complexity would be if you something like "when the result of ___ is ___" That really should be a given, not a when. Personally I would classify a move from when to given to be a complexity reduction.

Answer 2

Although I don't have any experience using SpecFlow, I've recently starting using StoryQ for this type of testing. Although I was very leary on it at first, I've found it to be very useful, including in complex scenario's. Not only is the code more organized now, but also, I've found it easier to write more complex scenario's as it forces me to break it up more.

Answer 3

Firstly, I think you used the word "anger" when you meant "earnest" - but this is purely a guess on my part.

If my guess is correct (a "big" IF), then to answer your question, I would say "yes" - in other words, I would use "given" "when" "then" for more complex scenarios.

Answer 4

You can use Given/When/Then for scenarios with any complicity level, for instance,

Very specific scenario:

Scenario: Error when the password and confirm password do not match
Given I am on User Registration From 
When I fill the Form fields as follow:
| Field   | Value           |
| Name | myusrname|
| Password| password123| 
|Confirm Password | passnotmatch234|
And I click on the button “Save”
Then the error message should be “Password and Confirm password do not match”

End-to-end scenario:

Scenario: New user with unique name can be registered in the system 
Given user with name “Uncle Bob” does not exists in the system
When I create a new user with name “Uncle Bob”
Then the registration should be successful 

In this case, there are the following checks behind the phrase “Then the registration should be successful”:

1. Registration form was saved without errors
2. The User has received a confirmation email
3. The user had clicked on the confirm link and the email confirmation was successful 
4. User logged in to the system

All those steps are implicit and hidden in the phrase “Then the registration should be successful”, because the goal of the scenario was to check that user with unique name can be registered in the system.