using behavior driven development and feature injection to build better software

Using Behavior Driven Development

and Feature Injection to Build Better Software

Jeffrey [email protected]

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?


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


– –Given

You & Your condition

What you do

What you see

Simple Structure

When

Then


Given – When – Then

You now know enough to succeed.

Go! Enjoy another session.


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


Not Today’s Agenda

Discuss BDD Tools Give automation advice Share code quality practices


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


What is BDD?

Fine grained, focused bits of behavior

Told in a story format

No, really, what is it?


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?



I dream of . . . adventure, challenge, success



Have you ever dreamed of . . . facts?

Yuck!


Stories

We use stories to communicate.


Do you mean User Stories?

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


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


Two Steps

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

Build Scenarios


– –Given

You & Your condition

What you do

What you see

Simple Structure

When

Then


Simple Structure

Given [CONTEXT]

When [EVENT OCCURS]

Then [OUTCOME]


Given

OLD?

NEWGiven I am . . .

<<Who & Where & What has already happened &

etc.>>

State your action in natural language


When

OLD?

NEWWhen I <<perform some action>>

State your action in natural language


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


Be Like Aldi

Generic behavior

Don’t include design.

Imagine performing the same actions on a telephone interface!


Simple Structure

Given [CONTEXT]

When [EVENT OCCURS]

Then [OUTCOME]


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


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.


Why?


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


Built right or Right product?

Gojko Adzic in Specification by Example, 2011


Benefits

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



Benefits


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



Benefits


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



Benefits


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



Benefits


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



Who Benefits?

Everyone!

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


Blah, Blah, Blah – Why should I care?

Ferries & Bridges


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.


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


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?”


Is it like testing?

Sort of…

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


Testing Tools

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

There are lots of tools to use


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


Downsides

May not help velocity

New

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


Wait a minute!

What happened to Feature Injection?


Build Software That Matters

Start with a business goal

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


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


Value is what matters

If you want to add value . . .

. . . don’t argue about features

. . . ask about why


Think like an investor

Every project is an investment.

Picture a Business Investor

Why does your Business Investor want to do this project?


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


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


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


BDD: Recap

Start with a goal or User Story

Build scenarios

Automate the testing

Write the code

Have a Coca-Cola and smile


Feature Injection: Recap

Find the value

Model the output

Follow the Information Smells

Have another Coke!


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…


Experts

Dan North @tastapod dannorth.net

Chris Matts @PapaChrisMatts theitriskmanager.wordpress.com

Liz Keogh @lunivore lunivore.com

Gojko Adzic @gojkoadzicgojko.net


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 [email protected]

BBCCon2011:bafNovember 3, 2011

using behavior driven development and feature injection to build better software

Documents

bdd jeffrey davidson

outcome jeffrey davidson

success jeffrey davidson

human jeffrey davidson

stories story formathave

bdd fundamentalsi

statementsuser stories

stories story formati