Bdd Introduction
21 likes10,087 views
1) Behaviour-driven development (BDD) is an agile methodology that focuses on delivering working, tested software through collaboration between developers, testers and stakeholders. 2) BDD implements an application by describing its behavior through features and scenarios written from the perspective of stakeholders. Stories, acceptance criteria, executable examples and other tools are used to define requirements and guide development. 3) BDD aims to produce software that provides tangible value to stakeholders by being delivered incrementally, being easy to deploy and manage, and by adapting quickly to feedback through frequent testing and deployment.
Bdd Introduction
- 1. Behaviour-Driven Development Writing software that matters Dan North, ThoughtWorks Liz Keogh, Lunivore
- 2. Part 1: Software that doesn’t matter 2 © Dan North, ThoughtWorks
- 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. How we deliver software Planning Analysis Design Deploy Code Test t Why do we do this? 4 © Dan North, ThoughtWorks
- 5. The exponential change curve $ Planning Analysis Design Deploy Code Test t 5 © Dan North, ThoughtWorks
- 6. The exponential change curve $ We fear this... so we do t which this... reinforces this! 6 © Dan North, ThoughtWorks
- 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. 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. Part 2: Software that matters 9 © Dan North, ThoughtWorks
- 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. 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. ...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. ...cycle of interactions... BDD in six pictures 13 © Dan North, ThoughtWorks
- 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. ...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. ...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. ...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. ...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. ...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. ...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. ...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. ...clearly-defined outputs... Code-by-example example Scenario Examples Scenario 22 © Dan North, ThoughtWorks
- 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. ...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. Part 3: Getting the words right 25 © Dan North, ThoughtWorks
- 26. 26 © Dan North, ThoughtWorks
- 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. 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. 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. 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. 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. Conclusion 32 © Dan North, ThoughtWorks
- 33. Software that matters ...has tangible stakeholder value ...is delivered on time, incrementally ...is easy to deploy and manage ...is robust in production ...is easy to understand and communicate BDD is a step in that direction 33 © Dan North, ThoughtWorks
- 34. Thank you Any questions? dan.north@thoughtworks.com http://dannorth.net @tastapod liz@lunivore.com http://lizkeogh.com @lunivore Google Group: BehaviorDrivenDevelopment 34 © Dan North, ThoughtWorks
- 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