Using Behavior Driven Development and Feature Injection to Build Better Software

Using Behavior Driven Development

and Feature Injection to Build Better Software

Jeffrey Davidson@JeffreyGoodReqgoodrequirements.com

BBCCon2011:bafNovember 3, 2011

© Jeffrey Davidson, 2011

BDD Fundamentals

I can teach you this in less than 1 minute . . .

Are you ready?

Seriously. Do you have your pencil ready?

Can someone time me?

© Jeffrey Davidson, 2011

60 minutes in less than 60 seconds

Without using any technical language…

Describe who you are and what your condition isAnd what you do And how the system responds

© Jeffrey Davidson, 2011

– –Given

You & Your condition

What you do

What you see

Simple Structure

When

Then

© Jeffrey Davidson, 2011

Given – When – Then

You now know enough to succeed.

Go! Enjoy another session.

© Jeffrey Davidson, 2011

Today’s Agenda…

Fundamentals of BDDFormal definitionWhat is BDD?How to use BDDWhy being less specific is importantBenefits Why you should careWhy BDD isn’t testingMore Fundamentals (Feature Injection)How to use Feature InjectionHow this directly relates to BDD

© Jeffrey Davidson, 2011

Not Today’s Agenda

Discuss BDD Tools Give automation advice Share code quality practices

© Jeffrey Davidson, 2011

What is BDD?

“BDD is a second-generation, outside-in, pull-based, multiple-stakeholder,

multiple-scale, high-automation, agile methodology. It describes a cycle of

interactions with well-defined outputs, resulting in the delivery of working,

tested software that matters.”Dan North @ Agile Specifications, 2009

© Jeffrey Davidson, 2011

What is BDD?

Fine grained, focused bits of behavior

Told in a story format

No, really, what is it?

© Jeffrey Davidson, 2011

Stories & Story Format

When you take a few minutes to talk to your co-workers, your boss, your spouse, and your family . . .

. . . do you give facts or context?

© Jeffrey Davidson, 2011

Stories & Story Format

I dream of . . . adventure, challenge, success

© Jeffrey Davidson, 2011

Stories & Story Format

Have you ever dreamed of . . . facts?

Yuck!

© Jeffrey Davidson, 2011

Stories

We use stories to communicate.

© Jeffrey Davidson, 2011

Do you mean User Stories?

“As a . . . , I want . . . , So . . . .”

© Jeffrey Davidson, 2011

User Stories are Statements

User Stories do not give all the preconditions Or all the actors actions Or all the system responses

Promise of a future conversation

© Jeffrey Davidson, 2011

Two Steps

Start with business goalsIn Agile development, this is a User Statement Story

Build Scenarios

© Jeffrey Davidson, 2011

– –Given

You & Your condition

What you do

What you see

Simple Structure

When

Then

© Jeffrey Davidson, 2011

Simple Structure

Given [CONTEXT]

When [EVENT OCCURS]

Then [OUTCOME]

© Jeffrey Davidson, 2011

Given

OLD?

NEWGiven I am . . .

<<Who & Where & What has already happened &

etc.>>

State your action in natural language

© Jeffrey Davidson, 2011

When

OLD?

NEWWhen I <<perform some action>>

State your action in natural language

© Jeffrey Davidson, 2011

NEWThen I see …

Then

OLDThe system shall …

This is how you observe the system’s response

State your action in natural

language– OR –

WRITE LIKE A HUMAN

© Jeffrey Davidson, 2011

Be Like Aldi

Generic behavior

Don’t include design.

Imagine performing the same actions on a telephone interface!

© Jeffrey Davidson, 2011

Simple Structure

Given [CONTEXT]

When [EVENT OCCURS]

Then [OUTCOME]

© Jeffrey Davidson, 2011

I want to withdraw $ from ATM (An example)Scenario #1: Account has sufficient funds

Given the account balance is 100  and the card is valid  and the machine contains enough moneyWhen the account holder requests 20Then the ATM should dispense 20  and the account balance should be 80  and the card should be returned

© Jeffrey Davidson, 2011

What is it?

It’s a bunch of tiny stories, using a particular grammatical structure.

It’s finding places of misunderstanding, and filling it with understanding.

It’s a conversation, captured.

© Jeffrey Davidson, 2011

Why?

© Jeffrey Davidson, 2011

Simple Made Easy

“We can only hope to make reliable those things that we can understand.We can only consider a few things at a time. Intertwined things must be considered together. Complexity undermines understanding.”

Rich Hickey @ StrangeLoop 2011

© Jeffrey Davidson, 2011

Built right or Right product?

Gojko Adzic in Specification by Example, 2011

© Jeffrey Davidson, 2011

Benefits

To build the right product effectively, software dev practices need:

Gojko Adzic in Specification by Example, 2011

© Jeffrey Davidson, 2011

Benefits

To build the right product effectively, software dev practices need:

Assurance all stakeholders & delivery team members understand what needs to be delivered in the same way.

Gojko Adzic in Specification by Example, 2011

© Jeffrey Davidson, 2011

Benefits

To build the right product effectively, software dev practices need:

Precise specifications so delivery teams avoid wasteful rework caused by ambiguities and functional gaps.

Gojko Adzic in Specification by Example, 2011

© Jeffrey Davidson, 2011

Benefits

To build the right product effectively, software dev practices need:

An objective means to measure when a piece of work is complete.

Gojko Adzic in Specification by Example, 2011

© Jeffrey Davidson, 2011

Benefits

To build the right product effectively, software dev practices need:

Documentation to facilitate change, in terms of both software features & team structure.

Gojko Adzic in Specification by Example, 2011

© Jeffrey Davidson, 2011

Who Benefits?

Everyone!

Seriously, it helps everyone. • Business • Users • Testers • Developers • Analysts

© Jeffrey Davidson, 2011

Blah, Blah, Blah – Why should I care?

Ferries & Bridges

© Jeffrey Davidson, 2011

Isn’t this just testing?

Seems like TDD to me

“Umm, what’s TDD?”

If you’re doing TDD, then BDD is a great next step.

© Jeffrey Davidson, 2011

Acceptance Test Criteria

Tests code or functionality

Presumes the test is right

Who really cares about the functionality? • It’s an IT term!• Users care about the behavior

© Jeffrey Davidson, 2011

BDD > TDD

Presumes we don’t know everything

So we ask about scenarios

It’s about behavior • You can only learn about behavior from

conversation Behavior leads to design

“Can you give me an example?”

© Jeffrey Davidson, 2011

Is it like testing?

Sort of…

Specifications are written in such a precise way we can execute them

© Jeffrey Davidson, 2011

Testing Tools

JBehave (java)RSpec, Cucumber (ruby)Lettuce (python) Nbehave & Nspec (.NET)FIT & FitNess (multiple) Etc.

There are lots of tools to use

© Jeffrey Davidson, 2011

It’s not about tools

“These tools are intended for use by programmers to guide coding, but they can also be used to express business facing tests that drive development, involving customers more closely in the process.”

Lisa Crispin in Agile Testing, 2009

© Jeffrey Davidson, 2011

Downsides

May not help velocity

New

Tools (and all that jazz) may cause clutter, slow-down, new learning, other stuff

© Jeffrey Davidson, 2011

Wait a minute!

What happened to Feature Injection?

© Jeffrey Davidson, 2011

Build Software That Matters

Start with a business goal

Hint: Businesses want to increase, conserve, or protect $.

© Jeffrey Davidson, 2011

Feature Injection

The value of an IT system is in it’s outputs / outcomes

Model based on desired results

Follow Information Smells to identify that may be missing from your model

© Jeffrey Davidson, 2011

Value is what matters

If you want to add value . . .

. . . don’t argue about features

. . . ask about why

© Jeffrey Davidson, 2011

Think like an investor

Every project is an investment.

Picture a Business Investor

Why does your Business Investor want to do this project?

© Jeffrey Davidson, 2011

Why invest?

Avoid penaltyKeep up with the market – competitor Always done this way Want to spend budget to keep it safe Bad PR via social mediaEt cetera

Whatever the reason, know the reason

© Jeffrey Davidson, 2011

Information Smells

1. Item on output, that are not on the model2. Item on model, that are not on the output3. Two pieces of information in one place 4. No relationship5. One to one relationship. Are they the same

thing?6. Many to many ( missing information )7. Undefined functions ( missing information )Chris Matts, to be published soon

© Jeffrey Davidson, 2011

It’s the same thing

Discussing the Information Smells• Not about do we need this data? • Conversation about what business

needs

Changes the dynamic

Transforms from push to pull

© Jeffrey Davidson, 2011

BDD: Recap

Start with a goal or User Story

Build scenarios

Automate the testing

Write the code

Have a Coca-Cola and smile

© Jeffrey Davidson, 2011

Feature Injection: Recap

Find the value

Model the output

Follow the Information Smells

Have another Coke!

© Jeffrey Davidson, 2011

Questions

If you waited until now to ask your questions, you missed the best chance for us to have a conversation.

But you should ask anyway…

© Jeffrey Davidson, 2011

Experts

Dan North @tastapod dannorth.net

Chris Matts @PapaChrisMatts theitriskmanager.wordpress.com

Liz Keogh @lunivore lunivore.com

Gojko Adzic @gojkoadzicgojko.net

© Jeffrey Davidson, 2011

Resources

http://www.lulu.com/product/ebook/real-options-at-agile-2009/17416200

This is a really cool comic. You should read

it.

Using Behavior Driven Development

and Feature Injection to Build Better Software

Jeffrey Davidson@JeffreyGoodReqgoodrequirements.com

BBCCon2011:bafNovember 3, 2011

Using Behavior Driven Development

and Feature Injection to Build Better Software

Jeffrey Davidson@JeffreyGoodReqgoodrequirements.com

BBCCon2011:bafNovember 3, 2011