views:

1301

answers:

4

I am trying to decide if I should use Cuke4Nuke or SpecFlow. What are the pro/cons of each? Opinions on which is better and why.

Thanks!

+19  A: 

(I might be biased because I am involved with SpecFlow, but here my thoughts...)

Cuke4Nuke is very close to Cucumber. This promises a lot of advantages:

  • Compatibility
  • Getting new features from Cucumber when Cucumber evolves (at least in theory, but language support is an example for this)
  • Being a real part of the Cucumber community and the Cucumber ecosystem

However this comes also with some potential disadvantages:

  • Ruby is a necessity
  • Since more infrastructure (Ruby, Wire-Protocol, command-line integration...) is involved, the complexity of the whole solution rises, and chances that something in the chain is failing rise
  • Debugging is possible but a bit of a hassle
  • Running scenarios on the dos-commandline is just plain ugly, and I still have problems with some characters (German Umlaute). The solutions from Cucumber did not work for cuke4nuke in my case.
  • Integration with your continuous build is something you have to work out for yourself

SpecFlow is a separate project from Cucumber. It tries to be as close to Cucumber as possible, but there are and will be gaps. There are plans to use the same parser as Cucumber, to improve compatibility on the language level.

SpecFlow tries to offer the following advantages:

  • A pure .NET solution (so no installation of Ruby is necessary and Ruby is not involved at runtime)
  • There is a basic integration with VisualStudio (and there are plans to evolve this)
  • Scenarios are basically UnitTests and can be run with your existing infrastructure (NUnit.Runners, ReSharper, VisualStudio MSTest Integration ...)
  • Scenarios and steps are easily debuggable out of VisualStudio (just set a breakpoint)
  • Integration in your continuous build should be a breeze, since the infrastructure to run unit-tests is most certainly there already

As disadvantages of SpecFlow I see currently:

  • It does not support as many languages as Cucumber
  • Currently there is a "code generation" step involved. This is transparent when using VisualStudio, and there is a commandline to do this without VisualStudio, but a lot of people do not like code-generation.
  • Currently there is no explicit commandline runner for SpecFlow. However you can use your unit-test commandline runner.
  • SpecFlow depends on a Unit-Test framework, and currently only NUnit and MSTest is supported
  • Reporting in SpecFlow is not very sophisticated yet. Cucumber does offer more options, however I don't know if they are all available in cuke4nuke...
jbandi
Thanks for the great insight. I am a .NET developer so based on your comments I am going to try Specflow for now.
Rich Blumer
I also appreciate your comments, jbandi. I made a similar comment on another post in that the ability to run my SpecFlow tests in ReSharper (like any other NUnit test) is a very practical advantage over Cuke4Nuke. Not installing Ruby is another (after all we have to keep the build server up to date and it is one more thing to worry about).
Randy Eppinger
On board,..great run down jb. Fully cleared this choice up for me. Now I've just got to convince the manager. :-)
Stimul8d
As of version 1.3.0 they support xUnit, version 1.3.1 adds support for MbUnit, and version 1.3.2 adds support for MsTest 2010 (vs 2010 edition). Also, the parser has been changed to the standard Gherkin parser (http://github.com/aslakhellesoy/gherkin) v2.0.1 (in version 1.3.1). The project is evolving fast enough
Bogdan Maxim
+4  A: 

jbandi gives a good summary. I answer the question in much the same way (with the opposite disclaimer for bias, of course).

The goal for Cuke4Nuke is full Cucumber compatibility in .NET while duplicating as little Cucumber code as possible. Therefore, some of the trade-offs you highlighted—e.g. the Ruby dependency—are inherent to the tool. Others, like bugs in language and formatter support and limited debugging support, are temporary issues and will go away with future versions.

I've run into a few issues where Cuke4Nuke doesn't work quite like Cucumber. But as I work primarily in English, I don't see the language-related issues in my normal work. I'd welcome steps to reproduce any of these issues so I can fix them. (Please post to them the Cuke4Nuke issues list, not here.)

Richard Lawrence
+2  A: 

Another heavily biased opinion: Try StoryQ :)

StoryQ tests are actually code, so you get much better refactoring / IDE support, and it embeds within your existing unit test runner, so CI is a breeze.

It's probably a matter of preference whether you'd rather check in plain text features or compilable code. But for us we found that it was really nice to be able to rename narrative methods and have all the stories update themselves.

There is actually a GUI provided that will convert plain text scenarios into StoryQ code for you, if you've already got an investment in plaintext scenarios or if you'd like to give the keyboard to your business people. It's even got a simple form of intellisense!

Give it a go if you want an ultra-lightweight entry point into BDD :)

Rob Fonseca-Ensor
+2  A: 

Another biased response: StorEvil eats all other .NET BDD tools.

Advantages: StorEvil has its own command-line runner, has nice reporting (using the Spark view engine), and has the best plaintext->C# translation and execution engine.

Also, it has 100% more Evil than any other solution.

Disadvantages: StorEvil does not fully support other human languages (except English). StorEvil's Visual Studio integration is not yet as nice as the other tools. StorEvil will drink all the beer in the fridge if you don't keep an eye on it.