Digiguru.co.uk

We’ve been supporting our codebase for many years, but we are starting to look into describing our core site tests as a load of Gherkin features. This is the first step as we move to a more highly automated testing process.

Now - what is Gherkin? It’s a way of describing what your application does in a way that anyone from the business can understand. The way the language has been designed it stands as a template that can be understood by testing frameworks. It looks like the following (this example is found on the wiki description:

Feature: Serve coffee
    Coffee should not be served until paid for
    Coffee should not be served until the button has been pressed
    If there is no coffee left then money should be refunded

  Scenario: Buy last coffee
    Given there are 1 coffees left in the machine
    And I have deposited 1$
    When I press the coffee button
    Then I should be served a coffee

The idea is to write these for core parts of the site.

Originally I thought it was an easy task. I have a list of core site tests, so I grabbed the list and started on the very first core feature.

* Standard registration
* Quick regsitration

That was all I needed to know what to test, but I can’t hand that over to anyone who doesn’t really understand the domain. The objective of writing these features is to make sure anyone can read these specs and understand how to test them, even an automation engine.

As I started to write the tests I realised that Gherkin is far more verbose. You need to describe the exact state in every scenario, look at this.

  Scenario: User should be able to register through quick registration
    Given I am not logged in
    And I am on a page describing the planning tool
    When I register with an email address that has never been used before
    Then I should be registered
    And I should be logged in
    And I should be on the planning tool

This was originally described as the concept

* Quick registration

But that’s not enough - I also need to describe what “not” being logged in is…

Scenario: Unauthenticated users cannot access planning tool
    Given I am not logged in
    When I go to the Planning tool page
    Then I should see the introduction page
    And I should be asked to register or sign in to continue

Only once these two tests are satisfied.

As I started to look at all the different scenarios that the user can follow, it quickly escalated to a much more complicated set of scenarios. The problem is, the concept of Gherkin is BDD - Behaviour Driven Development (Or Design). As we haven’t driven the development spec first, we are starting to pay the tax. BDD would have alerted us to all the crazy minor edge cases, and helped us simplify the design.

Where does it leave us? We need to do a lot of work writing our scenarios if we want to cover the core site areas, but there’s no urgent need - we can evolve our existing regression tests into Gherkin over time. Anything we learn we can feed into future developments - ones in which we can start considering BDD upfront.