BDD testing framework

We are a Microsoft shop, have a reasonably mature technology stack and have very skilled .net resources. We have been using TDD since we started and now are venturing into the BDD space. Our work is delivered by agile teams, using strong agile practices.

Our end testable produc开发者_如何学JAVAt is web, wpf and windows forms.

The testing resources have introduced BDD and would like to learn and use Ruby and Cucumber to perform the testing. There has been some resistance from the developers, as we would prefer to stick with the same technology stack and use Specflow (or similar). The argument from the testers is that it is simpler to learn.

I want to be sure that the developers and testers are not being biased, and that it is worthwhile introducing another technology.

---

Both SpecFlow and Cucumber use the exact same business-person-readable language (gerkhin) to specify the features; the only difference is whether you'll write the step definitions in C# (using e.g. WatiN to drive browser-based tests) or Ruby (using e.g. Watir). So the tests will be structured in a very similar manner and will yield similar benefits no matter which one you choose.

I guess that the benefit of using SpecFlow over Cucumber is that the tests will be easily runnable from Visual Studio, as well as from e.g. TeamCity or other .NET-based continuous integration tools. On the other hand, when Cucumber tests are changed or new tests are added, you don't need to wait for recompilation (however, a change in the test code is often accompanied by a change in the production code, so this probably won't be a significant savings). When it comes to testing WPF-based or Windows Forms-based apps, I assume that it will be easier to control those applications from .NET (but it could be that there is some Ruby library for controlling other GUI applications...)

---

We have a similar setup, we have testers writing and implementing steps behind scenarios. Our testers are quite happy staying with .net and c#. I think that if you introduce another technology you would have developers not running the tests before they commit and not taking responsibility for the tests when they fail as it would be extremely hard to debug it. This would mean your build would be broke more than it's working.

It would probably be good to start for the testers to write the scenarios and passing them to development to be implemented by the developer that is going to introduce the feature into the application. They can then perhaps pair up with the developer and implement the scenarios together until they are comfortable doing it themselves.

---

I have been using SpecFlow and found it quite satisfactory up till this point. But it is the essence and the idea behind BDD that is more important than the tool. All these tools can do facilitate a common platform for the business and the development folks to develop a shared understanding of the system. Here is a very good post on BDD with SpecFlow

http://codingcraft.wordpress.com/2011/12/17/bdd-with-specflow

BDD can get you to do your TDD right too .

http://codingcraft.wordpress.com/2011/11/12/bdd-get-your-tdd-right/