This document provides an overview of Cucumber-JVM best practices for behavior driven development. It discusses layers of agile development including test driven development and behavior driven development. It then explains Cucumber-JVM and Gherkin syntax for defining features, scenarios, steps, and tags. Finally, it outlines best practices for writing feature files, using code coverage, and building test data in step definitions.

1. Cucumber-JVM Best Practices
V3
Ahmed Misbah

2. Agenda
• Introduction
– Layers of Agile Development
– Test Driven Development
– Behavior Driven Development
• Cucumber-JVM
• Best Practices

3. Rules
• Phones silent
• No laptops
• Questions/Discussions at anytime welcome
• 10 minute break every 1 hour

4. INTRODUCTION

5. Layers of Agile Development

6. Agile Practices
• Pair Programming
• Test Driven Development
• Acceptance Test Driven Development
• Behavior Driven Development
• Specification by Example
• Collective Ownership
• Continuous Deployment
• Continuous Integration
• Version Control
• Definition of Ready
• Definition of Done

7. Test Driven Development
• Test-Driven Development (TDD) is a software
development process that relies on the
repetition of a very short development cycle
• Requirements are turned into very specific
test cases, then the software is improved to
pass the new tests only
• Kent Beck is credited with having developed
or 'rediscovered’ the technique

8. TDD and XP
• Testing in XP:
– All code must have unit tests
– All code must pass all unit tests before it can be
released.
– When a bug is found tests are created before the
bug is addressed (a bug is not an error in logic, it is
a test that was not written)
– Acceptance tests are run often and the results are
published

10. How do we do TDD?

11. Behavior Driven Development (1/2)
• Behavior-Driven Development (BDD) is a
software development process that emerged
from Test-Driven development (TDD)
• It combines the general techniques and principles
of TDD with ideas from domain-driven design
and object-oriented analysis and design to
provide software development and management
teams with shared tools and a shared process to
collaborate on software development

12. Behavior Driven Development (2/2)
• BDD is largely facilitated through the use of a
simple domain-specific language (DSL) using
natural language constructs (e.g., English-like
sentences) that can express the behavior and
the expected outcomes
• DSL can be written as Test Scripts and
converted into Fixtures for automating tests

13. Behavioral Specifications
• Title: The story should have a clear, explicit title: Narrative
A short, introductory section that specifies:
– who (which business or project role) is the driver or primary
stakeholder of the story (the actor who derives business benefit
from the story)
– what effect the stakeholder wants the story to have
– what business value the stakeholder will derive from this effect
• Acceptance criteria or scenarios: a description of each
specific case of the narrative. Such a scenario has the
following structure:
– It starts by specifying the initial condition that is assumed to be
true at the beginning of the scenario. This may consist of a
single clause, or several
– It then states which event triggers the start of the scenario
– Finally, it states the expected outcome, in one or more clauses

14. User Stories
• Written in the following notation:
– As who
– I want what
– So that why
• A User Story has three components (3Cs):
o Card
o Conversation
o Confirmation

15. An example of a User Story

16. Acceptance Criteria/Scenarios
• Scenarios are described in Given [initial
context] When [event occurs] Then [ensures
some outcome] notation

18. Problem Domain vs. Solution Domain
Problem Domain Solution Domain
Implement
Validate

19. BDD Frameworks and Libraries
• Cucumber (Java and Ruby)
• JBehave (Java)
• Behat (PHP)
• Jasmine (JS)

20. CUCUMBER-JVM

21. Cucumber
• Cucumber is a software tool that computer
programmers use for testing other software
• It runs automated acceptance tests written in
a behavior-driven development (BDD) style
• Gherkin is the language that Cucumber uses
to define test cases

22. Gherkin
• Gherkin is designed to be non-technical and
human readable, and collectively describes use
cases relating to a software system
• It seeks to enforce firm, unambiguous
requirements starting in the initial phases of
requirements definition by business management
and in other stages of the development lifecycle
• In addition to providing a script for automated
testing, Gherkin's natural language syntax is
designed to provide simple documentation of the
code under test

23. Cucumber/Gherkin Syntax
• All Gherkin files have the .feature file
extension. They contain a single Feature
definition for the system under test and are an
executable test script
• Cucumber tests are divided into individual
Features. These Features are subdivided into
Scenarios, which are sequences of Steps

24. Feature Definition

25. Scenarios

26. Scenarios and Examples

27. Steps (1/2)
• Given - Describes the preconditions and initial
state before the start of a test and allows for any
pre-test setup that may occur
• When - Describes actions taken by a user during a
test
• Then - Describes the outcome resulting from
actions taken in the When clause
• And - Logical and
• But - Logically the same as And, but used in the
negative form

28. Steps (2/2)

29. Tags (1/2)
• Gherkin's Feature structure forces organization.
However, in cases where this default organization
is inconvenient or insufficient, Gherkin provides
Tags
• Tags are @-prefixed strings and can be placed
before:
– Feature
– Scenario
– Scenario Outline
– Examples

30. Tags (2/2)
@SetupTestData

31. Cucumber-JVM
• Cucumber-JVM is a pure Java implementation
of Cucumber
• Cucumber-JVM also integrates with all the
popular Dependency Injection containers (e.g.
Spring)

32. Cucumber-JVM code

33. Hooks
• Hooks are Cucumber's way of allowing for setup to be
performed prior to tests being run and teardown to be
run afterwards
• Three basic types of hooks exist:
– Before - Runs before a scenario
– After - Runs after a scenario
– Around - Assumes control and runs around a scenario
• Additional hooks include:
– BeforeStep
– AfterStep
– AfterConfiguration - Runs after Cucumber configuration
and is passed an instance of the configuration

34. BEST PRACTICES

35. Feature file writing
• Feature files should be written using one of the
following approaches:
– Specification workshops - when starting out, having the
whole team attend specification workshops acts as a
useful introduction to the approach. Over time, some
teams decide to continue with a whole-team approach,
while others reduce the number of people in each session.
– 3 Amigos - suggests a minimum of 3 functional roles;
developer(s), tester(s) and business analyst or product
owner.
– Example mapping - uses index cards as a means to engage
all team members collaboratively and visually map the
story, acceptance criteria or rules, and examples.

36. Code Coverage
• Code Coverage should not rely entirely on
Feature Files
• Feature files should cover Acceptance Tests
• Most code coverage should come from Unit
Tests

37. Feature Files Writing Guidelines
1. All scenarios must be independent and deterministic.
This means that the scenario should run alone
successfully without depending on other feature files
or scenarios to run before it
2. Use DRY concept in writing Cucumber/Gherkin
feature files. This means that step definitions should
be written in a form that will make them reusable and
easy to refactor
3. Use Scenario Outlines. This implies writing single
scenarios for testing multiple data and relying on
examples to describe test data and verify different
outcomes

38. Feature Files Writing Guidelines
(cont’d)
4. Use regular expressions in Step Definitions for
ignoring plurals to promote reusability
particularly in setting up test data
Given the following user exists
| Username | Role |
| msaeed | Budget_Manager |
Given the following users exist
| Username | Role |
| msaeed | Budget_Manager |
| msaeed | Budget_Manager |
@Given("^the following users? exists?$")
public void the_following_user_exists(List<UserTestCommand>
userList) throws Throwable{
}

39. Feature Files Writing Guidelines
(cont’d)
5. Use tables in feature files for writing “When”
steps
Bad Practice

40. Feature Files Writing Guidelines
(cont’d)
Good Practice

41. Feature Files Writing Guidelines
(cont’d)
6. Setting up test data will be using:
– Tags (SQL scripts for global data - Separate tag for
each entity - Tag for all data - Use flyway migration
scripts)
– Background (for feature specific data)
– Given (for scenario specific data)
7. Truncate all tables from one scenario to the
other and run SQL migrations

42. Feature Files Writing Guidelines
(cont’d)
8. One step definition per API command for
setting up test data
9. Use business identifiers in feature file test
data

43. Building Test Data in Step Definitions
• Test data defined in Cucumber/Gherkin
feature files should be persisted using Builders
that will call the actual production APIs. The
Builders will construct the API Commands that
will be used to call the REST APIs

44. Building Test Data in Step Definitions
• Cucumber only injects objects that are declared
in the Step Definition class currently being run. To
overcome this problem, Cucumber glues are
declared in Spring Context XML to allow the glue
class to be injected in all classes that run
• Injecting all builders into a single class (or factory)
and declare this class as Cucumber Glue. Any
class that will use a builder will retrieve the
builder from the Builder Factory

45. Thank You!