I was recently interviewed for a podcast about my Behaviour Driven Development framework, StoryQ. David Starr from Pluralsight did a great job with the interview – check it out at www.pluralsight-training.net/community/blogs/pluralcast/archive/2010/06/21/pluralcast-18-bdd-in-net-with-storyq.aspx.

David also gave a great presentation on BDD at the 2010 tech ed in New Orleans, and I highly recommend it for anyone wondering how to get started, or even whether they should get started, with BDD: http://www.msteched.com/2010/NorthAmerica/DPR302

Improvements

I think this is a good opportunity to talk about some of the new features in StoryQ. My first post on StoryQ came when we’d just committed it to codeplex, and a lot has changed since then:

• We’ve moved to Mercurial, which means our users can create public forks
• No more ()=> operator. Thanks to FLIT, our fluent interface has evolved to accept plain old delegates, instead of Expression<Action>s.
• Tagging. Any Step can be “tagged”, which makes it easy to find in the output report
• By default, the HTML report generated by StoryQ is JQuery-enriched, which makes it easy to narrow down stories by class hierarchy or tag. I’m particularly proud of this report – it’s a great way to share test results with everybody, especially when published from a continuous integration server.
• A rewritten converter gui, which lets you convert plain text stories into StoryQ code. The new version lets you choose what level of code generation you want (from Story initialisation statement to entire test class), and offers a basic form of intellisense.

Roadmap

• The new fluent interface architecture allows us to support multiple (human) languages, and I’m looking forward to creating fluent interfaces for non-english speakers.
• I think we’ll be able to create a new way of doing BDD in .NET that takes advantage of C# 4.0′s dynamic features
• We still haven’t added xUnit support! Which is lame, because it’s probably going to be really easy…

Please check StoryQ out and let us know if you’ve got any bright ideas for it! And if you’ve never tried BDD, you should definitely look into it. It’s even more fun than TDD!!!

If you weren’t at my talk and have any questions – I’m in the market for more comments.

I’ve got one more link to add, these podcasts were what actually inspired my subject: http://channel9.msdn.com/shows/ARCast+with+Ron+Jacobs/ARCastnet-Presenter-First-Pattern-Part-1/

Here is my source code (perfectly commented), and here are my slides

Stay tuned for a bigger (50 line) do-it-yourself DI container that would be useful in production.

Sweet. Now I can use the Resharper test runner (superb) on MsUnit tests (mandated).

Here in .Net land, we’ve got an awful lot of choice if we want to write unit tests. First we had NUnit and MbUnit, then Microsoft came to the party and cloned NUnit. These day’s there’s also xUnit and the exotic NBehave.

Back when I was learning Java, there was pretty much just JUnit. You could write your tests in that one framework, and then they could be run pretty much anywhere (just like java ). You could use the JUnit console runner, the GUI runner, eclipse, intelliJ, NAnt, CruiseControl – they all knew how to run JUnit tests, because JUnit was the defacto.

These days, in .Net, we get to choose between lots of different testing frameworks, each with their own strengths and weaknesses. Each of these frameworks comes with their own test runner, for example, visual studio is (arguably) capable of executing MsUnit (AKA MsTest AKA TfsUnit) tests. TestDriven.Net came along and made the visual studio integration much nicer. You’d also typically be executing these tests from MSBuild if you were trying to do Continuous Integration. NUnit has its own GUI for running NUnit tests, and there are a lot of third party NUnit test runners.

Personally, I’m a big fan of the Resharper test runner, because you just click on the little green icon by your test and it’s started testing. The test results window is what cinches the deal, it provides you with a hierarchical view of your test results, and makes it really easy to re-run whatever you like.

But it only works on Nunit:

James Kovacs had written a MsUnit plugin that let Resharper run MsUnit tests – but those crazy jetbrainers have been upgrading things again and now the plugin doesn’t work.

Enter Gallio:

The Gallio Automation Platform is an open, extensible, and neutral system for .NET that provides a common object model, runtime services and tools (such as test runners) that may be leveraged by any number of test frameworks.

Essentially, Gallio is a bridge between ALL of the testing frameworks I’ve just mentioned and a huge number of test runners. The number one thing for me is that now I can use the Resharper runner on my MsUnit tests. All I had to do was grab the installer off the Gallio website, run it, and the next time I started Visual Studio, Resharper was ready to run my MsUnit tests:

I’m impressed that the people behind Gallio have been able to define a common object model for all these different testing frameworks.

I’d be really keen to see a Gallio plugin for TeamCity. Browsing through the Gallio discussions, it seems like it’s definitely on its way. But seriously, I think Jetbrains should be lending a hand here: both with the TeamCity plugin and with Resharper. They’d only be helping themselves.

NB: I just tried this with Resharper 4.1 RC2, and it seems like those rascally jetbrainers have broken things again. I’m sure the Gallio team will get right on it as soon as Resharper 4.1 is stable…

If you’re looking to get Gallio working with Reshaper 4.1+, check out Jeremy’s comment on this post…

NBehave, much like ruby’s rspec, is a great framework for making user stories executable within your IDE. Outside of your IDE, you’ve got things like Fitnesse, ZiBreve, and Twist - which are better if you want non technical people to be able to interactively define storys. On our project, however, we had technical people putting the acceptance tests into our Nunit project. Now, NBehave is written as an extension to NUnit, so i guess you could say they are compatible, but NBehave wasn’t compatible with the two NUnit runners that we were using all the time. Our developers used the superb Resharper test unit runner as they coded, and our build server (TeamCity, damn you JetBrains!) both wanted to run plain old NUnit.Framework.TestAttribute Tests.

So we set out to create a simple framework for running things that looked like story tests from within any test framework. StoryQ is what Todd & I came up with. The key points of difference from NBehave are:

• No dependency on any particular unit testing framework (although StoryQ does like to know what kind of Inconclusive / Pending exception your framework uses)
• StoryQ can use Lambda Expressions to make a sentence-like string out of a method call. This might not sound like much, but it actually takes away a lot of duplication pain. Thanks, LINQ!
• When you run a brand new story test, it will be marked as pending (not failed).
• By default, StoryQ output goes to Console.Out. You can also make it write a coloured html report to a file.
• There is a GUI in the project that can convert from plain text into test case code.

We’ve tried to keep it all very simple and lightweight. If you feel like your current acceptance testing framework is too clunky, or if any of the benefits above sound good to you, then please grab the code and check out the samples. There’s an explanation up on the project homepage. We are very keen for feedback: issues, comments, feature requests, contributors – please don’t hold back.