Using Cucumber for Behavior-Driven Testing

Are you doing BDD right?

Are you writing scenarios that illustrate business requirement instead of UI functionality?Are you getting business analysts involved and writing scenarios before code, that enables programmers to be guided by a clear specification? 

Then you are doing Behavior-Driven Development.

Getting started with BDD

The first is to get developers, testers and people from the business to talk to each other. That is the beginning of BDD. Anyone who thinks "we’re doing BDD because we use ‘Given’, ‘When’, ‘Then’" often are not. ‘Given’, ‘When’, ‘Then’ has nothing to do with BDD. The real intent in BDD is to try and work out what your client  wants from the software before you start working on it. The first way of doing this is to actually collaborate with those people.

The second steps comes after we have got everyone engaged. We need a way to record the business requirement in a meaningful but simple way. This is very important as different people are engaged in the process right now and we need everyone to contribute and everyone to understand. So we use a universal language in other words "ubiquitous language", People often use "Given", "When" and "Then" words for this. This is where Gherkin comes in to action.

Finally, if it’s appropriate to our teams and to our projects, we automate our tests to drive the behavior.

BDD is about encouraging conversation between all involved, writing down examples to make things clearer and reduce ambiguity allowing everyone to agree on what they are building. Automating the scenarios is an optional next step.

Gherkin

Gherkin is a plain-text language with a little extra structure. Gherkin is designed to be easy to learn by non-programmers, yet structured enough to allow clear description of examples to illustrate business requirement in most domains.

Here is a sample Gherkin document:

Feature: Cash withdrawal from an account

  Scenario: Account has sufficient funds

   Given the account balance is $100

     And the card is valid

     And the machine contains enough money  

    When the Account Holder requests $20

    Then the ATM should dispense $20

     And the account balance should be $80

     And the card should be returned

Cucumber for BDD 

Using Cucumber is not just about test automation and remember that Cucumber is not a testing tool. Most people who use Cucumber don't use it for BDD. They use it for testing, writing their tests afterwards. If that's your workflow, Cucumber isn't significantly better than many other testing tools. No customers, domain experts or product owners are going to read your Gherkin documents. 

Why use Cucumber

• Cucumber lets you keep specifications, automated tests and documentation in the same place.
• Simplicity. Features files are written in plain English, which can be linked with Agile stories.
• Communication between business and development is extremely focused as a result of a common English-type language.
• The code is easier to maintain, flexible, and extendable.
• The code is self-documenting with the examples.
• Test data can be changed only in the features file, not in the code.
• Stories are easier to breakdown and plan.
• Cucumber supports many different languages and platforms like Ruby, Java, or .NET.

The big question. When to use Cucumber

The simple answer is, whenever the business people have an opinion on the system behavior.

In my experience it is better to have integration tests and end-to-end tests implemented using Cucumber.

If you are thinking of writing automated tests to cover the GUI functions of an application, you will have to think twice. It is one thing to have an example of a Login page automated with cucumber integrated with Selenium, It's another thing to having to write cucumber scenarios to cover the functionality of each drop-down list and radio button.

In such case functionality of a feature should be tested at API layer by integration tests.

Other complication in trying to integrate selenium with Cucumber is you should have all the GUI ready to automate the cucumber tests. This will loose the whole point of having test-first approach in BDD. You will be just writing cucumber scenarios to structure your tests, but not to get the collaboration of Business analysts and developers on the clear specification.