Bdd Introduction


Published on

Bdd Introduction

Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Bdd Introduction

  1. 1. Behaviour-Driven Development Writing software that matters Dan North, ThoughtWorks Liz Keogh, Lunivore
  2. 2. Part 1: Software that doesn’t matter 2 © Dan North, ThoughtWorks
  3. 3. Failure modes – a field guide The project comes in late ...or costs too much to finish The application does the wrong thing It is unstable in production It breaks the rules The code is impossible to work with 3 © Dan North, ThoughtWorks
  4. 4. How we deliver software Planning Analysis Design Deploy Code Test t Why do we do this? 4 © Dan North, ThoughtWorks
  5. 5. The exponential change curve $ Planning Analysis Design Deploy Code Test t 5 © Dan North, ThoughtWorks
  6. 6. The exponential change curve $ We fear this... so we do t which this... reinforces this! 6 © Dan North, ThoughtWorks
  7. 7. If only we could deliver better... Deliver features rather than modules Prioritise often, change often Only focus on high-value features Flatten the cost of change Adapt to feedback Learn! 7 © Dan North, ThoughtWorks
  8. 8. What we would need Adaptive planning Streaming requirements Evolving design Code we can change Frequent code integration Run all the regression tests often Frequent deployments 8 © Dan North, ThoughtWorks
  9. 9. Part 2: Software that matters 9 © Dan North, ThoughtWorks
  10. 10. A loose definition of BDD “Behaviour-driven development is about implementing an application by describing its behaviour from the perspective of its stakeholders” - Me  10 © Dan North, ThoughtWorks
  11. 11. A more formal definition of 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.” 11 © Dan North, ThoughtWorks
  12. 12. ...second generation... BDD is derivative Derives from: XP, especially TDD and CI Acceptance Test-Driven Planning Lean principles Domain-Driven Design Influenced by: Neurolinguistic Programming (NLP) Systems Thinking 12 © Dan North, ThoughtWorks
  13. 13. ...cycle of interactions... BDD in six pictures 13 © Dan North, ThoughtWorks
  14. 14. ...cycle of interactions... The roles in a BDD team The stakeholders The analysts (or BAs) The testers (or QAs) The developers The project manager (or Boss) 14 © Dan North, ThoughtWorks
  15. 15. ...outside-in... Who is this application for? Vision (or Purpose) Outcome Outcome Outcome Feature set Feature set Feature set Feature set Features... Features... Features... ... Stories... Stories... ... Scenarios... ... 15 © Dan North, ThoughtWorks
  16. 16. ...clearly-defined outputs... What’s in a story? A story is a unit of delivery Story 28 - View patient details As an Anaesthetist I want to view the Patient’s surgical history So that I can choose the most suitable gas 16 © Dan North, ThoughtWorks
  17. 17. ...clearly-defined outputs... Focus on the value Story 28 - View patient details In order to choose the most suitable gas an Anaesthetist wants to view the Patient’s surgical history 17 © Dan North, ThoughtWorks
  18. 18. ...clearly-defined outputs... Focus on the value Story 29 – Log patient details In order to choose the most suitable gas an Anaesthetist wants other Anaesthetists to log the Patient’s surgical history for later retrieval 18 © Dan North, ThoughtWorks
  19. 19. ...clearly-defined outputs... Agree on “done” Define scope using scenarios Scenario – existing patient with history Given we have a patient on file And the patient has had previous surgery When I request the Patient’s surgical history Then I see all the previous treatments 19 © Dan North, ThoughtWorks
  20. 20. ...clearly-defined outputs... Automate the scenarios Make each step executable Given we have a patient on file In Ruby: Given “we have a patient on file” do # ... end In Java: @Given(“we have a patient on file”) public void createPatientOnFile() { // ... } 20 © Dan North, ThoughtWorks
  21. 21. ...clearly-defined outputs... Code-by-example to implement Also known as TDD Start at the edges, with what you know Implement outermost objects and operations Discover collaborators, working inwards and mock them out for now Repeat until “Done” If the model doesn’t “feel” right, experiment! 21 © Dan North, ThoughtWorks
  22. 22. ...clearly-defined outputs... Code-by-example example Scenario Examples Scenario 22 © Dan North, ThoughtWorks
  23. 23. ...clearly-defined outputs... Good tools can help here Cucumber or JBehave for stories RSpec, XUnit for code examples Mockito, Mocha, Moq for mocking Be opinionated rather than dogmatic with the tooling! 23 © Dan North, ThoughtWorks
  24. 24. ...clearly-defined outputs... We keep the development artifacts Examples become code tests …and documentation Scenarios become acceptance tests which become regression tests ...and documentation Automation is key 24 © Dan North, ThoughtWorks
  25. 25. Part 3: Getting the words right 25 © Dan North, ThoughtWorks
  26. 26. 26 © Dan North, ThoughtWorks
  27. 27. Domain-driven design 101 Model your domain ...and identify the core domain Create a shared language ...and make it ubiquitous Determine the model’s bounded context ...and think about what happens at the edges 27 © Dan North, ThoughtWorks
  28. 28. The map is not the territory There are many kinds of model Each is useful in different contexts There is no “perfect” domain model So don’t try to create one! Domain modelling takes practice 28 © Dan North, ThoughtWorks
  29. 29. A legacy domain modelling example Map<int, Map<int, int>> portfolioIdsByTraderId; if (portfolioIdsByTraderId.get(trader.getId()) .containsKey(portfolio.getId())) {...} becomes: if (trader.canView(portfolio)) {...} 29 © Dan North, ThoughtWorks
  30. 30. We often manage multiple domains You want to retrieve patient records in Java, using Hibernate so you define class HibernatePatientRecordRepository { What if your IDE did domain-specific fonts? 30 © Dan North, ThoughtWorks
  31. 31. Writing effective stories Each story represents (part of) a feature and each feature belongs to a stakeholder Each stakeholder represents a domain even the incidental stakeholders Mixing domains within a scenario leads to brittle tests What exactly is the scenario verifying? What does it mean when things change? “What does the stakeholder want from this story?” 31 © Dan North, ThoughtWorks
  32. 32. Conclusion 32 © Dan North, ThoughtWorks
  33. 33. Software that matters ...has tangible stakeholder value delivered on time, incrementally easy to deploy and manage robust in production easy to understand and communicate BDD is a step in that direction 33 © Dan North, ThoughtWorks
  34. 34. Thank you Any questions? @tastapod @lunivore Google Group: BehaviorDrivenDevelopment 34 © Dan North, ThoughtWorks
  35. 35. Bibliography Extreme Programming explained (2nd edition) - Kent Beck Domain-Driven Design - Eric Evans The Art of Systems Thinking and The Way of NLP - Joseph O’Connor 35 © Dan North, ThoughtWorks