Bdd with Cucumber and Mocha

hugeinc.com
info@hugeinc.com
45 Main St. #220 Brooklyn, NY 11222
+1 718 625 4843
Mar 12, 2014
BDD

BDD
Node with MochaSelenium with
Cucumber

• Agile Manifesto
• Evolutionary Development and Design
• BDD introduction
• BDD Philosophy and Implementation
• BDD with Selenium & Cucumber
• BDD with Node & Mocha
• BDD in Agile
Topics Covered
.

• Composed by heavy hitters in the software industry in
Snowbird, UT in February 2001.
• Included the folks backing methodologies such as Scrum,
XP, Crystal ,Feature driven development, etc.
• Big names included such as Martin Fowler, Robert C
Martin( Uncle Bob), Alistair Cockburn, Ken Schwaber etc.
Agile Manifesto
.

Agile Manifesto - Continued
.
• Continuous Delivery & Integration
o Welcome changing reqs
o Deliver working software frequently
o Involve biz and developers throughout the project
o Build projects around motivated folks
o Communication should be face to face
o Primary metric of progress is working software
o Simplicity is essential
o Self organizing teams
o Periodic retrospectives

Continuous Delivery & Integration
.
You can't just ask customers what they want and then try to give that to them.
By the time you get it built, they'll want something new. - Steve Jobs

What Agile says...
.
Continuous Development and Testing.
Deliver features rather than modules.
Only focus on high-value features
Strong emphasis on testing.
Adapt to faster feedback
Strong emphasis on continuous integration.
Once all software is ready for delivery, all tests should pass.
A unique way to address modern challenges in software development.

Technology Facing
.
These automated tests are written and maintained
exclusively by developers.
There are three kinds of tests that fall into this category
● Unit Test
● Integration / Component Test
● System / Deployment Test

Test Driven Dvlp (TDD) Philosophy
.
The basic tenets are developing and implementing Tests
before writing a line of code
Tests will and must fail up front
Code is developed after the test is developed.
A unique idea that is still foreign to many developers
This does not imply that we must use an agile development
process.

Business Facing
.
The tests in this quadrant are more commonly known as
Functional or Acceptance Tests.
Acceptance testing ensures that the acceptance criteria for a
story are met
Acceptance tests can test all kinds of attributes of the
system being built, including functionality, capacity, usability,
security, modifiability, availability
Acceptance tests are critical in an agile environment
because they answer the questions, “How do I know when I
am done?” for developers and “Did I get what I wanted?” for
users

Why Acceptance Testing essential?
.
Many developers believe that unit test suites created through
test-driven development are enough to protect against
regressions
Acceptance tests are business-facing, not developer-facing.
Unit tests are an essential part of any automated test strategy,
but they usually do not provide a high enough level of confidence
that the application can be released.
The objective of acceptance tests is to prove that our application
does what the customer meant it to, not that it works the way its
programmers think it should.

Executable Specifications
.
As automated acceptance testing has become more central to the
continuous delivery, practitioners have realized that automated
testing is not just about testing.
Rather, acceptance tests are executable specifications of the
behavior of the software being developed.
This realization has spawned a new approach to automated
testing.
Behavior Driven Development

What is BDD?
.
“Behavior-driven development is
about implementing an application
by describing its behavior from the
perspective of its stakeholders”.
“It describes a cycle of interactions
with well-defined outputs, resulting
in the delivery of working, tested
software that matters.”

BDD is derivative
.
BDD is second generation agile methodology. Its an
evolution to TDD.
One of the core ideas of behavior-driven development is that
your acceptance criteria should be written in the form of the
customer’s expectations of the behavior of the application.
It should then be possible to take acceptance criteria thus
written, and execute them directly against the application to
verify that the application meets its specification

What’s in a story?
.
A story is a unit of delivery
Story -28 Cash Withdrawal from ATM
As a active bank account holder
I want to withdraw cash from Bank ATM

Agree on “done”
.
Define scope using scenarios.
Feature: Cash Withdrawal from ATM
As a active bank account holder
I want to withdraw cash from Bank ATM
Scenario 1 – Cash Withdrawal with Sufficient amount
Given I have 100$ in account
When I withdraw 50$
Then Machine gives me 50$
Scenario 2 – Cash Withdrawal with In-Sufficient amount
Given I have 10$ in account
When I withdraw 50$
Then Machine says insufficent amount.

Tools and Frameworks
.
Stories & Scenarios:
Cucumber, JBehave, Mocha, Concordian, Twist
Implementation:
Selenium, Junit or TestNG

Cucumber Framework
.
Cucumber is the most popular tool is writing Scenarios in style of
Tests which can be shared with Non-Tech people.
It alters the traditional, boring, very large requirement documents
into clean, understandable English syntax feature files which
execute itself.
In short cucumber delivers executable Delivery document.
It uses very simple Gherkin language to define the scenarios.

Cucumber Framework
.
Cucumber Features is nothing but list of executable steps.
There are 3 major types of steps.
Given – When – Then
- Given some initial context
- When an event occurs
- Then ensures some outcomes.

Automate the scenarios in Java with
Cucumber
.
Make each step executable
@Given(“I have 100$ in account”)
public void createAccountWithBalance() {
}
@When(“I withdraw 50$”)
public void makeWithdrawAction() {
}
@Then(“Machine gives me 50$”)
public void dispenseTheCash() {
}

Automate the scenarios in Java
.
Make each step executable
}
@When(“I withdraw 50$”)
public void makeWithdrawAction() {
}
@Then(“Machine says insufficient amount”)
public void withdrawlError() {
}

Additional feature of cucumbers
.
Before:
}
After:
@Given(“I have (d+)$ in account”)
public void createAccountWithBalance(var amount) {
}
Before:
@Then(“Machine says ‘Insufficient amount’”)
public void withdrawlError() {
}
After:
@Then(“Machine says (.*)”)
public void withdrawlError(var message) {
}

Automation is the key
.
Scenarios become acceptance tests
which become regression test ...and documentation
Examples become code tests
…and documentation

Test Automation Tools
.
• Quick Test Professional By HP
• Rational Functional Tester By Rational (IBM Company)
• Silk Test By Borland
• Test complete By Automated QA
• QA Run (Compuware )
• Watir ( Open Source)
• Selenium ( Open Source)
• Sahi (Open Source)

Test Automation Using Selenium
.
Selenium is a robust set of tools that supports rapid development of test
automation for web-based applications.
Selenium provides a rich set of testing functions specifically geared to the
needs of testing of a web application.
Selenium operations are highly flexible, allowing many options for locating UI
elements and comparing expected test results against actual application
behavior.

Selenium Framework Features
.
• Supports Cross Browser Testing. The Selenium tests can be run on multiple
browsers.
• Allows scripting in several languages like Java, C#, PHP and Python.
• Assertion statements provide an efficient way of comparing expected and
actual results.
• Inbuilt reporting mechanism.

Selenium Driver
.
• Selenium driver is the most important point of function in writing
Selenium Tests
• Driver can perform many functions like
• Open a page
• Find elements ( By Id, class or CSS Property)
• Wait for a page load or action
• Fill the text boxes
• Click the Buttons, URLs
• Hover on elements
Over all Selenium driver is the one with whom everyone has to deal
mainly. Lot of common functionality has been implemented somewhere
is other tests. There is very good online community support and
documents for any queries or questions.

Cucumber Feature : Code Example
.
@CompareHappyPath
Feature: Compare Vehicles
As a user, I can compare a Lexus trim to other vehicle trims
Scenario: User can successfully compare one vehicle to another
Given user starts Compare flow on a large viewport
When they select the IS model
When they select the IS 250 AWD trim
When they add a competitor trim
Then ensure the compare vehicles button appears

Selenium Code Example in Lexus
.
private String startUrl = "/web/compare";
@Before("@CompareHappyPath")
public void setUp() throws Exception {
logger.debug("Start Compare Happy Path...");
}
@After("@CompareHappyPath")
public void tearDown() {
if (driver != null) {
}
driver.quit();
}
@Given("user starts Compare flow on a (.*) viewport")
public void startHappyPath(String viewportSize) {
this.openPage(startUrl);
assertTrue(StringUtils.endsWith(driver.getCurrentUrl(),
startUrl));
}

- NodeJS testing frameworks
BDD:
Mocha **, Vows*, Jasmine*, Cucumber *
TDD:
Expresso
Both: Mocha ***, Chai *
- Mocha is primarily BDD. TDD is a special mod of it.
From
(1) https://nodejsmodules.org/tags/testing
(2) https://nodejsmodules.org/tags/bdd
(3) https://nodejsmodules.org/tags/tdd
In NodeJS world

NodeJS Framework
.
Set the requirements:
● Requirement 1: Landing page functionality
a. 1.1 Need to see text on the landing page.
b. 1.2 Need to see the link to the login page.
● Requirement 2: Login page functionality
a. 2.1 Need to see text on the login page.
b. 2.2 Need to be able to login with user/email
“TEST”/”TEST”.
… etc.

NodeJS Framework
.
TDD implementation very similar to BDD implementation

NodeJS Framework
.
Expected Output:
Expected Failure Output:

Ideal qualities of Tests
.
• Decisive – Test should be human communication filter. It should
determine success/failure of a program and each time it should help to
advance to next level.
• Complete Test should read like a story. It should contains all the
information it needs to run correctly with a given test harness and work
artifact under test.
• Valid – produces a result that matches the intention of the work artifact
under test
• Repeatable always gives the same results if the test harness and the
artifact under test are the same i.e. Is deterministic
• Isolated is not affected by other tests run before it nor does a test affect
the results of tests run after it
• Automated requires only a start signal in order to run to completion in a
finite amount of time

Quotes
.
If it's worth building, it's worth testing.
If it's not worth testing, why are you wasting your time working on it?

BDD benefits
.
• It produces the software that matters.
• Requirement becomes easy to understand and communicate.
• It promotes tangible stakeholder value in software solution.
• Provides detailed (executable) specifications
• Provides concrete evidence that your code works
• Requires developers to prove it with code
• Provides finely grained, concrete feedback (in mins)
• Supports evolutionary development
• Defects after deployment are rare and non critical. Much difference than
Legacy way of development.
BDD is a step in that direction

BDD Costs
.
• Cost of learning curve. Initial dip in productivity, but quality deliverable
starts from day one.
• Maintaining acceptance tests over the long term requires discipline.
• Continuous refactoring as new acceptance criteria comes.
• Need to deal with Social barrier.
• Slow performance
At the end its subjective decision either its costly or not costly.
The great ROYAL FATE….!

Myth
.
Myth: No one knows TDD/BDD. Otherwise it would be everywhere.
Answer: Not true…!
Large portion of developers has been exposed to TDD since last 5 years. Myth
looks true due to very less adoption ratio. And the one of the reason ( Out of
many is) social barrier.
I see only two class in my Team. And I am a programmer not QA. I cannot
write tests.

Agile Developer
.
• Agile programmers are pros because they take things like software quality very
seriously.
• The best are passionate testers who take pride in their work and are always
looking for an edge in writing higher-quality code.
• To that end, there are certain things agile programmers do when regularly
creating high-quality, production-ready software.
• They write lots of tests and will often use tests as a means of driving out their
designs.
• They are continuously designing and improving the architecture of their software
as they go.
• They make sure the code base is always in a state of production readiness and
ready to deploy at a moment’s notice.

Agile Tester
.
• Agile testers know that although it’s one thing to build it, it is another to know it
works.
• Agile tester will insert themselves into the agile project early, ensuring that
success for user stories gets defined up front and that when working software is
produced, it works.
• Agile tester work closely with developers, helping with test automation, looking
for holes, and doing extensive exploratory testing by trying to break the
application from all possible angles.
• Agile Tester have in mind the big testing picture and never lose site of load
testing, scalability, and anything else the team could be doing to produce high-
quality software.

Lexus Experience
● We used traditional model : Acceptance tests are the responsibility of the testing
team.
● The test team was always at the end of the chain of development, so our
acceptance tests spent most of their lives failing.
● This is not a trivial problem. Acceptance tests are often complex.
● We changed the ownership of the automated acceptance tests.
1. Happy Path
2. Alternative Path
3. Sad Path

Experience
.
“All right… we know what BDD is and understand the importance of Tests but you
know… one day tests started to fail and then one day we got override of it.”
This nonsense seems to be common in across the industry. If test is not running,
means my program isn't running. Don’t deliver it.
In practical, this happens as programmers faces lot pressure apart from programming.
They can’t convenience non-Tech leads about the process and quality.
So the first and most important thing in BDD/TDD is
Support from Leads.

Acceptance BDD … to overcome above problem
.
• Acceptance Business Driven Development (ATDD) is a practice in which the
whole team collaboratively discusses acceptance criteria, with examples,
and then distills them into a set of concrete acceptance tests before
development begins.
• It’s the best way I know to ensure that we all have the same shared
understanding of what it is we’re actually building.
• It’s also the best way known to ensure we have a shared definition of
Done.

Experience … Continued
.
BDD is not only to write Acceptance Test first before Code.
Its philosophy and very highly articulated practice , it needs time to understand, digest
and make it in practice in day to day work.
Next question… Are we following BDD in Lexus? I don’t think so, but we should try.
I think … the day when Programmer thinks first about Test before Code
implementation and Implement functionality through the window of acceptance
criteria compiled by Analysts and QA then we would be on path of BDD.

hugeinc.com
info@hugeinc.com
45 Main St. #220 Brooklyn, NY 11222
+1 718 625 4843

Bdd with Cucumber and Mocha

Recommended

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to Bdd with Cucumber and Mocha (20)

Recently uploaded (20)

Bdd with Cucumber and Mocha