Experiences introducing BDD and BDD elements

To unit testing and a legacy codebase

XP 2010, June 3rd 2010

Background

A local, familyman, 2 children

Developer, Consultant

BEKK Consulting

10+ years

Seen many types of projects

@ah74

hammervold.com/anders

Background: What I had seen a lot of

POUT

Some testclasses of several k+ lines

Often excellent testcode

Difficult to understand for others

Difficult to come back to after some time away

Focus on test techniques like Mocking

Refactoring later would mean rewriting complex code AND complex tests

in a hurry? remove tests that are red

BDD and ”BDD elements”

BDD

Started seeing BDD inspired syntax and thinking

Ground up

Which effect did this have ?

Did it correspond with the goals of BDD?

What was happening in other projects right now ?

Examples

Example: BDD using Cucumber features

http://www.engineyard.com/blog/2009/cucumber-introduction/

Example: ”BDDTest”

Adapted from and inpired by code and examples from: Torbjørn Marø and Jonas follesø

Example: ”BDDTest” adapted

Example: Glue

Tore Vestues, http://glue.codeplex.com

Experiment: Regions

Experimental,

IDE-specific

Effects: The skeptic

”I know how to write tests”

Effects: The skeptic

”Wow this test became so much simpler!”

”This was almost fun”

How

~20 minute interviews

– Developers

– Testers

– Customers

5 different projects

– May 2010

Objections?

Some arguments used were the same as against TDD

Fear of change

Technical problems, sometimes new technology

Unwillingness to learn something new

Not true BDD, outside in through ui

Developer perspective

Clear sense of purpose

Recipe to follow

Renewed focus on specification

Smaller, simpler tests

Easier to maintain

Most tests now got a similar structure

Greater number of tests but better organised

”I give up, i’ll rather go write some BDD-tests,

maybe that will cheer me up”

Customer perspective

”The bug-rate dropped significantly”

”I could see that they (the developers) had understood what I meant”

”I never understood the code anyway”

– Generally responded well to the syntax

– Customers were generally more agile than developers perhaps expected

– When given a chance

– Clarifying requirements

Success

Many of the results can be attributed to TDD

BDD elements added to and amplified these

Skeptics became ”believers”

The customers showed greater involvement

Testers could write features in the error report

Some success-criteria

Access to a mentor

Commitment from the team

Willingness to learn

Including the customer