Geeks With Blogs
Pounding Code technological rantings and code samples

I've been trying to push the client where I work into a more test driven approach, but when you're dealing with state agencies, if you want to get people nervous, just say the word "Change". They want 'impovements', just not 'change'.  In many respects, they're not unlike the person who wants to lose weight, but not change their eating habits. Now that I'm moving on to greener pastures, I can again resume my deep dive into NSpec, NBehave and the rest, however since I've also been digging into templating tools, my perspective is that it's possible to populate a template that will write out the human readable specifcations and stub out the tests. (more on this later)0.

I have begun analyzing different BDD tools and approaches and while some might consider what makes sense for them to be the ONLY WAY IT SHOULD BE DONE. I've got a more pragmatit approach to the whole arguement. If you can pick an approach that is saving you time, improve communication with the stakeholders, streamline the development process and above all eliminate redundancy, you've got the right tool.

I had been excited by the notion of an executable specification: that is a document which could be easily consumed by developers and managers and stakeholders alike. The holy grail of an automated executable specification may be unatainable and even unadvisable for a two of reasons. The first being that it may unduly constrain an agile process - the design process gets driven in multiple directions (from the client who has evolving needs, from the PM who has deadlines and resource constraints and from the dev who needs to deliver and knows quite well that the map is not the territory).

My instincts tell me that while it is probably easier to create the prose from the BDD tool vs parsing out praragraphs using regular expressions, a third way would be to build out a lightweight tool which could be used in a meeting where the variables were either injected into an input form with a backing database and then the preliminary prose and code templates get generated. This tool might help assure that the requirements are traceable.

An example of BDD with StoryQ
Story is Data Safety
In order to keep my data safe as a user, I want all credit card numbers to be encrypted within the scenario of submitting shopping cart. Given I have typed my credit card number into the checkout page, when I click the 'Buy' button, and the browser posts my credit card number over the Internet, then the form should be posted over https.
 

Which maps to
Story is Data Safety
In order to Keep my data safe
As a User
I want All credit card numbers to be encrypted
With scenario of submitting shopping cart
Given I have typed my credit card number into the checkout page
When I click the 'Buy' button
And the browser posts my credit card number over the Internet
Then the form should be posted over https
 

When we examine this in a more structured form, we discover our variables: story, justification, role, modtivation, etc:
Story is <story>
In order to <justification>
As a <role>
I want <motivation>
With <scenario>
Given <context>
When <invoking action, "qualifier">
And <reaction>
Then <assertion clause , result>
(assertion clause) <noun, adverb, verb>

Which can easily injected back into prose or code:

As prose
In order to <justification> as a <role>, I want <motivation> within the <scenario>. Given <context>, when <invoking action, "qualifier">, and <reaction>, then <assertion clause , result>.
 

As StoryQ:
new Story("<story>").Tag("sprint 1")
        .InOrderTo("<justification>")
         .AsA("<role>")
        .IWant("<motivation>")
        .WithScenario("<scenario>")
        .Given(<context>)
        .When(<invoking action, "qualifier">)
        .And(<assertion clause , result>)
        .Then(<assertion clause , result>)
        .ExecuteWithReport(MethodBase.GetCurrentMethod());
 

Which a templating tool could generate as * 
using StoryQ;
 using Microsoft.VisualStudio.TestTools.UnitTesting;
namespace StoryQ.Demo
 {
 [TestClass]
public class DemoTest
{ [TestMethod] public void PassingExample()
{
    new Story("Data Safety").Tag("sprint 1")
        .InOrderTo("Keep my data safe")
         .AsA("User")
        .IWant("All credit card numbers to be encrypted")
        .WithScenario("submitting shopping cart")
        .Given(IHaveTypedMyCreditCardNumberIntoTheCheckoutPage)
        .When(IClickThe_Button, "Buy")
        .And(TheBrowserPostsMyCreditCardNumberOverTheInternet)
        .Then(TheForm_BePostedOverHttps, true)
        .ExecuteWithReport(MethodBase.GetCurrentMethod());
}

* StoryQ tests requires far more code than what is shown here, but you get the idea. If you've thoughts on the subject, I'd like to here them.
 

Spec Flow Example

Story is Bowling
Feature:: Score Calculation
In order to know my performance as a player I want the system to calculate my total score

Scenario: Gutter Game: Given a new bowling game, when all my balls are landing in the gutter, then my total score should be 0
Scenario all strikes: Given a new bowling game, when all my balls are strikes, then my total score should be 300

Which maps to

Spec Flow
Feature:: Score Calculation
In order to know my performance
As a player
I want the system to calculate my total score

Scenario: Gutter Game
Given a new bowling game
When all my balls are landing in the gutter
Then my total score should be 0

Scenario all strikes
Given a new bowling game
When all my balls are strikes
Then my total score should be 300

When we examine this in a more structured form, we discover our variables: story, justification, role, modtivation, etc:

Spec Flow
Feature::<story>
In order to <justification>
As a <role>
I want <motivation>

Scenario: <scenario>
Given <context>
When <invoking action, "qualifier">
Then <assertion clause, result>

You can see in both cases that they are using the domain specific language of BDD with only minor differences. StoryQ uses (but does not require) an AND clause.


http://specflow.org/specflow/getting-started.aspx
http://storyq.codeplex.com/

Posted on Wednesday, August 25, 2010 9:15 AM BDD | Back to top


Comments on this post: Executable specifications: pondering BDD tools and automation.

No comments posted yet.
Your comment:
 (will show your gravatar)


Copyright © James Fleming | Powered by: GeeksWithBlogs.net