Gateway to Agile: XP and BDD

GATEWAY TO AGILE
Taste of XP – BDD Event

ROB, LARRY, PANEL
 Rob Trivetti, MATRIX, Sr Agile Coach, Empower Agile. He has experience
managing complex, high priority, cross-functional and time-sensitive
programs for Agile transformations, social media, eCommerce, SAAS and
telecom companies. Agile leader at AT&T, Intuit, LinkedIn, Walmart, to name
a few. Rob is a West Point graduate and served as the US Army Captain in
the Signal Corps.
 Larry Apke is the Agile Program Manager at Oracle. Larry has fulfilled roles:
Agile Leader, Program Manager, Senior Business Analyst, Business
Analyst, and Technical Writer at many organizations. Proven Leader in Agile
Development – Certified Scrum Master (CSM) - Certified Scrum Practitioner
(CSP) - Certified SAFe Agilist (SA). The author of Understanding The Agile
Manifesto: A Brief & Bold Guide to Agile. A recognized leader in the Agile
community and expert speaker, giving presentations to many different
groups such as the Scrum Users Group, Java Users Group, Desert Code
Camp and others. Founder of the Agile Coffee Group in San Antonio.

EXTREME
PROGRAMMING (XP)
AND BDD
Agile Ecosystem Thread #3

XP/BDD
Panel
Next
Event
OUR
AGENDA

AGILE ECOSYSTEM
XP and BDD
practice
thread

Building in Quality: Behavior Driven
Development (BDD)

BDD Begins with Test Driven Development (TDD)

Why Do TDD?
• Maintainability
• Flexibility
• Extensibility
• High Rate of Test Code Coverage
• Streamlined Codebase
• Cleaner Interfaces
• Easier Refactoring of Code
• Tests Provide Some Code Documentation
• Bottom Line - Higher Quality

TDD Quotes from “Uncle Bob”
“It is a myth that we can get systems “right the first time.” Instead, we should implement
only today’s stories, then refactor and expand the system to implement new stories
tomorrow. This is the essence of iterative and incremental agility. Test-driven development,
refactoring, and the clean code they produce make this work at the code level.”
Robert “Uncle Bob” Martin is a software development professional
since 1970, co-author of the original Agile Manifesto, author of
numerous books on code quality including Clean code: a handbook
of agile software craftsmanship and The clean coder: a code of
conduct for professional programmers.

“The Three Laws of TDD:
1) You may not write production code until you have written a failing unit test.
2) You may not write more of a unit test than is sufficient to fail, and not compiling
is failing.
3) You may not write more production code than is sufficient to pass the currently
failing test.”

“Indeed, the ratio of time spent reading versus writing is well over 10 to
1. We are constantly reading old code as part of the effort to write new
code. ...[Therefore,] making it easy to read makes it easier to write.”
“So if you want to go fast, if you want to get done quickly, if you want
your code to be easy to write, make it easy to read.”

“A system that is comprehensively tested and passes all of its tests all of the time is a
testable system. That’s an obvious statement, but an important one. Systems that aren’t
testable aren’t verifiable. Arguably, a system that cannot be verified should never be
deployed.”
“If the discipline of requirements specification has taught us anything, it is that well-
specified requirements are as formal as code and can act as executable tests of that code!”

“Perhaps you thought that “getting it working” was the first order of business for a
professional developer. I hope by now, however, that this book has disabused you of that
idea. The functionality that you create today has a good chance of changing in the next
release, but the readability of your code will have a profound effect on all the changes that
will ever be made.”
“Programmers who satisfy themselves with merely working code are behaving
unprofessionally. “
“Writing clean code is what you must do in order to call yourself a professional. There is no
reasonable excuse for doing anything less than your best.”

In addition to Test Driven Development and writing testable, readable code, there are a
number of other things that go into making one a professional programmer.
• Your code must be secure
• Your code must be performant
• Your code must be deployable
• Your code must integrate (preferably using Continuous Integration)
In other words, code quality must be injected into the code by the professional
programmer. Quality cannot be inspected into the code ex post facto (after the fact)
The Professional Programmer

Why Doesn’t Everyone Do TDD?
• Most developers have not learned TDD
• There is a learning curve associated with learning TDD
• TDD is extremely disciplined
• There is a perception that development is slower
• It is difficult to introduce with legacy code
• Developers often need to mock objects and learn mocking
“I kept coming across the same confusion and misunderstandings. Programmers wanted to
know where to start, what to test and what not to test, how much to test in one go, what to
call their tests, and how to understand why a test fails.” - Dan North - Introduction to BDD

Along Comes BDD
• Behavior Driven Development
• Originally invented by Dan North to address the issues that developers where having
with TDD
• “My response is behaviour-driven development (BDD). It has evolved out of established
agile practices and is designed to make them more accessible and effective for teams
new to agile software delivery. Over time, BDD has grown to encompass the wider
picture of agile analysis and automated acceptance testing.”
• Created a “ubiquitous language for the analysis process itself!”
• Over time they found that the conversations between business and development where
richer

Why Do BDD?
• TDD build it right, BDD builds the right thing
• While there is no silver bullet to software development, BDD (when coupled with
continuous integration) comes as close as anything I have found
• My blog - “10 Reasons Why BDD Changes Everything” was published on 3/6/2012 and
still is the most visited page on my website

10 Reasons Why BDD Changes
Everything
• Communication between business and development is extremely focused as a result of
common language.
• Business needs tie directly to the code that is written.
• Developers know what test cases they should write to accommodate TDD.
• All the underlying benefits of TDD become more easily realized.
• Code is easier to maintain.
• Code is self documenting.
• Stories are easier to “groom” – breakdown, task and plan.
• Teams can be more agile.
• Developers can be trained / on-boarded easier.
• There is more visibility into team progress and status.

Step One
Write our story acceptance criteria using BDD scenarios
Step Two
Leverage these BDD scenarios to write our automated tests first in true TDD fashion
Step Three
Leverage a BDD Tool like Cucumber to map human-readable BDD scenarios to the
automated tests
Adopting BDD in Three Simple Steps

Step One is accomplished by the three amigos - Product Owner, Developer(s) and Quality
Assurance Person(s).
Step One is accomplished during Story Refinement which is where we go into detail for the
stories that we believe we will take during the next iteration.
This is the first step in transitioning to BDD and the one that brings the most benefit. It was
a pleasant surprise to Dan North and crew, something that they did not plan. Better
communication equals better quality.
Step One - Write Stories With BDD
Acceptance Criteria

Acceptance Criteria
The Story
Customer withdraws cash
As a customer,
I want to withdraw cash from an ATM,
so that I don’t have to wait in line at the bank.

The Story
As a customer,
Scenario 1 - Account is In Credit
Given the account is in credit
And the card is valid
And the dispenser contains cash
When the customer requests cash
Then ensure the account is debited
And ensure cash is dispensed
And ensure the card is returned
Acceptance Criteria

The Story
As a customer,
Scenario 2 - Account is overdrawn past the overdraft limit
Given the account is overdrawn
And the card is valid
When the customer requests cash
Then ensure a rejection message is displayed
And ensure cash is not dispensed
And ensure the card is returned
Acceptance Criteria

In step two we leverage BDD to write our tests and begin the process of TDD. BDD
scenarios can be written directly into tests using comments.
Step Two - Put Your BDD A.C. into
Tests

public class AccountIsInCredit extends TestCase {
@Setup
//Scenario 1 - Account is In Credit
// Given the account is in credit
// And the card is valid
// And the dispenser contains cash
Write code here to mock out account and add credit, mock out card and set as valid, etc.
//When the customer requests cash
Call CustomerRequestsCash class (or merthod) and pass values return computed values
@Test
//Then ensure the account is debited
// And ensure cash is dispensed
// And ensure the card is returned
Assert.AssertEquals(ExpectedAccountBalance, Account.Balance);
Assert.AssertEquals(CashDispensed, True);
Assert.AssertEquals(CardReturned, True);
}
Step Two - Put Your BDD A.C. into
Tests

• BDD Tool will take human-readable scenarios and use regular expressions to map the
human readable scenarios to Unit Tests.
• BDD Tools will create a unit test and shell automatically (referred to as a step definition
file) that helps in the creation of test.
• When the BDD Tool runs the tests, the output shows which tests passed and failed
against the human-readable scenarios.
• There are BDD Tools for all major languages
Step Three - Use BDD Tool

Scenario: Cutting vegetables
Given a cucumber that is 30 cm long
When I cut it in halves
Then I have two cucumbers
And both are 15 cm long
Given(/â cucumber that is (d+) cm long$/) do |arg1|
pending # express the regexp above with the code you wish you had
end
When(/Î cut it in halves$/) do
end
Then(/Î have two cucumbers$/) do
end
Then(/^both are (d+) cm long$/) do |arg1|
end

Given /â cucumber that is (d+) cm long$/ do |length|
@cucumber = {:color => 'green', :length => length.to_i}
end
When /Î (?:cut|chop) (?:it|the cucumber) in (?:halves|half|two)$/ do
@choppedCucumbers = [
{:color => @cucumber[:color], :length => @cucumber[:length] / 2},
{:color => @cucumber[:color], :length => @cucumber[:length] / 2}
]
end
Then /Î have two cucumbers$/ do
@choppedCucumbers.length.should == 2
end
Then /^both are (d+) cm long$/ do |length|
@choppedCucumbers.each do |cuke|
cuke[:length].should == length.to_i
end
end

#encoding: utf-8
Feature: Showcase the simplest possible cucumber scenario
In order to verify that cucumber is installed and configured correctly
As an aspiring BDD fanatic
I should be able to run this scenario and see that the steps pass (green like a cuke)
Scenario: Cutting vegetables # features/first.feature:8
Given a cucumber that is 30 cm long # features/step_definitions/first_steps.rb:3
When I cut it in halves # features/step_definitions/first_steps.rb:7
Then I have two cucumbers # features/step_definitions/first_steps.rb:14
And both are 15 cm long # features/step_definitions/first_steps.rb:18
1 scenario (1 passed)
4 steps (4 passed)
0m0.005s

Bonus Step - Use Tool Like Serenity to
Visualize Test Suite

BDD Gone Wrong
In the Cucumber Book, the authors describe four things that can go wrong with Cucumber
scenarios:
• Flickering Scenarios - Tests are failing randomly
• Brittle Scenarios – Tests keep breaking unintentionally
• Slow Features – Tests are taking too long to run
• Bored Stakeholders – Stakeholders do not read our features
The Cucumber Book outlines potential problems and solutions.
BDD and TDD is a commitment. Tests are code and must be treated as such. They will
need to be maintained the same as the rest of the code.

Helpful Links
• Dan North - Introduction to BDD
• The Cucumber Book: Behaviour-Driven Development for Testers and Developers
• BDD in Action: Behavior-driven development for the whole software lifecycle
• Specification by Example: How Successful Teams Deliver the Right Software
• Cucumber Tool
• Serenity Tool
• Clean Code: A Handbook of Agile Software Craftsmanship

GATEWAY TO AGILE
XP and BDD Next

AGILE ECOSYSTEM
Dark Agile is created by
improper alignment and
care of your Agile
Ecosystem AND
Unhappiness

DARK AGILE
PATTERNS
Technocentrics
Self-Absorbed
Augmented Reality
Laissez-Faire Grand Unified Theory

TECHNOCENTRICS
Too much Focus on Agile
Practices and Tools
Individual Collective
(Limited) Interior

SELF-ABSORBED
Too much Focus on Agile
Practices and Tools +
Agile Humanity
All Individual Interior

AUGMENTED REALITY
Little or No Focus on
Organization and Culture
& Environment
Individual Collective
(Selective) Interior

LAISSEZ-FAIRE
Insufficient Focus or
Alignment Across
Quadrants
Individual + Collective
Interior + Exterior
Minimalist

GRAND UNIFIED THEORY
Too Much Focus on Each
Quadrants, No
Synchronicity
Individual + Collective
Interior + Exterior
Extermist

GATEWAY TO AGILE
Roadmap and Interests Groups

GRAND CHALLENGE
Team to organize and operate
grand challenge
Prize $TBD

EVENT COORDINATION
Team to help with
Meetup and Events

SPONSOR MANAGEMENT
Team to help with
Sponsors

THANK YOU
NEXT: Design Thinking (MVP)
And Design Sprints

Gateway to Agile: XP and BDD

Related slideshows

More Related Content

Gateway to Agile: XP and BDD

Editor's Notes