BDD测试框架

Question

我们是微软的一个商店，拥有相当成熟的技术堆栈和非常熟练的.net资源。我们从一开始就在使用TDD，现在正在冒险进入BDD领域。我们的工作是由敏捷团队交付的，使用强大的敏捷实践。

我们的最终可测试产品是web、wpf和windows forms。

测试资源已经引入了BDD，并希望学习和使用Ruby和Cucumber来执行测试。开发人员遇到了一些阻力，因为我们更喜欢坚持使用相同的技术堆栈并使用Specflow (或类似的)。来自测试人员的论点是，它更容易学习。

我希望确保开发人员和测试人员没有偏见，并且值得引入另一种技术。

Answer 1

我们有一个类似的设置，我们有测试人员在场景后面编写和实现步骤。我们的测试人员非常喜欢使用.net和c#。我认为，如果你引入另一种技术，你会让开发人员在提交之前不运行测试，并且在测试失败时不承担责任，因为调试它将非常困难。这将意味着你的构建会被破坏，而不是它正在工作。

对于测试人员来说，开始编写场景并将它们传递给开发人员是很好的，因为开发人员将把该功能引入到应用程序中。然后，他们也许可以与开发人员配对，一起实现场景，直到他们自己习惯于这样做。

Answer 2

SpecFlow和Cucumber使用完全相同的业务人员可读语言(gerkhin)来指定功能；唯一的区别是您将使用C# (使用WatiN来驱动基于浏览器的测试)还是Ruby语言(例如使用Watir)来编写步骤定义。因此，无论您选择哪种测试，这些测试都将以非常相似的方式进行组织，并将产生类似的好处。

我猜使用SpecFlow而不是Cucumber的好处是，测试可以很容易地从Visual Studio中运行，也可以从TeamCity或其他基于.NET的持续集成工具中运行。另一方面，当更改Cucumber测试或添加新测试时，不需要等待重新编译(但是，测试代码中的更改通常伴随着生产代码中的更改，因此这可能不会显著节省成本)。在测试基于WPF或Windows Forms的应用程序时，我假设从.NET控制这些应用程序会更容易(但也可能有一些Ruby库用于控制其他图形用户界面应用程序……)

Answer 3

我一直在使用SpecFlow，到目前为止，我发现它非常令人满意。但BDD背后的本质和理念比工具更重要。所有这些工具都可以为业务和开发人员提供一个共同的平台，以发展对系统的共同理解。这里有一篇关于SpecFlow的BDD的很好的文章

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

BDD也可以让您正确地执行TDD。

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