Behaviour Driven Development/Design - BDD
https://dannorth.net/introducing-bdd/
BDD is an outside-in style and approach to TDD.
BDD is not just about coding acceptance-style tests. First and foremost it requires stakeholders, QA, and developers to work together in order to define requirements (often in the form of very small stories).
Stories along with their scenarios (if any) ensure that developers test drive the implementation based on the behavior that was asked for, and helps developers determine when they are truly done implementing a specific story (set of behaviors).
In BDD, tests are mainly based on systems behavior
In most cases, the Given-When-Then approach is used for writing test cases
the behavior is illustrated in a very simple English language, also known as a shared language. This helps everyone in the team responsible for development to understand the feature behavior.
Typical flow
Describe behaviour
Write tests
run and fail
write code to pass test
Run and pass test
repeat
At its core, BDD is about having conversations to help teams overcome misinterpreted requirements and delivery issues
it’s about promoting a shared understanding between team members as early as possible in a user stories lifecycle.
BDD leverages the ATDD along with other techniques around conversations, collaboration and automation to ensure that a team delivers what the business wants this first time around.
Benefits
Helps reach a wider audience by the usage of non-technical language
Allowing the requirements to be defined in a standard approach using simple English
Focuses on how the system should behave from the customer’s and the developer’s perspective
BDD Is a cost-effective technique
Reduces efforts needed to verify any post-deployment defects
Providing several ways to illustrate real-world scenarios for understanding requirements
Providing a platform that enables the tech and non-tech teams to collaborate and understand the requirements
How
Test names (methods) should be written in English sentences
language is in the form of documentation
when adopting BDD it’s important to focus on solving the problems of delivering the right thing and not on the automation technique
Once the collaborative sessions are flowing a team may choose to capture examples from those conversations using the Gherkin syntax
and then use the captured examples with automated tools to help guide what developers deliver, in what is known as outside in development.
https://lizkeogh.com/behaviour-driven-development/
https://medium.com/ft-product-technology/behaviour-driven-development-at-the-ft-46dc2991471d
Issues
Just as with ATDD, in gerneal it is not the devs who write the tests, but th testers/BAs who do it
This can lead to issues as described in [/libraries/yatspec.md]
You lose the ability to think of the design when the test and prod code are separated
test code written, can become a nightmare to work with after a while
Long feedback cycles, to add code to parse user tests, and to go from test to code
Last updated
Was this helpful?