Behavior Driven Development - TDD and DDD rolled into one

To be honest, I like to think that I’m pretty good at keeping up with the cutting edge of what developers are doing to improve their effectiveness, I’m pretty well versed in agile software delivery approaches like domain driven design, test driven development, agile modeling. I also am pretty well-versed in and have real experience in things like SOA, AOP, Web 2.0 , REST, patterns of all kind...

and then every once in a while I become completely humbled by learning that I have been totally ignorant of some fantastic new innovation within the development team.

This time that innovation is behavior driven development, a fusion of test driven development , agile user stories, and domain driven design.

What behavior driven development allows you to do is take a set of user stories and supporting acceptance tests written in natural language and turn them into explicit, testable requirements that become part of your automated testing and build routine.

For example:

take the following user story

As a customer
  I want to update my customer profile
  So that my personal data is always accurate
 
  Scenario 1: customer enters invalid birthday (must be 18 years or older) 
  given that the customer enters a birthday
  and that the customers age is calculated to be less than 18 years 
  When the test is run
  the following error message should be displayed "customers must be 18 years or older to be valid members of this website!"

  Scenario 2: etc.

Using a behavior driven specification framework like Story Test, one develops acceptance tests (either automatically using a tool or manually)
like the following
  namespace StoryQ.Tests.Documentation
  {
    [TestFixture]
    public class CustomerSpecification
    {
 
        [Test]
        public void ValidCustomerBirthdayScenario()
        {
            Story story = new Story(" writing executable specification for customer birthday");
 
            story.AsA("customer")
                .IWant(" update my consumer profile")
                .SoThat(" my personal data is always accurate")
 
                .WithScenario("invalid birthday scenario")
                    .Given(" the customer enters a birthday")
                    .Add ("any age is calculated to be less than 18 years")                  
                    .Then(" display error message saying that the customer must be 18 years or older to be a valid member of this website")
 
                .WithScenario("Writing specifications again")
                    .Given("That i have written everything in text")
                        .And("still have no asserts")
                        .And("and have another condition")
                    .When("the test is run")
                        .And("I am happy")
                    .Then("the test result should be pending")
                       .And("here’s just some more and’s");
 
            story.Assert();
        }
 
    }
  }
These user story specifications leverage the concept of a ubiquitous language from domain driven design, and are built just like regular user stories leveraging concepts such as value driven questions , and responsibility driven design.
IMHO, this is brilliant stuff and really ties together the concept of testable requirements and executable specifications.
 
This kind of innovation that comes from the open source world is also why, IMHO big vendors finding it increasingly difficult to match the pace of free products.
aa
 

..