How BDD enables True CI/CD

HOW BDD ENABLES TRUE
CI/CD
ROGER TURNAU
roger.turnau@accenture.com

ROGER
Copyright © 2020 Accenture. All rights reserved.
3
• Agile coach with Accenture’s SolutionsIQ
practice since 2018
• Wrote my first complete software program (a
text-based adventure game) when I was 11
• Ever a glutton for punishment, I became a
professional coder in 1995
• Snuck off when no one was looking to earn
an MFA in Creative Writing from Florida State
in 2008
• Would talk your ear off about TDD and BDD
even if I wasn’t being paid to do so
TECHNOLOGUS HIPPOPHOBOAMITE
• VERY VICIOUS!
• IF SEEN IN THE WILD,
APPROACH WITH
CAUTION
TURNAU, AGILE COACH

Copyright © 2019 Accenture All rights reserved.
PART ONE
A FEW DEFINITIONS
7

8
The shortest possible line between idea and working
software. Benefits include:
• 44% more time spent on new features
• 50% higher market cap growth over 3 years
• 8000x faster deployment lead time
• 50% less time spent fixing security defects
• 50% lower change-failure rate
• 21% less time spent on unplanned work and
rework
CONTINUOUS DELIVERY

9
• A development practice where developers
integrate code into a shared repository
frequently, preferably several times a day.
• In Continuous Integration, the team should
realize immediately if there are any issues
with the code that prevent it from being
deployed.
• “Continuous Integration doesn’t get rid
of bugs, but it does make them
dramatically easier to find and remove.”
– Martin Fowler
CONTINUOUS INTEGRATION

10
• Ensures that code is always in a ready-to-
deploy state by automatically deploying it
to production.
• Every committed change is expected to be
deployed immediately.
• Deployed is not the same thing as released.
CONTINUOUS DEPLOYMENT
Photo by Harshal S. Hirve on Unsplash

PART TWO
WHAT IS BDD?
11

12
Most software systems share the following
characteristics:
• They are shipped with many defects
• The cost of changing them increases over time
• These systems will need to be replaced every 3-5
years.
CURRENT STATE OF DEVELOPMENT

WHY USE TDD/BDD?
13
Time
Development
Cost
Look up
some code
templates
Add a new
feature
Costs of keeping new features
from breaking existing
functionality continue to
increase
Technical debt is out of
control. IT recommends top-
to-bottom rewrite of the
whole system.
A short-lived push to add
unit tests is too little, too
late
Most software today starts out being relatively cheap to
produce. But as technical debt is accumulated, it becomes
more and more expensive to work with.

WHY USE TDD/BDD?
14
With Test-Driven and Behavior-Driven Development, there is
a high initial investment of time and effort, but your
development effort becomes cheaper and faster over time.
Time
Development
Cost
Developers learning
entirely new process.
Mistakes are made.
Because of test coverage,
new features are
guaranteed not to break
old functionality.
At this point, there is
very little technical debt.
New features are easy to
introduce. Deployments
are uneventful.
Production issues are
rare.

15
TEST-DRIVEN DEVELOPMENT
Test Passes
Refactor
Test Fails
A 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).
https://www.agilealliance.org/glossary/tdd

CODE WITHOUT TESTS IS BAD CODE. IT
DOESN’T MATTER HOW WELL WRITTEN IT IS;
IT DOESN’T MATTER HOW PRETTY OR
OBJECT-ORIENTED OR WELL ENCAPSULATED
IT IS.
WITH TESTS, WE CAN CHANGE THE
BEHAVIOR OF OUR CODE QUICKLY AND
VERIFIABLY. WITHOUT THEM, WE REALLY
DON’T KNOW IF OUR CODE IS GETTING
BETTER OR WORSE.
16
Michael Feathers, Working Effectively with Legacy Code

17
Develop Check it works
Develop Check 1 & 2 work
Develop Check 1, 2 & 3 works
Develop Get Bored Stop Checking
Develop, Develop, Develop, Develop, Develop, Develop, Develop, Develop, Develop,
Develop, Develop, Develop, Develop, Develop, Develop, Develop
Test… Hold on… WTH?
Write Unit Tests
UNIT TESTING VS TDD

18
Develop Run Test
Write Test It works
Develop Run Tests
Write Test They work
Develop Run Tests
Develop Run Tests
Test?
UNIT TESTING VS TDD
Test Passes
Refactor
Test Fails

19
• Technical debt-free code. Forever.
• Boring deployments.
• Easy refactoring and re-engineering.
• Code assumptions become self-
documenting.
• New developers learn the system
quicker.
WHAT TDD ENABLES
Photo by Ian Stauffer on Unsplash

• TDD can’t fix a bad design.
• SOLID design principles still need to be
followed. TDD does not replace
architecture.
• TDD, by itself, does not guarantee
alignment with acceptance criteria.
• Although if you’re doing it right, it should.
• TDD does not mean “Unit Tests”
• It’s perfectly acceptable to include some
integration testing in your TDD effort.
WHAT TDD DOESN’T DO

21
• You still need lengthy regression-testing cycles before each
release.
• You have frequent production issues with released code.
• Similar issues happen more than once with the same code base.
It is not enough to fix a bug.
You need to guarantee that bug is fixed
forever.
TDD PROBABLY ISN’T BEING DONE IF…

Copyright © 2019 Accenture All rights reserved. 22
BEHAVIOR-DRIVEN
DEVELOPMENT

23
Introduced in 2006 by Dan North and Chris
Matts to fix some problems their clients had
experienced with TDD adoption:
• Not knowing where to start
• Not knowing what to and what not to test
• Not knowing how much to test in one
attempt
• Not knowing what to call their tests
• Not understanding why a test fails
BEHAVIOR-DRIVEN DEVELOPMENT
Photo by Harshal S. Hirve on Unsplash

24
The problem, they decided, was one of
language. So they created a couple of
clarifying rules:
• Test method names should be sentences
that include the word “should”
• They replaced the term “Test” with
“Specification”
• They replaced the term “Test Case” with
“Scenario
• They proposed Given-When-Then to model
appropriate test behavior
BEHAVIOR-DRIVEN DEVELOPMENT
Photo by Geran de Klerk on Unsplash

25
AND A BRIEF RANT ABOUT WHY I HATE PROCESS DIAGRAMS
TDD
Automated Acceptance
Testing
Business BA UX
BA Testers Developers UI
Designers
Vision
Flow
Capabilities
Features
Business Rules
Examples
Shared Understanding
Executable Specifications
Wireframes
Feedback
Visibility
Valuable software
THE BDD PROCESS

26
Behavior-Driven Development rests on two central ideas:
THE CORE OF BDD
Ubiquitous Language so that
everyone in an organization
can focus on the problem
domain
System development driven by

27
THE CORE OF BDD

28
THE CORE OF BDD
domain

29
Either side will lead to improvements in your process,
but to get the full benefit, you need to do both.
THE CORE OF BDD

30
Here is what BDD adds to standard TDD practice:
THE CORE OF BDD
• Given-When-Then pattern for
creating tests
• Testing behaviors rather than
implementations
• Test case as a sentence that
involves the word “should”
• Guaranteed alignment to
Acceptance Criteria

31
Here is what BDD adds to requirements specification:
THE CORE OF BDD
domain
• Feature Mapping: requirements
discovery
• Example Mapping: creating
testable scenarios
• Three Amigos: Involving
everyone (not just developers)
in test creation
• Combining test creation with
requirements specification

32
Manual Testing
Unit tests: Most of your tests
should live at this level.
Service tests: More expensive to
run and write. No need to
duplicate Unit tests.
E2E and UI tests: use sparingly.
Manual testing: final validation,
and when you cannot automate.
THE AGILE TESTING TRIANGLE

33
BDD DRAWBACKS/CHALLENGES
BECAUSENOTHINGISEVEREASY
Requires a high level of collaboration with the business. Leaders cannot task out
this work and expect a status report later – they must participate in the process.
BDD will not work in a silo – you cannot outsource the tests and expect success.
Test quality matters – if your tests are bad, you will not get the benefits

PART THREE
BDD AND CONTINUOUS
DEPLOYMENT
34

35
In order to achieve Continuous Delivery
and/or Continuous Deployment, your
software must always be in a releasable
state. This requires the following:
• Creating a repeatable, reliable process for
releasing software
• Automate nearly everything
• Keep everything in version control
• If it hurts, do it more often
• Build quality in!
HOW TO GET TO CONTINUOUS DELIVERY

IF IT HURTS, DO IT
MORE FREQUENTLY,
AND BRING THE PAIN
FORWARD.
36
Jez Humble and Dave Farley, Continuous Delivery

37
CI/CD PIPELINE
Source
Repository
Commit
Acceptance
Test
Manual Test
Component
Performance
System
Performance
Data
Migration
Artifact
Repository
• Any code that passes in
this pipeline is releasable
as is.
• Manually test as little as
you can get away with.
• Any testing that can be
automated should be
• This includes security
tests

38
THE DEVOPS SKILL TREE
Think of TDD and BDD like the
Animal Husbandry of DevOps.
It may not seem like much
now, but you’ll need it if you
ever want to explore outer
space.

39
THE DEVOPS SKILL TREE
TDD BDD
Continuous
Integration
Continuous
Deployment
Trunk-Based
Development
Feature Flags

HOW TO GET TO CI
(AND WHY FEATURE
BRANCHING IS EVIL)

41
FEATURE BRANCHING
Always in releasable state
Always Unit Tested
Trunk
Feature A
Your trunk (the “master” in Git) should be always releasable.
Every branch (including your trunk) should have a well-
understood policy associated with it.
A developer will take a branch for each feature under
development. Following TDD, this branch will be covered by
unit tests, which are also checked in with the source code.

42
FEATURE BRANCHING
Always Unit Tested
Always Unit Tested
Trunk
Feature A
Feature B
How do you keep feature branches in synch with any
changes in the trunk?

43
FEATURE BRANCHING
Always Unit Tested
Daily Merges from
Trunk
Always Unit Tested
Trunk
Feature A
Feature B
One widely used solution is to pull from the trunk daily. Any
conflicts can be solved locally by the developer.

44
FEATURE BRANCHING
Always Unit Tested
Daily Merges from
Trunk
Always Unit Tested
Trunk
Feature A
Feature B
However, in the current system, merges back to trunk
happen only when the feature is completed.

45
FEATURE BRANCHING
Always Unit Tested
Daily Merges from
Trunk
Boom!
Integrating the
code back to
trunk is
inevitably a big-
bang effort.
Always Unit Tested
Trunk
Feature A
Feature B
And that gets messy.

47
FEATURE BRANCHING
Always Unit Tested
Daily Merges from
Trunk
Boom!
Unless…
Always Unit Tested
Trunk
Feature A
Feature B
By waiting days or weeks until you merge back, you create a
job of unnecessarily large batch size – a bottleneck.
Integrating the
code back to
trunk is
inevitably a big-
bang effort.

48
CONTINUOUS INTEGRATION
Trunk
Feature A
Always Unit Tested
Feature B
Code is merged back to
trunk on a daily basis.
Always Unit Tested
! !
Integration is re-tested
every day. Problems are
caught earlier. Batch size
is smaller.
Once you get to this point, you do not need any branching

49
Before we all take a flying leap into the
great unknown of continuous integration,
let’s consider the situations in which
doing this won’t work.
JOURNEY TO CI
Photo by Reid Naaykens on Unsplash

50
This is Bob
His new code
changes how we
accept orders.
HOW TO BREAK AN INTEGRATION
This is Gina
Her code re-
categorizes
products.
When they integrate
their code to trunk
that evening…

51
Bob’s code is using the old product object code, so it breaks.
Gina’s code assumes the old order workflow, so it breaks.
The system is down. Angry emails circulate. Dogs start barking.

52
In order to be delivering continuous integration, we must, at a
minimum, do the following:
• Hide new functionality until it is finished.
• Allow incremental changes to be merged into trunk, even if it’s
currently in an unusable state.
• Again, this depends on TDD/BDD! The
behavior of your code must be
predictable.

THE SOLUTION:
FEATURE FLAGS

54
At its simplest, a feature flag wraps new functionality in an if/then
structure in order to control its release.
if ( featureExists(“newOrder”)) {
// use the new order/product logic
} else {
// use the old logic
}
WHAT IS A FEATURE FLAG?

55
Even better would be to create a new implementation, and to use
a factory method to control implementation at run time.
WHAT IS A FEATURE FLAG?
if ( featureExists(“newOrder”)) {
// inject the new implementation
} else {
// inject the old implementation
}
NewClass
OldClass

56
TRUNK-BASED DEVELOPMENT
Trunk
Includes
Features
A and B
Feature A
Feature B
Always in deployable state
Code is checked into
trunk.
! !
Feature is switched on,
which releases it to
users. Release is
separated from
deployment.
Feature flags remove the need for branching.

57
FEATURE FLAGS
New Feature Feature Flag or Toggle
On
Off
Off
Consumers

COMMON
OBJECTIONS TO
BDD/TDD

64
”Hi! Should we wash our
hands before your
operation? What do you
think?”
BUT OUR MANAGERS WON’T LET US!
By the end of this course, you should
understand why development teams do
not need permission to implement
TDD/BDD.
• Automated test-first practices are not
not optional.
• They are a professional duty of care.

65
Maintenance costs for software are between 40% to 80% of total
cost. Many companies myopically optimize for speed through
development phase but neglect the waste that this creates.
IT WILL SLOW US DOWN!

66
Even though BDD feels like it’s slowing you
down, its overall, long-term effect is to speed
you up.
You literally cannot do Continuous Delivery
without solid automated testing.
According to Accelerate, test automation
predicts better IT performance when:
1. Tests are reliable: the team trusts that when
the tests pass, the software is releasable
2. The tests are created by the team, not by an
outside vendor or a siloed QA organization.
BDD’s IMPACT ON DELIVERY SPEED

67
Again, the benefits of true Continuous Integration
and Continuous Deployment far outweigh short-
term costs.
• 44% more time spent on new features
• 50% higher market cap growth over 3 years
• 8000x faster deployment lead time
• 50% less time spent fixing security defects
• 50% lower change-failure rate
• 21% less time spent on unplanned work and
rework
YOU CAN’T AFFORD NOT TO USE BDD

How BDD enables True CI/CD

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à How BDD enables True CI/CD

Similaire à How BDD enables True CI/CD (20)

Dernier

Dernier (20)

How BDD enables True CI/CD