Getting Started with Behavior Driven Development
What is BDD and its benefits? How does SpecFlow support it? These are the main questions this articles answers.
What is BDD and its benefits? How does SpecFlow support it? These are the main questions this articles answers.
Behavior Driven Development (BDD) is an agile software development practice – introduced by Dan North in 2006 – that encourages collaboration between everyone involved in developing software: developers, testers, and business representatives such as product owners or business analysts.
BDD aims to create a shared understanding of how an application should behave by discovering new features based on concrete examples. Key examples are then formalized with natural language following a Given/When/Then structure.
Gherkin is the most commonly used syntax for describing examples with Given/When/Then in plain text files, called feature files. Gherkin scenarios can be automated to validate the expected behavior. At this point, BDD tools – such as SpecFlow – come in handy. Automated acceptance tests, however, are an optional by-product of using BDD, not the sole purpose.
Automated Gherkin scenarios are “green” when up-to-date and in sync with system behavior. Whenever the updated system stops producing the expected behavior, the affected scenario turns red to alert the team. This failure can be caused by new behavior that contradicts with previous requirements or the updates introducing unwanted side-effects. In any case, the team must fix this mismatch to make all scenarios green again. When the team follows this practice, Gherkin documentation grows with the system, providing an always up-to-date specification of its behavior. This is also called “Living Documentation”, here you can view an example.
To summarize, Behavior Driven Development can be defined as follows:
BDD is an agile software engineering practice that supports feature discovery and encourages collaboration among developers, testers and business participants in a software development team. BDD is facilitated through examples expressed in natural-language constructs expressing the expected system behavior, and automation validating these examples as acceptance tests.
Behavior Driven Development (BDD) is an agile software development practice – introduced by Dan North in 2006 – that encourages collaboration between everyone involved in developing software: developers, testers, and business representatives such as product owners or business analysts.
BDD aims to create a shared understanding of how an application should behave by discovering new features based on concrete examples. Key examples are then formalized with natural language following a Given/When/Then structure.
Gherkin is the most commonly used syntax for describing examples with Given/When/Then in plain text files, called feature files. Gherkin scenarios can be automated to validate the expected behavior. At this point, BDD tools – such as SpecFlow – come in handy. Automated acceptance tests, however, are an optional by-product of using BDD, not the sole purpose.
Automated Gherkin scenarios are “green” when up-to-date and in sync with system behavior. Whenever the updated system stops producing the expected behavior, the affected scenario turns red to alert the team. This failure can be caused by new behavior that contradicts with previous requirements or the updates introducing unwanted side-effects. In any case, the team must fix this mismatch to make all scenarios green again. When the team follows this practice, Gherkin documentation grows with the system, providing an always up-to-date specification of its behavior. This is also called “Living Documentation”.
To summarize, Behavior Driven Development can be defined as follows:
BDD is an agile software engineering practice that supports feature discovery and encourages collaboration among developers, testers and business participants in a software development team. BDD is facilitated through examples expressed in natural-language constructs expressing the expected system behavior, and automation validating these examples as acceptance tests.
Learn more | By clicking subscribe you agree to our privacy policy.
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:
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.
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:
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.