This document discusses test-driven development (TDD) and behavior-driven development (BDD). It describes how BDD uses conversations to discover requirements and build shared understanding. BDD captures conversations as executable specifications expressed in a common language. TDD follows the "Red-Green-Refactor" process of writing a failing test, adding code to pass the test, and refactoring code. TDD drives better design through incremental development guided by tests and prevents overdesign. While TDD can improve design, it also risks overly complex test code and dependencies if not kept simple. The document advocates starting with examples to guide development and testing in a test-driven manner.

1. Being Test-Driven
It’s not really about testing
Raj Indugula George Lively
Raj.Indugula@lithespeed.com George.lively@lithespeed.com
Twitter: @lithespeed

2. 2
What is the point of
test-driven
development?

3. • Driving Common Understanding
with Behavior Driven Development
• Driving Better Design with Test-
Driven Development
• Tying it all together
• Q&A
Outline
“The speed of
development is the
speed of getting an
idea from one brain to
another”
– Alistair Cockburn
3

4. BDD IS BUILDING
THE RIGHT THING
Behavior-Driven Development (BDD)

5. Behavior Driven Development (BDD)
5
Collaboration and
conversation to
discover essential
requirements and
identify uncertainty
Using rules & examples
Expressed in a common
language to build a
shared understanding
To deliver software that
matters

6. Behavior Driven Development (BDD)
6
Collaboration and
conversation to
discover essential
requirements and
identify uncertainty
Using rules &
examples
Expressed in a
common language to
build a shared
understanding
To deliver software that
matters

7. HAVE
CONVERSATIONS
BEFORE
WRITING CODE

8. BDD IS THE ART
OF USING RULES
& EXAMPLES IN
CONVERSATIONS
TO ILLUSTRATE
BEHAVIOR
8

9. 9
Different Viewpoints,
Shared Understanding
9
Business, Developer, Tester
Shared understanding
All agree it is ready to be
implemented
THREE AMIGOS
9
Example Mapping, Matt Wynne
Depositor can
withdraw cash
Limited by
amount on
deposit
Subject to daily
and transaction
limits
Scenario with
sufficient
funds
Limited by daily
limit of $500
What is the
transaction
limit?
Cash is dispensed in
$10 increments with
$20 bills favored
Scenario with
insufficient
funds
Fully stocked scenario
when withdrawal of
$50 results in 2 $20
bills and 1 $10 bill
When out of $20s,
withdrawal of $50
results in 5 $10 bills
Acceptance
Scenarios
Acceptance
Criteria

10. 10
CAPTURE THE
CONVERSATIONS TO DRIVE
DEVELOPMENT

11. 11
Feature: ATM withdrawals
Our ATM allows depositors to withdraw their funds in cash
Rules:
Withdrawals are limited by amount on deposit
Withdrawals are subject to daily and transaction withdrawal limits
Cash is dispensed in $10 increments with $20 bills favored
Scenario: Sufficient funds allows successful withdrawal
Given a depositor has $2000 on deposit
When the depositor requests $200
Then the ATM dispenses $200
And the depositor’s balance is reduced to $1800
…
DocumentationHuman readable Structured and
keyword-based
Allows automation
Gherkin

12. 12
AUTOMATE SPECIFICATIONS
AS NEEDED
Test
Framewor
k
Integratio
n
Gherkin
Scenarios
Specification
expressed in
common
language
Step
Definitions
“Glue” code
that ties
specification to
System under
Test
Cucumber,
SpecFlow, etc.

13. 13
HAVING
CONVERSATIONS
>>
CAPTURING
CONVERSATIONS
>>
AUTOMATING
CONVERSATIONS
Liz Keogh

14. Test-Driven Development (TDD)
TDD IS BUILDING
THE THING RIGHT

15. Reimagine our thinking…
15
How we typically
write tests…
1. Think about
implementation
2. Write code (fields &
methods)
3. Write some test
cases to verify
behavior
Instead, what if we…
1. Write a test to capture
expected behavior?
2. Think about
implementation to meet
expectation?
3. Write code to make the
failing test pass?
Build functionality
incrementally one test at a
time…

16. Test-Driven Development (TDD)
16
Write a
new test
Test Fails
Write Code
Test
Passes
Clean up
code,
make sure
tests pass
start here
Style of programming
in which three
activities are tightly
interwoven: coding,
testing (in the form
of writing unit tests)
and design (in the
form of refactoring)
Developer
heartbeat
Red – Green - Refactor

17. Business Benefits
Requirements
verification
Regression
catching
Quicker
release cycle
Reduced
Waste

18. Developer Benefits
Better design
choices
Prevents gold-
plating
Confidence /
Supports
change
Momentum

19. Extreme Programming (XP)
- Kent Beck 19
Feedback &
Simplicity

20. But there’s no free lunch…
20
Here are some ways that TDD can lead to WORSE design:
• In search of speed, developers will lean too heavily on mocks, locking in
place their production code and making refactoring more difficult
• Developers will build elaborate dependency injection tools and
structures, making their design highly complex and unmaintainable.
REMEMBER: the emphasis should be on SIMPLE DESIGN, and not just for
your application code but also for your test code.
Source: https://www.jamesshore.com/Blog/How-Does-TDD-Affect-
Design.html

21. Source Adaptation: BDD in Action
Business Goals Features
Rules &
Examples
Executable
specifications
Low-level
specifications
Application
Code
User
stories
Only build features
that align with
business goals
Features and stories
clarified with rules
and examples
Guide development &
testing. Can be read by
whole team
Features broken
down into smaller
user stories. Help
plan how we
deliver a feature
Unit tests aimed
mostly at
developers
Automatable with BDD
tools like Cucumber,
Specflow
Unit testing tools like
JUnit, NUnit
21
Principle Activities Summarized

22. Source Adaptation: Raj Indugula & George Dinwiddie
Scenario: Invalid example
Given I am a new user
When I select "Abc1*$!-**" as a
password
Then I can access my account
Scenario: Cash dispensed when
machine has no $20 bills
Given the ATM is out of $20 bills
When a depositor withdraws $50
Then the ATM dispenses 5 $10 bills
22
From Test-last to Test-driven
conversations
Building the right thing
Building the thing right

23. 23
Being test-driven isn’t really
about testing. It’s about
specification and design
driven through tests