Using Behavior Driven Development and Feature Injection to Build Better Software

1. Jeffrey Davidson @JeffreyGoodReq goodrequirements.com BBCCon2011:baf November 3, 2011 Using Behavior Driven Development and Feature Injection to Build Better Software

2. 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?

3. 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

4. Simple Structure What you see You & Your condition Given – – When Then What you do

5. Given – When – Then You now know enough to succeed. Go! Enjoy another session.

6. 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

7. Not Today’s Agenda • Discuss BDD Tools • Give automation advice • Share code quality practices

8. 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

9. What is BDD? • Fine grained, focused bits of behavior • Told in a story format No, really, what is it?

10. 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?

11. Stories & Story Format • I dream of . . . adventure, challenge, success

12. Stories & Story Format • Have you ever dreamed of . . . facts? Yuck!

13. Stories • We use stories to communicate.

14. Do you mean User Stories? • “As a . . . , I want . . . , So . . . .”

15. 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

16. Two Steps • Start with business goals • In Agile development, this is a User Statement Story • Build Scenarios

17. Simple Structure What you see You & Your condition Given – – When Then What you do

18. Simple Structure • Given [CONTEXT] • When [EVENT OCCURS] • Then [OUTCOME]

19. Given NEW • Given I am . . . <<Who & Where & What has already happened & etc.>> OLD • ? State your action in natural language

20. When NEW • When I <<perform some action>> OLD • ? State your action in natural language

21. 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

22. Be Like Aldi • Generic behavior • Don’t include design. Imagine performing the same actionson a telephone interface!

23. Simple Structure • Given [CONTEXT] • When [EVENT OCCURS] • Then [OUTCOME]

24. 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

25. 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.

26. Why?

27. 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

28. Built right or Right product? GojkoAdzic in Specification by Example, 2011

29. Benefits To build the right product effectively, software dev practices need: GojkoAdzic in Specification by Example, 2011

30. 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

31. 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

32. 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

33. 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

34. Who Benefits? • Everyone! • Seriously, it helps everyone. • Business • Users • Testers • Developers • Analysts

35. Blah, Blah, Blah – Why should I care? • Ferries & Bridges

36. 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.

37. 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

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

39. Is it like testing? • Sort of… • Specifications are written in such a precise way we can execute them

40. Testing Tools There are lots of tools to use • JBehave(java) • RSpec, Cucumber (ruby) • Lettuce (python) • Nbehave & Nspec (.NET) • FIT & FitNess (multiple) • Etc.

41. 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

42. Downsides • May not help velocity • New • Tools (and all that jazz) may cause clutter, slow-down, new learning, other stuff

43. Wait a minute! • What happened to Feature Injection?

44. Build Software That Matters • Start with a business goal Hint: Businesses want to increase, conserve, or protect $.

45. 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

46. Value is what matters • If you want to add value . . . • . . . don’t argue about features • . . . ask about why

47. Think like an investor • Every project is an investment. • Picture a Business Investor • Why does your Business Investor want to do this project?

48. 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

49. 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

50. 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