Mixing Then and When in BDD User Stories/Acceptance Tests

How do you handle user stories/acceptance tests that have long chains like this one, where the Then/W开发者_如何转开发hen 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

---

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

---

The question is really one of what the "branches" are.

If there are multiple steps there must be user choices at each step. There should be multiple "When"'s. This should form a rich tree with lots of user-selected alternatives at each branch. Each possible outcome should have it's own test to make the various choices and arrive at that outcome.

A three step sequence with two user choices is 8 possible paths. Different paths may arrive at the same outcome (or may not). But you should have multiple paths through this.

If it's just sequential (because someone felt like writing sequential steps) and the user has no choices, then it's not really driven by consideration of the user's behavior, is it?

I don't see the choices. No choices == bad smell. But easy to test since there's only one outcome with a sequence of captive steps where the user has few or no choices.

If you work out the choices properly, then each step has multiple outcomes and each step should be tested independently.