A lot of focus on Agile is around SCRUM, but thought worthwhile to cover other Agile methodologies. BDD (Behavior Driven Development) is a second-generation, outside-in, pull-based, multiple-stakeholder, multiple-scale, high-automation, agile methodology. It describes a cycle of interactions with well-defined outputs, resulting in the delivery of working, tested software that matters. As name suggests it is related to another methodology Agile TTD (Test Driven Development)
It extends TDD by writing test cases in a natural language that non-programmers can read. Behavior-driven developers use their native language in combination with the ubiquitous language of domain driven design to describe the purpose and benefit of their code. This allows the developers to focus on why the code should be created, rather than the technical details, and minimizes translation between the technical language in which the code is written and the domain language spoken by the business, users, stakeholders, project management, etc.
The User stories are broken down into 1 or more scenarios; for example:-
User Story:As a Scrum Master I want to see Lead/Cycle time progress
As a Scrum Master
I want to see Lead/Cycle time progress
So that I know whether we are improving our development process or not
Scenario #1
Given Reports section in project and Bug Tracking practice is disabled
When I navigate to Lead and Cycle Time Report
Then I see Lead Time chart
And chart contains 1 line for stories
These scenarios become the basis for start of coding. Depending on tool you are using, pseudo code can be generated from scenario. Click here to see example output, created using SpecFlow, a Visual Studio BDD addon. It looks verbose, but for good reason – steering the developer the right way. This isn’t partonising, its what developers want – a clear remit of work required! This all sounds simple – because it is. The advantage of this methodology is it’s focus on the user stories and scenarios, and the way the process funnels these down through to development. As with all processes, there is an increase in intial adminsitration, but it does reduce overall bugs – cheifly because of the adherence to specifications (a lot of issues raised on projects are directly or indrectly requirements-related).
#region Designer generated code
namespace TestProject5
{
using TechTalk.SpecFlow;
[System.CodeDom.Compiler.GeneratedCodeAttribute("TechTalk.SpecFlow", "1.6.1.0")]
[System.Runtime.CompilerServices.CompilerGeneratedAttribute()]
[NUnit.Framework.TestFixtureAttribute()]
[NUnit.Framework.DescriptionAttribute("As a Scrum Master I want to see Lead/Cycle time progress")]
public partial class AsAScrumMasterIWantToSeeLeadCycleTimeProgressFeature
{
private static TechTalk.SpecFlow.ITestRunner testRunner;
#line 1 "SpecFlowFeature3.feature"
#line hidden
[NUnit.Framework.TestFixtureSetUpAttribute()]
public virtual void FeatureSetup()
{
testRunner = TechTalk.SpecFlow.TestRunnerManager.GetTestRunner();
TechTalk.SpecFlow.FeatureInfo featureInfo = new TechTalk.SpecFlow.FeatureInfo(new System.Globalization.CultureInfo("en-US"), "As a Scrum Master I want to see Lead/Cycle time progress", "As a Scrum MasterrnI want to see Lead/Cycle time progressrnSo that I know whether" +
" we are improving our development process or not", GenerationTargetLanguage.CSharp, ((string[])(null)));
testRunner.OnFeatureStart(featureInfo);
}
[NUnit.Framework.TestFixtureTearDownAttribute()]
public virtual void FeatureTearDown()
{
testRunner.OnFeatureEnd();
testRunner = null;
}
public virtual void ScenarioSetup(TechTalk.SpecFlow.ScenarioInfo scenarioInfo)
{
testRunner.OnScenarioStart(scenarioInfo);
}
[NUnit.Framework.TearDownAttribute()]
public virtual void ScenarioTearDown()
{
testRunner.OnScenarioEnd();
}
[NUnit.Framework.TestAttribute()]
[NUnit.Framework.DescriptionAttribute("Lifecyle progress")]
[NUnit.Framework.CategoryAttribute("CycleProgress")]
public virtual void LifecyleProgress()
{
TechTalk.SpecFlow.ScenarioInfo scenarioInfo = new TechTalk.SpecFlow.ScenarioInfo("Lifecyle progress", new string[] {
"CycleProgress"});
#line 7
this.ScenarioSetup(scenarioInfo);
#line 8
testRunner.Given("Reports section in project and Bug Tracking practice is disabled");
#line 9
testRunner.When("I navigate to Lead and Cycle Time Report");
#line 10
testRunner.Then("I see Lead Time chart");
#line 11
testRunner.And("chart contains 1 line for stories");
#line hidden
testRunner.CollectScenarioErrors();
}
}
}
#endregion
Related posts:
