Behavior-driven development

Behavior-driven development

In software engineering, behavior-driven development (BDD) is an Agile software development process that encourages collaboration among developers, QA and non-technical or business participants in a software project.^[1][2][3] It encourages teams to use conversation and concrete examples to formalize a shared understanding of how the application should behave.^[4] It emerged from test-driven development (TDD).^{[1][2][5][6][vague][7]} Behavior-driven development combines the general techniques and principles of TDD with ideas from domain-driven design and object-oriented analysis and design to provide software development and management teams with shared tools and a shared process to collaborate on software development.^[2][7]

Although BDD is principally an idea about how software development should be managed by both business interests and technical insight, the practice of BDD does assume the use of specialized software tools to support the development process.^[5] Although these tools are often developed specifically for use in BDD projects, they can be seen as specialized forms of the tooling that supports test-driven development. The tools serve to add automation to the ubiquitous language that is a central theme of BDD.

BDD is largely facilitated through the use of a simple domain-specific language (DSL) using natural-language constructs (e.g., English-like sentences) that can express the behaviour and the expected outcomes. Test scripts have long been a popular application of DSLs with varying degrees of sophistication. BDD is considered an effective technical practice especially when the "problem space" of the business problem to solve is complex.^[8]

 

BDD Glossary

As you get started with BDD, you will find that it uses some very specialized lingo. Don’t let this deter you – it’s all pretty simple once you learn a few key terms.

We have compiled a list of the most common BDD terms you may come across, their definitions, and examples. This glossary is designed to complement the Getting Started with BDD guide, which provides a deeper dive into the core principles underlying BDD. Our ultimate goal is to provide a one-stop-shop for mastering the basics so you can experience the many benefits of BDD as rapidly as possible.

If you have questions about the existing definitions or ideas for new terms to include, please let us know via Twitter.

Acceptance Test Driven Development

Automated Acceptance Tests

Automation

Discovery

Domain-Specific Languages

Feature and Feature Files

Formulation

Gherkin

Given-When-Then

Living documentation

Test Driven Development – TDD

Three Amigos

Scenario

SpecFlow

 

What is BDD?

 

Why BDD?

BDD describes application behavior from a user’s point of view. Overall, the main goal of BDD is to improve the collaboration between all stakeholders involved in developing software and form a shared understanding among them.

So, why use BDD?

Here are some of the top advantages that teams practicing BDD experience:

• Reduced Rework / Shared Understanding: Concrete examples of expected system behavior foster a shared understanding by being specific enough for developers and testers while still making sense to business participants. Think of a BDD scenario like a bug report that is written in natural-language and posted before the system has been implemented. It describes the steps to reproduce (Given/When) and expected outcome (Then) without the symptoms (unwanted behavior) that usually triggered the bug report.
• Faster Feedback: Example scenarios describe focused, granular changes to the system under development. This enables teams to evolve the system in small steps while keeping it potentially shippable, allowing for shorter release cycles and faster feedback.
• Effectiveness: Since you extend the system in small increments, you can validate business value earlier and avoid unnecessary features. This prevents gold-plating and makes the overall implementation of the system more effective.
• Lower Cost: Driving automated acceptance tests through test-first BDD scenarios is much cheaper than post-automating acceptance tests. Teams practicing ATDD (Acceptance Test Driven Development) use their shared understanding to develop the feature and the test automation, while teams separating development and test automation need to interpret and fine-tune scenarios multiple times. This causes extra effort and can lead to misaligned interpretations. Additionally, test automation based on scenarios that were used to drive the implementation have a better focus and more relevant assertions. This leads to higher test automation coverage and more relevant test automation scenarios, which reduces regression errors and efforts for manual checks.
• Single Source of Truth: Specification through examples that is guarded with automated acceptance tests is an always-up-to-date description of the current system behavior (“Living Documentation”). This provides a single source of truth for the team, business stakeholders and important external parties like regulatory authorities or partners relying on the system specification. Here you can view an example.
• User Satisfaction: By focusing on the needs of the business, you get satisfied users — which translates to customer loyalty and better business outcomes. The higher degree of test automation frees more time for manual exploratory testing and yields less errors in production, especially when shipping new versions at a high cadence. More frequent, high quality releases enable rapid response to evolving user needs and dynamic market pressuress.
• Code Quality: Using Acceptance Test Driven Development has a positive impact on code quality: it promotes emergent design that ensures loosely-coupled, highly-cohesive architecture and avoids over-engineering and technical debt. This ensures that a system stays testable and maintainable– and that it can be quickly changed to support new requirements without sacrificing stability.

Many teams using Behavior Driven Development turn these concrete examples/specifications into automated acceptance tests. At this point, BDD tools and testing frameworks – such as SpecFlow – come into play.

 

 

 

 

 

作者:Chuck Lu    GitHub