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.
Example:
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*/ });
5
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*/ });
10
11
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 …
WE ARE HAPPY THAT WE FOUND STORYQ!
StoryQ is another BDD library you can use to write the BDD tests but it has the following cooooooool features:
- 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
- Nice posibility to add ParameterFormatAttributes
- Nice/painless integration into pure NUnit/MSTests testing => integrated into Resharper/VS.NET IDE
- Sexy exports into the reports (using XML, XSLT) nicely integrated with continous integration i.e. TFS build server
- 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):
- 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.
- calling the method .ExecuteWithSimpleReport(MethodBase.GetCurrentMethod()); we changed to .Run(); using the following extentions method:
11 public static void Run(this Outcome outcome)
12 {
13 StackTrace st = new StackTrace();
14 outcome.ExecuteWithReport(st.GetFrame(1).GetMethod());
15 }
- Empty String-typed arguments are displayed as ” – nothing – so I created EmptyStringParameterFormatAttribute:
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 }
- 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.
- 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 …
thoughts on coding 