scaffolding a legacy app with bdd scenarios using specflow/cucumber (bdd london meetup, skills...

Scaffolding a legacy app with BDD scenarios using SpecFlow/Cucumber

BDD London Meetup, Skills Matter24/5/2016

Gáspár Nagycoach • trainer • bdd addict • creator of specflow

@gasparnagy • [email protected]

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 +

Automationon 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

Complex domain…

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?

Source: Wikipedia


The first change request

Deployment –

Workflow


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


1. Capture current behaviorRed


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!

1

2

3

4

5

8

9

#6

7

5. Pick off a bite!

1

2

3

4

5

8

9

#6

7

Aut

#

#’


5. Pick off a biteRefactor


We have scaffolded our application for implementing this feature!


6. Describe the new featureRed


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…


1. Capture current behavior

• 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 Nagycoach • trainer • bdd addict • creator of specflow

@gasparnagy • [email protected]

Thank you!

scaffolding a legacy app with bdd scenarios using specflow/cucumber (bdd london meetup, skills...

Software