BDD测试框架

如何解决BDD测试框架

| 我们是一家Microsoft商店，拥有相当成熟的技术堆栈，并且拥有非常熟练的.net资源。自从我们开始使用TDD以来，我们一直在进入BDD空间。我们的工作是由敏捷团队使用强大的敏捷实践来交付的。 我们的最终可测试产品是Web，WPF和Windows窗体。 测试资源介绍了BDD，并希望学习和使用Ruby和Cucumber进行测试。开发人员一直存在一些阻力，因为我们宁愿坚持使用相同的技术堆栈并使用Specflow（或类似的产品）。测试人员的论点是，它更容易学习。 我想确保开发人员和测试人员不会受到偏见，并且值得引进另一项技术。     

解决方法

我们有一个类似的设置，我们有测试人员编写和实施场景背后的步骤。我们的测试人员很高兴与.net和c＃在一起。我认为，如果您引入另一种技术，则将使开发人员在提交测试之前不运行测试，并且在测试失败时不对测试负责，因为调试起来非常困难。这意味着您的构建将无法正常工作。 对于测试人员来说，开始编写场景并将它们传递给开发人员，以将功能引入到应用程序中来进行开发，可能是一个不错的选择。然后，他们也许可以与开发人员结对并一起实施方案，直到他们自己满意为止。     ,SpecFlow和Cucumber都使用完全相同的业务人员可读语言（gerkhin）来指定功能。唯一的区别是您将使用C＃（使用例如WatiN来驱动基于浏览器的测试）还是Ruby（使用例如Watir）来编写步骤定义。因此，无论您选择哪种测试，测试的结构都将非常相似，并且会产生相似的收益。 我猜想使用SpecFlow而不是Cucumber的好处是可以轻松地从Visual Studio以及其他示例中运行测试。 TeamCity或其他基于.NET的持续集成工具。另一方面，当更改Cucumber测试或添加新测试时，您无需等待重新编译（但是，测试代码的更改通常伴随着生产代码的更改，因此，这样做可能会赢（不是一笔可观的节省）。在测试基于WPF或基于Windows Forms的应用程序时，我认为从.NET控制这些应用程序会更容易（但是可能有一些Ruby库可以控制其他GUI应用程序...）     ,到目前为止，我一直在使用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/