Behavior Driven Development creates a shared understanding of how an application should behave by discovering missing requirements based on concrete examples. This is how bugs & misunderstandings are prevented.
Concrete examples of expected system behavior foster a shared understanding by being detailed enough for developers and testers while still making sense to business participants.
Discovery refers to a structured, collaborative practice for specifying software requirements with examples. The process of Discovery is also known as a “Specification By Example workshop.” Discovery aims to overcome the blind spots of the “unknown-unknowns” in software development and reduce the learning bottleneck.
Focus on writing tests in natural language instead of building complex testing-code
Formulation is the practice of turning key examples from Discovery into formalized documentation, such as the easy to read Gherkin scenarios.
Automation is where formalized scenarios are turned into automated acceptance tests. Automated acceptance tests significantly reduce efforts for regression testing and provide immediate feedback when the specification documentation doesn’t match the system behavior anymore.
SpecFlow turns Gherkin scenarios into automated tests and helps teams bind automation to feature files and easily share the resulting examples.
Spend more time on coding feature-logic rather than debugging and explaining code.
Allows for continued collaboration and increased visibility among the entire team.
By focusing on the needs of the business, you get satisfied users — which translates to customer loyalty and better business outcomes.
Involving testers from the beginning means fewer bugs later.
Since you extend the system in small increments, you can validate business values earlier and avoid unnecessary features. This prevents gold-plating and makes the overall implementation of the system more effective.
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.
BDD has a positive impact on code quality: it promotes emergent design that ensures loosely-coupled, highly cohesive architecture and avoids over-engineering.
As with any new methodology or practice that is introduced to new teams, there is a learning curve that requires the entire team to put time and effort into learning a new practice. Adopting a new practice may be a big challenge for some teams.
Creating and maintaining the feature files and scenarios requires an overhead investment of time and effort. In small projects, it may not be worth it, but in projects that have many iterations, you’ll definitely see a return on that investment.