Scaffolding a legacy app with BDD scenarios using SpecFlow/Cucumber (BDD London Meetup, Skills Matter, 24/5/2016)

Scaffolding a
legacy app with
BDD scenarios
using SpecFlow/Cucumber
BDD London Meetup, Skills Matter
24/5/2016
Gáspár Nagy
coach • trainer • bdd addict • creator of specflow
@gasparnagy • gaspar@specsolutions.eu
sponsors:

Copyright © Gaspar Nagy
bdd addict
given.when.then
CAUTION!
bddaddict.com
on the stage

In my brain…
• Support SpecFlow contrib team
• SpecFlow for .NET Core
• Behavior driven UI automation
• BDD Addict Newsletter (bddaddict.com)
• Gherkin parser (now for elixir)
• Integration of Gherkin scenarios to TFS/MTM
• Property-based testing with BDD
• “SpecFlow Tips” blog series on gasparnagy.com
• Promote agile testing & BDD in Hungary
• SpecFlow book
• Challenges of applying BDD to legacy apps

What is BDD?

BDD =
Product Ownership +
Collaboration +
Automation
on the product
of requirements
real

Smart Calculator
Demo: BDD Drives
Development

How can I apply this
to legacy apps?

Working with a legacy app is like
renovating a house…

Renovation can be
challenging…
Source: http://kadarkocka.blogspot.com/2011_08_01_archive.html

My Story
The project was delivered in cooperation with TechTalk (www.techtalk.at)

It was modern…
Source: http://irodahaz.info

106 failing (integration?) tests

… and other challenges
• 17 GB test database
• 46 projects
• 300k lines of code
• >2 minutes build time

What can I do with this?

The first change request

0. Get the infrastructure ready
We need a healthy local dev and CI environment!
• Make a dummy test and get it running!
• Ignore/skip/delete unstable
tests
• Setup the desired testing
model (e.g. SpecFlow)
• Test core dependencies
(e.g. “When I do
something with the
database”)

1. Capture current behavior
• Based on the way it was demoed to you
• Do not worry about automation
• Do not worry about details
• Do not worry about exact phrasing

TDD Cycle

ATDD Cycle

Red

2. Automate “Then” steps
• Feel free to hard-wire concrete data (IDs)!
Red

3. Improve errors
Our scenario fails. Is it easy to understand why?
• Check the test output and improve if necessary!
Red

4. Automate “When”
with hard-wired data
• We have something to start with!
• (But its obviously nasty with “2347599”)
Green

We need to get rid of the hard-wired
data!

5. Pick off a bite!
1
2
3
4
5
8
9
#6
7
Aut
#
#’

5. Pick off a bite
Refactor

We have scaffolded our application
for implementing this feature!

6. Describe the new feature
Red

7. Automate and implement
it
• You can even forget that your are maintaining a legacy
app here…
Green

8. Discover corner cases
• We have seen a “happy path” so far…
• But what happens if…
• …there are associated deliverables
• …the package is partially frozen
• …

9. Pick low hanging fruits
• We have developed an automation interface for a part
of the application
• Can we use it to cover other usual cases?

Summary: The first change
request
• We addressed the system through a new feature
• Ensured that the test infrastructure works
• Scaffolded the app with a test for the current behavior
using hard wired data
• Refactored the automation to eliminate some parts of
these data – taken apart a bit of the scaffolding
• Described and implemented the new feature
• Used the automation infrastructure for further tests

The first bug

This is a nasty bug…
• Because
• Workflow is handled by WF 3
• Script is executed on a remote machine through SSH
• A very old dead OSS project is used for SSH (no timeout
setting)
• I cannot even try this out!

Ok… calm down.
We have a process…

• Do not worry about automation
• Do not worry about details
• Do not worry about exact phrasing
Red

2. How to test SSH?
A focused scenario can drive you to find a solution for
automation
• Find a tool that can be well automated and can be
used for SSH – Vagrant?
• Set it up locally (don’t worry about the automation yet)
• Make the test pass with the local setup
• Do you remember deployment #2347599?
• Refactor: Eliminate hard-wired details
Green

3. Describe bug as a
scenario
Red

4. Fix the bug!
• With the test we could find the bug that was actually in
the SSH library
Green

Shall we keep regression tests?
• It depends…
• If the bug highlighted an important business case –
keep it!
• If it described a special situation (and the bugfix was
covered by unit/integration tests) – delete it!
• Maintaining regression tests is very costly!

Summary: The first bug
• Similarly to new features, addressing the bugs by
capturing the current behavior as scenarios is helpful
• Don’t be afraid of deleting the regression test after
fixing the bug if it does not represent an important
business case

Working on a legacy app does not
mean that you cannot apply BDD
process.
The scenarios can guide you to
discover more and more from the
application!

Happy maintenance!

bdd addict
given.when.then
CAUTION!
bddaddict.com
on the loose

Gáspár Nagy
coach • trainer • bdd addict • creator of specflow
@gasparnagy • gaspar@specsolutions.eu
Thank you!

Scaffolding a legacy app with BDD scenarios using SpecFlow/Cucumber (BDD London Meetup, Skills Matter, 24/5/2016)

More Related Content

Scaffolding a legacy app with BDD scenarios using SpecFlow/Cucumber (BDD London Meetup, Skills Matter, 24/5/2016)