This document discusses Behavior-Driven Development (BDD) and how it can help deliver valuable software quickly by focusing on business value and user behavior through techniques like ubiquitous language, living documentation, and specifying examples. It provides tips for implementing BDD, including defining requirements and acceptance criteria, writing scenarios, test automation approaches, and ensuring business involvement. The document emphasizes that BDD is not restricted to any one layer or framework, and can be applied to both user interfaces and APIs.
2. “The most important problem that we face as software
professionals is this: If somebody thinks of a good idea,
how do we deliver it to users as quickly as possible?”
- “Continuous Delivery” book
3. ➜ Ubiquitous Language
➜ Focus on business value
➜ Living Documentation
➜ Specifying By Example
How does BDD come to the picture?
4. ➜ Because we have to deliver
‘software that matters’ – Agile
Manifesto
Why do we need to focus on software
behaviour
14. Definition of Ready & Definition of Done
- Definition of Ready
- Definition of Done
- 2 parallel boards
15. Acceptance Criteria & Example Mapping
- Acceptance Criteria – how are they related to
Scenarios?
- Example Mapping
- How about Non Functional Requirements/Criteria?
- Automation is not always the outcome of a
Specification session
- Team Rotation?
16. Roles
- Do we need Developers in Test?
- We are all developers
- Testers you are still needed!!!
17. • What happens when business are
not as involved into your processes?
• Product Owner/Business Analysts
are a catalyst to the BDD process
• Unit & Integration Tests, then
Acceptance
Business Involvement + Test-First Maturity
19. - BDD describes behaviour
- BDD doesn’t need UI
- BDD doesn’t restrict on one layer of your
system
- You can do BDD with xUnit frameworks
- Unit + Service tests with Test Doubles
- Drive majority of tests from API
- How about SPAs?
I’m a full-stack developer, can I do BDD?
20. “Given, Given, And, Then, When, Then…”
How about Fluent APIs then?
What if Gherkin language gets in the way?
21. MISSION PATTERN
A pattern for Fluent
APIs:
http://magentys.io/blogs
Place your screenshot here
https://dzone.com/articles/mission-pattern-a-means-to-modularise-automation-c
23. Thanks!
You can find me at:
@mamalisk
http://kostasmamalis.com
http://magentys.io/blogs/
Editor's Notes
By Jez Humble and David Farley
At the end of the day we want to deliver exactly what the customer needs. I can bring you water that can quench your thirst, but delivering the water this poor man needs to face the calamity which stroke upon him… well that’s a different matter altogether. How can we avoid these sort of misunderstandings, how can we bridge the communication gap. The prevailing answer that BDD actually advocates is:
At the end of the day we want to deliver exactly what the customer needs. I can bring you water that can quench your thirst, but delivering the water this poor man needs to face the calamity which stroke upon him… well that’s a different matter altogether. How can we avoid these sort of misunderstandings, how can we bridge the communication gap. The prevailing answer that BDD actually advocates is: