Is it acceptable to write a "Given When Then When Then" test in Gherkin?

Question

Is it acceptable to write a "Given When Then When Then" test in Gherkin? A real-life example is as follows all AllPlayers.com

Scenario: Successfully register a user   Given I am on homepage     And I am not logged into an account   When I follow "create a new account"     And I fill in "First Name" with "Bobby"     And I fill in "Last Name" with "Bricks"     And I fill in "E-mail" with "[email protected]"     And I select "Jun" from "Birthday Month"     And I select "22" from "Birthday Day"     And I select "1985" form "Birthday Year"     And I select "Male" from "Gender"     And I fill in "Password" with "123testing"     And I fill in "Confirm Password" with "123testing"     And I solve the captcha math problem     And I click "Create new account"   Then I should see "the user dashboard"     And I should see the Registration Wizard   When I push "Proceed to next step"   Then the "First Name" field should contain "Bobby"     And the "Last Name" field should contain "Bricks". 

I know it works using behat, so parsing it isn't a problem. I'm just trying to write better tests. I could write in the first then And the Registration Wizard should be filled out with data but that doesn't seem specific enough...

Suggestions?

Answer 1

It depends on the target audience of the feature as written. It seems highly likely that the gherkin you've got there was not written with a stakeholder (i.e. somebody not-techie but has a vested interest in the business and the website). BDD is really about the conversation about requirements and expectations - and Gherkin is a tool which gives a standard/recognised way that everyone should be able to read that you can write the requirements and expectations; in a way that serves as automated tests for a developer and perhaps test scripts for a tester.

Trying to take my developer hat off now - I would say that a business stakeholder would rather read, and understand easily...

Scenario: Should be able to successfully register on website     Given I am new to the website     And I want to register for a user account     When I go to the registration form     And I complete all the required registration details correctly     Then I will be registered on the website     And I will be automatically logged in 

You can still build the same test behind the scenes of this specification - but this specification has larger readership, it is a more easily understood requirement that anyone should understand. I'm not saying what you have got has no value - far from it. It will be a very valid test. But it is quite developer specific, and highly coupled to the UI implementation (if you refactor/redesign the UI, you now need to refactor your Requirements...).

I started off having plenty of gherkin specifications much like yours - and I still use them on occasion. Once your testing framework has built up a little gherkin is a really great way of kind of writing data-driven/configurable unit tests; and they still have great value to my development process. But I do try to separate the more "pure" specifications from my "developer" ones - but folder and tags/categories.

Edit: I guess in summary what I'm getting at is... what you have is a great "test", but a fairly bad "requirement". Stick with it though!

Answer 2

Yes, more than one When/Then cycle is appropriate in a Gherkin scenario when the real-world scenario calls for it.

SaxonMatt's answer makes the excellent point that scenarios are best written in stakeholder language rather than in the language of UI manipulation, and that doing so often reduces the length of a scenario, but that misses the exact point of the question. Let's take the bull by the horns.

Gherkin was designed for acceptance tests: tests which test that stakeholder-level requirements have been completely implemented, i.e. that the software actually provides value to stakeholders. Sometimes providing value takes more than one action-response cycle. Consider the following scenario:

Scenario: Guest buys a product   # This scenario starts with the user not logged in, which doesn't require a step   Given there is a product named "Elliptical Juicer"    When I go to the product page for "Elliptical Juicer"   And I add the product to my shopping cart   Then I should see 1 product in my shopping cart    When I request to check out   Then I should see the account creation form    When I create an account   Then I should see the checkout form with 1 product, "Elliptical Juicer"    When I check out   Then I should see the checkout success page with 1 product, "Elliptical Juicer"   And I should receive a checkout confirmation email with 1 product, "Elliptical Juicer" 

(Note that when I have more than one When/Then cycle in a scenario I like to separate them with blank lines so they stand out.)

There are several reasons why this scenario is best written with multiple When/Then cycles:

• Before the user checks out, they should see one product in their shopping cart (only as a digit in the site header, so the step doesn't mention the product name). There is no way to test this requirement at the end of the scenario. (Well, the test could collect the information immediately after the user adds the product to their cart and assert the expected count at the end of the scenario, but that would be pointlessly sneaky and confusing.) Instead, assert the correct count at the natural place in the scenario, as soon as it is visible to the user.

  Similarly, Then I should see the account creation form and Then I should see the checkout form with 1 product, "Elliptical Juicer" can test important requirements at the points in the scenario at which it is natural to test them.

• Suppose we didn't care about what the user sees during the process, only whether they get to the end of the scenario with their product on the way. We might then omit the intermediate Then steps:

  Given there is a product named "Elliptical Juicer" When I go to the product page for "Elliptical Juicer" And I add the product to my shopping cart And I request to check out And I create an account And I check out Then I should see the checkout success page with 1 product, "Elliptical Juicer" And I should receive a checkout confirmation email with 1 product, "Elliptical Juicer" 

  And I create an account comes as a surprise, doesn't it? It requires the reader to infer that a guest user is asked to create an account during checkout. It's clearer to say so explicitly, as in the first version of the scenario that I gave.

• Suppose none of the above concerns convinced us and we wrote a separate Gherkin scenario for each point in the overall scenario where we needed to assert that requirements have been met:

  Scenario: Guest adds a product to their shopping cart   Given there is a product named "Elliptical Juicer"   When I go to the product page for "Elliptical Juicer"   And I add the product to my shopping cart   Then I should see 1 product in my shopping cart  Scenario: Guest with a product in their shopping cart attempts to check out   Given I have a product in my shopping cart   When I request to check out   Then I should see the account creation form  Scenario: Guest creates an account   Given I have a product named "Elliptical Juicer" in my shopping cart   And I am on the account creation form   When I create an account   Then I should see the checkout form with 1 product, "Elliptical Juicer"  Scenario: Newly registered user checks out   Given I am a user   And I have a product named "Elliptical Juicer" in my shopping cart   And I am on the checkout form   When I check out   Then I should see the checkout success page with 1 product, "Elliptical Juicer"   And I should receive a checkout confirmation email with 1 product, "Elliptical Juicer" 

  That's awful! First, none of the scenarios is what a stakeholder would think of as a scenario. Second, when one of the intermediate states changes, two steps will have to change: the step which asserts the intermediate state and the Given step which sets up the intermediate state for the next scenario. Each of those Given steps is an opportunity to set up the wrong state, i.e. make an integration error. This set of scenarios has much less value as an integration test suite than did the single scenario. You might almost have written a series of unit tests.

It's true that writing every scenario end-to-end is likely to lead to some duplication. Just as you tolerate duplication more in unit tests than you would in regular code, tolerate duplication even more in Gherkin scenarios than you would in unit tests. Don't compromise on understandability. Break up scenarios and use Givens only at crucial points (such as creation of a product in the example above), and do so knowing that you're diluting your scenarios' integration-testing power.

Also, keep in mind that acceptance tests should be only part of your automated test suite. Write only enough acceptance tests to cover critical scenarios, and cover the details with unit tests. Often enough, the solution to duplication among acceptance tests is to replace one with a unit test.