Why Cucumber?

Filed under: Cucumber, Executable specification, Test automation, — Tags: Automated acceptance criteria, Automated acceptance tests, Collaboration, Concrete examples, Cucumber-jvm, JUnit, Readability, Requirements — Thomas Sundberg — 2014-03-30

Before I can try to motivate why you should use a tool, let me define what it is and what it does.

What is cucumber?

Cucumber is a tool for collaboration and testing. It is used to create examples of behaviour that are executable. Creating examples in a collaborative way emphasize close cooperation between business analysts, testers and developers. The examples they come up with can be used as acceptance tests for the system being developed. It can be used as a testing tool where the tests are defined in a business friendly language while still being executable.

Goal

Our goal is to create a common understanding of the problem and therefore simplify the communication between all parties involved. We would also like to get something that is possible to use for automating the verification of the resulting program. That is, use as a base for test automation of the system.

Why use Cucumber?

The main reason for using Cucumber is that it is easy to express requirements using concrete examples that are hard to interpret in more than one way. It means that a customer that may describe a problem vague has to be very precise and use clear examples for describing the behaviour they actually want. These examples are easy for testers and developers to understand and discuss with the customer.

We are able to replace vaguely defined problems with well defined, concrete examples and get acceptance criteria that can be automated in the process.

Why not write source code?

Being concrete and precise is the same thing as writing source code. Why don't we just write source then? Depending on the receiver, this may be a good or bad idea. However, most of our customer can't read, or write source code. This is the reason why we have a communication gap that we must bridge. It is also the reason why we developers have a job, our customers can't do the job we do.

An example of source code that I hope can be viewed as relatively easy to understand is the example below. If you are a developer, then this should be very understandable. If you don't read or write code, you will probably be confused by all the strange notations and possible miss the important parts hidden somewhere in the middle.

import org.junit.Test;

public class SignUpTest {

    /**
     * New users should get a confirmation email and be greeted
     * personally by the site once signed up.
     */
    @Test
    public void shouldSuccessfullySignUp() {
        WebSite site = new WebSite();
        site.signUpWithAllDetails();
        site.assertConfirmationMail();
        site.assertPersonalizedGreetingMessage();
    }

    /**
     * Where someone tries to create an account for an email address
     * that already exists
     */
    @Test
    public void shouldBeOfferedToRecoverPasswordWhenSigningUpWithDuplicateEmail() {
        WebSite site = new WebSite();
        site.signUpWithRegisteredEmail();
        site.assertDuplicateEmailMessage();
        site.offerToRecoverPassword();
    }
}

Expressing the same thing using Cucumber may look like the example below.

Feature: Sign up

  Sign up should be quick and friendly.

  Scenario: Successful sign up

  New users should get a confirmation email and be greeted
  personally by the site once signed up.

    Given I have chosen to sign up
    When I sign up with valid details
    Then I should receive a confirmation email
    And I should see a personalised greeting message


  Scenario: Duplicate email

  Where someone tries to create an account for an email address
  that already exists

    Given I have chosen to sign up
    But I enter an email address that has already registered
    Then I should be told that the email is already registered
    And I should be offered the option to recover my password

The example above is taken from The Cucumber Book.

Conclusion

If you want to use a tool where anyone can read and validate a required behaviour, choose Cucumber. Do not write test code that you want your business stakeholders to read and validate. They are not good at reading code and will never be able to validate that the expectations on the system are correct.

Give them examples that are easily readable and executable. Give them examples on the format Given/When/Then and discuss the examples with them to validate that you have a common understanding of the goal with the system.

Resources



(less...)

Pages

About
Events
Why

Categories

Agile
Automation
BDD
Clean code
Continuous delivery
Continuous deployment
Continuous integration
Cucumber
Culture
Design
Executable specification
Gradle
Guice
J2EE
JUnit
Java
Linux
Load testing
Maven
Mockito
Pair programming
PicoContainer
Programming
Public speaking
Quality
Recruiting
Requirements
Scala
Selenium
Software craftsmanship
Software development
Spring
TDD
Teaching
Technical debt
Test automation
Tools
Web
Windows
eXtreme Programming

Authors

Thomas Sundberg
Adrian Bolboaca

Archives

Meta

rss RSS