The Future of Cucumber on .NET
Beginning just over two years ago, I worked with some great developers to create Cuke4Nuke as a way to bring Cucumber to .NET. Shortly after the first releases of Cuke4Nuke, TechTalk released SpecFlow, a native .NET tool inspired by Cucumber. As a pure .NET solution without Ruby dependencies, SpecFlow seemed to be easier for Microsoft shops to adopt. But Cuke4Nuke had (to me) enough advantages that I kept it going.
By this summer, however, it was clear that SpecFlow had made up for most of Cuke4Nuke’s advantages and had more momentum in the .NET community and was under much more active development. There were just a few gaps SpecFlow needed to overcome (in my opinion), mostly related to better harmonization with the other Cucumber projects. (With the pure Java Cucumber-JVM under active development as a Cuke4Duke replacement, there was no longer as compelling an argument for shared code between Cucumber versions, Cuke4Nuke’s biggest remaining advantage.)
At AA-FTT and later in the week at Agile 2011, my colleague Paul Rayner and I met with Christian Hassa and Gaspar Nagy from the SpecFlow team. We discussed the few things that needed to change in SpecFlow to make it behave more like the other Cucumbers.
This week, most of those changes were released as part of SpecFlow 1.8. With that release, I’m letting Cuke4Nuke die. I won’t be maintaining or extending Cuke4Nuke. My Cucumber classes and book will cover SpecFlow rather than Cuke4Nuke.
I’ve had a great time getting to know the SpecFlow guys, and I look forward to collaborating with them in the future to help bring Cucumber to more and more teams in the Microsoft world.
Personally, I’m saddened by the fact that the most important feature of any tool in .NET ecosystem seems to be Visual Studio integration. I’m sure that SpecFlow is a well-written tool, but I’ve seen teams jump on it without even evaluating alternatives (including plain Cucumber) just because “it’s integrated”. This kind of closed ecosystem centered on “one tool to rule them all” is ultimately hurting the .NET world at large, but most developers don’t seem to notice the opportunity costs of this monoculture.
Totally agree, @Nusco. I finally decided it wasn’t worth my energy to fight it, though.
@Nusco – I should add…I just wrapped up a week of training and coaching with another .NET client in a string of .NET clients who tried both Ruby Cucumber and SpecFlow side by side on their own stories and chose Ruby, so there are bright spots.
Nice to hear… All those .NET developers moving to Ruby might be raising the curiosity of people who choose to stay. If .NETters open up to using the right tool for the job instead of sticking to their comfort zone, then everybody wins.
I can imagine how hard it must be to let go of a project you’ve put so much work into, so well done. It sounds as though it was the right decision.
There’s one great benefit that remains from the work we did on Cuke4Nuke: Cucumber’s wire protocol. That’s allowed Cucumber to reach into languages like PHP and ActionScript, and the developers who work on those stacks. I’ve head a lot of compliments about the wire protocol over the years, and that’s down to the work we did to shape it for Cuke4Nuke.
Thanks for the contribution to the community and for pushing it as far as you did.
We have been working for a while with Richard, Paul, Christian, Jonas and Darren for the preparation of this and we keep working together to provide the necessary support for doing Cucumber-style BDD for the .NET developers. I also would like to thank to them and anyone who have contributed or ever will contribute to Cuke4Nuke or SpecFlow.
I’m looking forward to include any good ideas that make BDD more efficient and more fun on .NET and ideas from Cuke4Nuke are especially welcome.
I’d sure like to see the Wire protocol support in SpecFlow – that was golden when used to drive test DUT’s from an external PC.