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.
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.
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.
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.
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.
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.