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/     

要回复问题请先登录注册