Question

How do you handle user stories/acceptance tests that have long chains like this one, where the Then/When mingle together? Is it best to split this into a separate acceptance test where one tests that the dialog appears and then the second one tests the behavior after the dialog has been shown?

Feature: Confirmation before removing products from cart
  In order to avoid accidentally removing an item from my cart
  As a Customer
  I want a confirmation dialog to ask me if I'm sure I want to remove an item

  Scenario: I want to remove an item from my cart
    Given I have added item "xyz" to my cart
    When I click "Remove"
    Then a confirmation dialog pops up
    And it asks "Are you sure you want to remove this from your cart"
    When I click "Yes"
    Then item "xyz" should be removed from my cart

Answer 1

Your scenario seems a little long, and it’s quite heavily tied to the gui. What would happen if you tied it to the capabilities of the system instead?

Scenario: I want to remove an item from my cart
  Given I have a cart containing "xyz"
  When I remove "xyz" from my cart
  Then my cart should be empty.

The scenario now describes stuff that’s useful to the user, and it’s easier to refactor.

I love BDD as much as I do because I had a situation much like this. We had 120 acceptance tests and they were mostly failing. Someone had put a confirmation dialogue box in much like the one you describe, and instantly broke over 80 acceptance tests. By turning them into scenarios with high-level, reusable steps instead, we can easily refactor and keep the tests working even if the mechanisms we use to implement the capabilities of the system change. The actual clicking of buttons happens within those reusable steps, and it’s OK to have more than one UI action per step.

I wrote a scenario here which does this if it’s useful (it’s a DSL rather than English but you should get the idea):

http://code.google.com/p/wipflash/source/browse/Example.PetShop.Scenarios/PetRegistrationAndPurchase.cs