thoughts on coding

March 25, 2010

NBehave out, StoryQ in

Filed under: BDD, NBehave, StoryQ, TDD, Uncategorized — Tags: , — Frantisek @ 10:39 am

I use Behavior Driven Development (BDD) style of the development for last few years. Just for the explanation as I see BDD, BDD is Test-Driven development (TDD) with the description of the tests.

I used TDD in past but I found out that I wrote many comments in the code. Then I started to extract the commented code into the methods whose name was exactly that comment. BDD enables to translate the method names into the text and export that text while running the test. You can find very nice example of this here or exactly the steps I described here. Please note fluent style of the naming the methods and basically all the stuff.

By the way, you can read about the core BDD syntax here.

Until now we used NBehave to define the stories but … I think the biggest disadvantage of this library is the string-adidtive style.

    1          WithScenario("text ......")

    2                 .Given("a text describing give ", "arg", arg => {/* some code*/ })

    3                 .When("a text describing when operation", () => {/* some code*/ })

    4                 .Then("a text describing then operation with expectation", "expectation",  arg => {/* some code*/ })

In case of having 2 tests which share the same test step, i.e. …… it’s recommended (in order to follow DRY principle) to extract the code to the method and use this method in the test.


    1             WithScenario("text ......")

    2                    .Given("a text describing give ", "arg", TextDescribingGiven)

    3                    .When("a text describing when operation", () => {/* some code*/ })

    4                    .Then("a text describing then operation with expectation", "expectation", arg => {/* some code*/ });


    6             WithScenario("text 2......")

    7                    .Given("a text describing give ", "arg", TextDescribingGiven)

    8                    .When("a text describing when operation", () => {/* some code*/ })

    9                    .Then("a text describing then operation with expectation", "expectation", arg => {/* some code*/ });



   12         private void TextDescribingGiven(string arg)

   13         {

   14             /* some code*/

   15         }

It was usual that we changed the code in the step, so we changed the method name, too (using refactoring). But we were too lazy to change also the strings which described the step name. This resulted into wrongly named step decriptions => test description is useless. The developers have to follow very strict rules and you know how hard it is. This functionality was used in NBehave v0.3 and v0.4.

NBehave team released new version 0.4.5 which makes all the above mentioned usage obsolete and dictates us to write the stories in the external file in text form! and then map it (via strings!!!) against the  code! It’s strange step for me because many .NET community stuff tries to avoid using string (i.e. Expressions, etc.) This is hardcore step, I would say. I hate strings and it’s to avoid them as much as possible.  That was the reason why I tried to find out some another library which could create the step description from the method name (methods were named fluently) or we will try to write our own.

We used NBehave for 3 years and we tried to integrate them into NUnit tests with using Resharper to run the tests but …


StoryQ is another BDD library you can use to write the BDD tests but it has the following cooooooool features:

  1. step description is created from the method name, i.e. .Given(IHaveTypedMyCreditCardNumberIntoTheCheckoutPage) => translates to => Given I have typed my credit card number into the checkout page
  2. Nice posibility to add ParameterFormatAttributes
  3. Nice/painless integration into pure NUnit/MSTests testing => integrated into Resharper/VS.NET IDE
  4. Sexy exports into the reports (using XML, XSLT) nicely integrated with continous integration i.e. TFS build server
  5. amazing StoryQ Converter GUI which enables you to write the stories and translate them into the code – it creates testing code envelope!

Check all these features on their web. There is qood documentation.

My comments and enhancements to StoryQ
After using StoryQ for some time I found out that it would good (at least fro my point of the view) the following extensions/changes (we did few of them):

  1. we used to write 1 story in 1 class but with several scenarios. Each scenario is the separated test method. Because there are several strings (again used), I would suggest:
    • scenario description should be created based on the method name
    • story name could be created based on the whole class name

    This extentions/change could avoid using strings. The question is how this could be integrated into NUnit without any pain in order to get the textual representation of the tests.

  2. calling the method  .ExecuteWithSimpleReport(MethodBase.GetCurrentMethod()); we changed to .Run(); using the following extentions method:
  3.    11 public static void Run(this Outcome outcome)

       12         {

       13             StackTrace st = new StackTrace();

       14             outcome.ExecuteWithReport(st.GetFrame(1).GetMethod());

       15         }

  4. Empty String-typed arguments are displayed as ” – nothing – so I created EmptyStringParameterFormatAttribute:
  5.     5 public class EmptyStringParameterFormatAttribute : ParameterFormatAttribute     6     {     7         public override string Format(object value)     8         {     9             if (value != null)    10             {    11                 var str = value as string;    12                 if (str == null || str.Length != 0)    13                 {    14                     return value.ToString();    15                 }    16                 return "empty string";    17             }    18             return "{NULL}";    19     20         }    21     }
  6. It’s big shame that StoryQ Converter doesn’t use T4 templates to generate the code because it would be good to extend/change the default code generation which is currently hard-coded.
  7. It would be good if it would be possible to specify in StoryQ Converter also the argument names, i.e.  when building the shared component with $id:1 => could create a code (BuildingTheSharedComponentWithId, 1) and the method signature could be BuildingTheSharedComponentWithId(int id). It’s just a nice to have feature 😮

I must say StoryQ is really coool library with amazing Converter. Btw, it was really nice to read and know how SrotyQ team developed this library – usign Flit (Fluent Interface toolkit in conjuction with Irony and Dot/GraphViz) which is really coool way and it’s worth another blog posts.

That’s all for now …



  1. For point #1, how’s this?

        public abstract class StoryTestBase
            private Feature feature;
            protected StoryTestBase()
                Story s = new Story(Uncamel(GetType().Name));
                feature = DescribeStory(s);
            protected abstract Feature DescribeStory(Story story);
            protected Scenario Scenario
                    return feature.WithScenario(Uncamel(new StackFrame(1).GetMethod().Name));
            private string Uncamel(string methodName)
                return Regex.Replace(methodName, "[A-Z_]", x => " " + x.Value.ToLowerInvariant()).Trim();

    Comment by Rob — March 25, 2010 @ 3:33 pm

    • Rob, thanks for you comments. Really good inspiration, so I wrote about it here

      Comment by Frantisek — March 26, 2010 @ 11:05 am

  2. For comments and enhancements point #2 & #3: I think I’ll incorporate those into StoryQ (although StackFrame isn’t reliable in some cases so I might keep the overload)

    For points 4 & 5, I’d encourage you to clone/fork the StoryQ repository and just change the code to do what you want! I’m trying to keep things simple, which sacrifices some generic-nessousity, but if you clone the mercurial repository then you should have no trouble merging your changes in with whatever we do to StoryQ in the future.

    You can host your fork publicly if you like:

    Comment by Rob — March 25, 2010 @ 3:46 pm

  3. […] Filed under: Uncategorized — Frantisek @ 11:04 am Thankfully to Rob who inspired me from the comments in my previous post with the easy way how to create the scenario description from the test method name, I decided to […]

    Pingback by StoryQ: scenario enhancements « Exploring the world … — March 26, 2010 @ 11:10 am

  4. I ended up checking in point #4. “given an id of $id:5 and a login at {loginDate:2010-12-25}” will produce

    private void AnIdOf_AndALoginAt_(int id, DateTime loginDate)
    throw new NotImplementedException();

    Comment by Rob — April 6, 2010 @ 1:45 pm

  5. It’s probably too late for you, but the fluent syntax in NBehave has just been reinstated. On the trunk at least … it will get released in v0.5. I’ve posted about it at

    Comment by John Rayner — April 7, 2010 @ 10:51 pm

  6. hi,

    have you managed to integrate storyq with tfsbuild 2010? thank you.

    Comment by moby — October 16, 2011 @ 1:45 pm

    • yeap, there are two solutions: the first is to use it withing MSTests. Then you can execute a task to run the tests which creates a TFS standard file. This files can be viewed directly from VS.NET. Another solution is to ask StoryQ to export the results into XML file and then to add the link to the exported file to TFS build result. When you want to open that XML, you need to use XSLT.

      We’re configuring TFS build to run StoryQ for Silverlight tests, I’ll let you know later about the results and how to configure it.


      Comment by Frantisek — October 16, 2011 @ 8:47 pm

      • thanks, for your response. appreciated it.

        currently my struggle to be able to prepare an environment where we can use and storyq within automated build environment.
        so far managed to use storyq with xunit via resharper runner. desperately looking for any for any guidelines in this direction.

        Comment by moby — October 16, 2011 @ 10:59 pm

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

Blog at

%d bloggers like this: