Content tagged with: BDD
Elisabeth Hendricksson stated at Turku Agile Day 2010 that “Specs is an abbreviation for speculations”. She is right, specs are often speculations. How can this be avoided? Execution of code doesn’t leave any room for speculation. If the specs can be executed, they aren’t speculations anymore.
Acceptance tests and requirements are linked. You can’t have one without the other. The tests clarify and amplify the requirements. A test that fails shows that the system does not properly implement a requirement. A test that passes is a specification of how the system works.
Learn how software applications can be specified, continuously developed, tested and delivered and how testing supports the flow from requirements through to acceptable systems. In the Agile community, Acceptance-Test Driven Development (ATDD), Behaviour-Driven Development (BDD), Test-Driven Development (TDD) and Specification by Example are gaining greater acceptance as an effective approach to developing systems of high quality and business value.
The ideas behind Behavior-Driven Development (BDD), Specification by Example and Agile acceptance testing are deceivingly simple, but have proved far from easy to implement. Yet most of the complaints online come from misunderstood ideas which lead to misguided attempts. This talk busts the myths around these techniques and shows how successful teams all over the world use them to successfully deliver the right stuff using these techniques.
Feature injection is a business analysis approach that focuses on business value, an approach similar to Behavior Driven Development (BDD). It transfers knowledge to the team about how the project can deliver value and what are the features needed to deliver that value. Examples are used to transfer this information to the team in the form with the goal to eliminate the waste of separate requirements specifications and tests. Why is it call Feature Injection? Because “The process of pulling value from a project injects features into the system”.
Outside-in development doesn’t mean starting at the user interface, it means starting at the outside of whatever you want to discover. On a brand new application, the first thing you need to discover is your domain model. Those fancy ajax gizmos can wait. This video features both film footage and Matt’s demo’s and code. Starting from a single Cucumber scenario, Matt drives out a domain model, then like a BDD magician, he’ll slip in a user interface around the domain model *without touching the tests*.
Behavior Driven Development (BDD) is “Test–Driven Development (TDD) done right”, but in practice, it often ends up being TDD done with new tools and more verbose test names. The goal of writing executable specifications is the writing: learning what to specify, what to write about, what to leave out, and the right level of specificity.
Based on extensive research of behavior driven development and agile acceptance testing, this video presents stories that will inspire you to improve your software development process.
This tutorial shows how easy it is to get ready for the first automated specification in a .NET project and gives you a chance to learn SpecFlow quickly together with useful tips for practicing Behavior-Driven Development (BDD).
These two videos show the Behaviour Driven Development (BDD) cycle using Ruby, Cucumber and RSpec.