570 likes | 750 Views
Jeffrey Davidson @ JeffreyGoodReq goodrequirements.com BBCCon2011:baf November 3, 2011. Using Behavior Driven Development and Feature Injection to Build Better Software. BDD Fundamentals. I can teach you this in less than 1 minute . . . Are you ready?
E N D
Jeffrey Davidson @JeffreyGoodReq goodrequirements.com BBCCon2011:baf November 3, 2011 Using Behavior Driven Development and Feature Injection to Build Better Software
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 is • And what you do • And how the system responds
Simple Structure What you see You & Your condition Given – – When Then What you do
Given – When – Then You now know enough to succeed. Go! Enjoy another session.
Today’s Agenda… • Fundamentals of BDD • Formal definition • What is BDD? • How to use BDD • Why being less specific is important • Benefits • Why you should care • Why BDD isn’t testing • More Fundamentals (Feature Injection) • How to use Feature Injection • How 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?
Stories & Story Format • I dream of . . . adventure, challenge, success
Stories & Story Format • 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 goals • In Agile development, this is a User Statement Story • Build Scenarios
Simple Structure What you see You & Your condition Given – – When Then What you do
Simple Structure • Given [CONTEXT] • When [EVENT OCCURS] • Then [OUTCOME]
Given NEW • Given I am . . . <<Who & Where & What has already happened & etc.>> OLD • ? State your action in natural language
When NEW • When I <<perform some action>> OLD • ? State your action in natural language
Then NEW • Then I see … OLD • The system shall … State your action in natural language – OR – WRITE LIKE A HUMAN This is how you observe the system’s response
Be Like Aldi • Generic behavior • Don’t include design. Imagine performing the same actionson 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 money • When the account holder requests 20 • Then 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.
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? GojkoAdzic in Specification by Example, 2011
Benefits To build the right product effectively, software dev practices need: GojkoAdzic in Specification by Example, 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. GojkoAdzic in Specification by Example, 2011
Benefits To build the right product effectively, software devpractices need: • Precise specifications so delivery teams avoid wasteful rework caused by ambiguities and functional gaps. GojkoAdzic in Specification by Example, 2011
Benefits To build the right product effectively, software dev practices need: • An objective means to measure when a piece of work is complete. GojkoAdzic in Specification by Example, 2011
Benefits To build the right product effectively, software dev practices need: • Documentation to facilitate change, in terms of both software features & team structure. GojkoAdzic in Specification by Example, 2011
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 There are lots of tools to use • JBehave(java) • RSpec, Cucumber (ruby) • Lettuce (python) • Nbehave & Nspec (.NET) • FIT & FitNess (multiple) • Etc.
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 penalty • Keep up with the market – competitor • Always done this way • Want to spend budget to keep it safe • Bad PR via social media • Et cetera Whatever the reason, know the reason
Information Smells • Item on output, that are not on the model • Item on model, that are not on the output • Two pieces of information in one place • No relationship • One to one relationship. Are they the same thing? • Many to many ( missing information ) • 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