A practical approach BDD using Cucumber-jvm and web driver with introduction to process and technology integration. Colombo Selenium meetup group.

1. BDD – By Examples
Behavior Driven Development with Selenium/ Cucumber-JVM
Nalin Goonawardana

2. The audience

Automated acceptance testing?

Agile/Scrum?

CI?

BDD?

3. BDD/BDT – Connecting the dots
Agile
Cucumber
User Stories
UATDD
Features
Gherkin
Scenarios
BDD-2003
Step
Definitions
TDD
Steps
Dan North
Thought
Works
Jason
Huggins
JBehave
CucumberJVM
Specification
by Example
Selenium2004

4. DSL

Business language --- DSL

Specification by Example

On the other hand a good functional test tells a story!

5. The concept of ―Xdriven‖


You are driven by something to do something or achieve something.
i.e. What do you set as the guiding line that governs how you establish
some other task!

Few examples: Capability driven development

Model driven development

Test driven development

Passion driven development

Requirement driven development?

What drives us to do something or what you do first!

Of course it is not ―Bug driven development where the developer only get
to know the expected requirement through a bug!

6. How close we are - Requirements
User
The creation of functional tests and "features"
User Interface
Expected behavior
User acceptance Testing
Functional Testing
Integration testing
Service layer testing
Module
Module level testing/Unit te
Class
Unit?-method?
The creation of unit tests and "technical" code
Unit testing
Developer

7. What is wrong with Unit tests

Developer testing Vs. Behavior compliance.
Requirement
Or Expected behavior
BA/QA/User
Explicit collaboration effort that
May vary
Developer
Verification and
validation at
unit test level

8. Gaps and Cracks
Bugs
One common set of verifications that collaboratively making passed
as the exit criteria or done-ness criteria

9. Gaps and Cracks Contd..

The gap between unit tests : high-level software requirements, low-level
technical details
Behavior
Requirement

10. Executable Specification - User stories





Executable specifications
Apply the "Five Why's" principle to each proposed User Story, so that its
purpose is clearly related to business outcomes
Thinking "from the outside in", in other words implement only those
behaviors which contribute most directly to these business outcomes, so
as to minimize waste
Describe behaviors in a single notation which is directly accessible to
domain experts, testers and developers, so as to improve communication
Apply these techniques all the way down to the lowest levels of
abstraction of the software, paying particular attention to the distribution
of behavior, so that evolution remains cheap

11. What makes BDD different?



It technically Integrates the requirement to the SDLC.
It demands developer to align the development with user requirement
from the beginning.
It is a engineering work bench that support requirement driven
deveolopment.

12. BDD and BDT

13. How do we implement this?

Process or workflow alignment

Technical solution

14. The work-flow
Feature > Scenarios
Feature/Behavior
Test Fixtures
App implementation
Acceptance

15. BDD phases
Elicitation – BA/Customer (Product)
Elaboration – BA/QA (Product/QA)
Implementation of feature - Dev
Implementation of steps - QA
Validation(Exploratory+BDT)
Acceptance(Product owner-Demo)

16. The framework anatomy
Page Object layer (Pages and Elements)
get_element1
Page One
Page Two
Page Three
get_element
2
Basic Action Layer
Composite action Layer (Helper abstract layer
-Business flow layer)
[Transferring browser
control over page objects]
action_element1
action_element2
Starting comp action
Intermediate Comp Action
Exiting comp Action
Step Definition Layer (Collection of methods annotated in
Cucumber/Gherkin - Given, When, Then, But or And)
Junit executor class
Feature Layer (Actual test cases represented as scenarios written in
annotated names in step definition class.)

17. The framework anatomy contd..
Page Object layer (Pages and Elements)
Basic Action Layer
Composite action Layer (Helper abstract layer
-Business flow layer)
Step Definition Layer (Collection of methods
annotated in
Cucumber/Gherkin
- Given, When, Then, But or And)
Feature Layer (Actual test cases represented
as scenarios written in
annotated names in step definition class.)

18. TDD process and it’s roots
Specify
Behaviour
Write
little
test
Refactor
Implement
the App
complying
to the
Behaviour
Watch
test fail
Get test
pass
Wire steps
with
automation
code

19. Into details

Cucumber

Gherkin

20. The jargon




Feature : Piece of system functionality that delivers value.
User story : Vertical functional slice of a feature that can be delivered
independently
Scenario : One key example for a feature in the feature file. This amounts
to the main functional flows/ behaviors * critical data (derived through a
test design technique)
Step: Domain language phrases which can be combined to create
scenarios.

21. Cucumber



Cucumber is a testing framework that speaks the language of Gherkin.
It wires the .feature or the executable spec to its corresponding test
implementation the ―step definitions‖.
Using Cucumber doesnt mean you are practicing BDD!

22. Cucumber-JVM and the tech stack
• Cucumber-JVM is a pure Java implementation of Cucumber, with native
support for the most popular JVM languages: Java, Scala, Groovy, Clojure,
Rhino, Jython and JRuby.
• Selenium Web Driver : Java : Junit : Maven

23. Gherkin in two mins

Gherkin is the language that Cucumber understands.

purposes — documentation and automated tests

it’s talking to you, telling you what code you should write.

Single Gherkin source file contains a description of a single feature.

Source files have .feature extension.

24. Gherkin in two mins …..

Features,User Stories, Scenarios and steps

line-oriented language that uses indentation to define structure

Line endings terminate statements

Either spaces or tabs may be used for indentation

lines start with a keyword (Feature,Background,Scenario,Scenario
Template,Given,When,Then,And,But)

Comment lines are allowed anywhere #

Regular expressions

Tables

25. Gherkin in two mins ….. Keywords

Given : Pre condition

When: primary action of a scenario

Then : Post condition, expected observable outcomes.

And, But
If you have several Given, When or Then steps.

26. Data driven
Scenario Outline: Login Success and Failure
Given I navigate to the mock application
When I try to login with '<type>' credentials
Then I should see that I logged in '<status>'
Examples:
| type
| valid
| invalid
| status
|
| successfully |
| unsuccessfully|

27. Setting up the IDE

Pre conditions:

IntelliJ IDEA 12 Community Edition
In the IDE add the following plugins;
Settings> IDE settings > Plugins > Install JetBrains Plugins > Gherkin V1.1
Settings> IDE settings > Plugins > Install JetBrains Plugins > Cucumber for Groovy V1.0
Settings> IDE settings > Plugins > Install JetBrains Plugins > Cucumber for Java V1.0

28. IDE features

1. Code Completion (Step definition and Gherking syntax support)

2. Cucumber Framework Support

3. Drill down from *.feature file to step definition

4. Code Formatting

5. Junit runner support

29. Framework Changes Step 1 – Adding Maven Dependencies

Simple five steps approach in the framework level changes

Assumptions

Existing Java/Junit/Maven/Web Driver based test framework.

Or Create an empty maven project

Apart from the junit/Selenium deps add the following deps to the maven
pom file
<dependency>
<groupId>info.cukes</groupId>
<artifactId>cucumber-java</artifactId>
<version>1.1.4</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>info.cukes</groupId>
<artifactId>cucumber-junit</artifactId>
<version>1.1.5</version>
<scope>test</scope>
</dependency>

30. Framework Changes Step 2 - Set up package structure

31. Framework Changes Step 3: Add the junit runner class

32. Framework Changes Step 4 - Add the step definition class

33. Framework Changes Step 5 - Add the feature file

34. The role of the CI dashboard

Create a view in the name of the sprint and add the junit runner class to
separate new projects and let every one know where we are!

35. Demo

Sprint X starts

Scenarios were written

Create CI project dashboard for Sprint X and initiate.

QA : Write the test fixture and implement any step definitions. Use mock
elements(xpath or id etc.) refering to the wire frames and create the page
objects. Replace them with the real element references as soon the
details available.

Dev: Implement the Code

Tests getting passed progressively

Done: All tests are passed + Planned manual tests are executed.

36. Auto generated code skeleton
@Given("^add (d+) and (d+)$")
public void add_and(int arg1, int arg2) throws Throwable {
// Express the Regexp above with the code you wish you had
throw new PendingException();
}

37. The transition



In the original proposal the transition would be just using ―should‖ instead
of ―test‖ in the unit testing!
User story: "As a [role] I want [feature] so that [benefit]".
Scenario: ―Given [initial context], when [event occurs], then [ensure some
outcomes]‖

Test method names should be sentences

A simple sentence template keeps test methods focused

An expressive test name is helpful when a test fails

―Behavior‖ is a more useful word than ―test‖

Requirements are behavior,too

Acceptance criteria should be executable

38. Agile Scrum Alignment

Feature : Backlog item

Scenario: Test case

Donness : Built in - Green report + Manual expert/exploratory testing sign
off.

Continuous collaboration : BDD enforces it.

Continuous integration : BDD enforces it. (Part of the build.)

Recommends automation : BDD enforces it.

Just enough/living documentation that serve multiple purposes.

Always know how much is remaining.

39. Manual testing?

Expertize driven testing

Exploratory testing

Regression ?

Limitations of automation ?

40. Can we only do BDT without BDD

Yes and a No!

BDT can be identified as the means of realizing BDD.

41. Some more advantages

Non technical

BA's Product owners, OPS, Dev, QA speaking the same language

Defines Doneness criteria

Automated Regression Test suites.

No compilation issues only runtime.

User expected behavior conformance is maintained from the beginning...

42. Advantages Contd…

Tests can become truly useful documentation

Helps you to separate "what?" from "how?"

Purposely small command-set is simple to learn

Separating requirements from implementation helps refactoring

Specifications can be as thorough as unit tests

Specifications can be hooked in at different levels

Agreeing details up-front allows finer control over scope

Test coverage no longer relies on developer self-discipline

automatic generation of technical and end user documentation from BDD
"specifications"

43. The collaboration
• In BDD a significant portion of "functional documentation" defined in the
form of ―User Stories‖.
• "tests", a BDD practitioner will prefer the terms "scenario" and
"specification".
• "functional tests", the preferred term will be "specifications of the product's
behavior".
• "the unit tests of a class", a practitioner or a team using BDD prefers to
speak of "the specifications of the behavior of the class"

44. You are already a BDD practitioner

If you are practicing TDD properly

BDD, often described as ―TDD done well‖

User focused TDD

45. TOOLS

JSpec - JavaScript Behavior Driven Development

SpecFlow - Pragmatic BDD for .NET
•
•
•
•
•
•
•
•
FitNesse
Cucumber (software)
Framework for Integrated Test
JBehave
Robot Framework
Concordion
specs2
specflow

46. BDT is a paradigm shift for QA
• Reclaiming the QA role within the Agile world
• No tests but scenarios!
• Technical convergence
• Early/Parallel automation.
• Just enough Engineering practices!
• Tests frameworks without layers ! Record and play !
• Highly engaged requirement deal
• Its not about the tools but about the practices !

47. Future implementations

API Testing (In conjunction with Rest Assured)

Performance testing (In conjunction with Jmeter)

Consolidated online CASE tool?
A communication and collaboration framework for developers, QA and nontechnical or business participants in a software project.

48. More
• http://aslakhellesoy.com/post/20006051268/cucumber-jvm-1-0-0
• http://www.ibm.com/developerworks/opensource/library/a-automatingria/index.html
• RSpec, Cucumber and GivWenZen(Fitness)
• FitNess
• http://fitnesse.org/
• Xebium : Combine the power of Selenium
• http://xebia.github.io/Xebium/
• BDD original proposal
• http://dannorth.net/introducing-bdd/

49. Q&A

50. Thanks!
Nalin Goonawardana
http://nalingski.blogspot.com/
Leapset Inc.
http://www.leapset.com/
http://www.meetup.com/colombo-selenium/events/165499102/