BDD 测试框架答案

【问题标题】：BDD testing frameworkBDD 测试框架
【发布时间】：2011-04-15 01:09:35
【问题描述】：

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

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

测试资源介绍了 BDD，想学习和使用 Ruby 和 Cucumber 来执行测试。开发人员遇到了一些阻力，因为我们更愿意坚持使用相同的技术堆栈并使用 Specflow（或类似的）。测试人员的论点是它更容易学习。

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

【问题讨论】：

编写单元测试的人和编写应用程序代码的人不一样吗？
@jamesaharvey - Cucumber 和 SpecFlow 不是单元测试框架。它的接受程度更高。
@Don Roby：虽然 Cucumber 等人的传统使用模式。确实是验收测试，完全可以将它们用于单元测试。在最近的一个项目中，我们在 SpecFlow 中编写了一些数据密集型单元测试，仅仅是因为使用 gerkhin 的表结构的测试变得比使用 NUnit 编写时更具可读性。
开发人员目前正在编写单元测试和集成测试。我们需要跨职能团队。

标签： .net ruby cucumber bdd specflow

【解决方案1】：

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

我猜想在 Cucumber 上使用 SpecFlow 的好处是测试可以很容易地从 Visual Studio 以及例如从TeamCity 或其他基于 .NET 的持续集成工具。另一方面，当 Cucumber 测试更改或添加新测试时，您不需要等待重新编译（但是，测试代码的更改通常伴随着生产代码的更改，因此这可能不会' t 是一个显着的节省）。在测试基于 WPF 或基于 Windows 窗体的应用程序时，我认为从 .NET 控制这些应用程序会更容易（但可能有一些 Ruby 库用于控制其他 GUI 应用程序......）

【讨论】：

【解决方案2】：

我们有类似的设置，我们有测试人员在场景后面编写和实施步骤。我们的测试人员非常乐意使用 .net 和 c#。我认为，如果您引入另一种技术，您将让开发人员在提交之前不运行测试，并且在测试失败时不对测试负责，因为调试它非常困难。这意味着您的构建将比它的工作更坏。

最好让测试人员开始编写场景并将它们传递给开发人员，由开发人员实施，以便将功能引入应用程序。然后，他们也许可以与开发人员结对并一起实施方案，直到他们自己适应为止。

【讨论】：

【解决方案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/

【讨论】：