3

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

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

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

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

4

3 回答 3

4

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

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

于 2011-04-15T01:24:36.550 回答
2

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

最好让测试人员开始编写场景并将它们传递给开发人员，以便开发人员将其引入应用程序中。然后，他们也许可以与开发人员配对并一起实施方案，直到他们自己做起来很舒服。

于 2011-04-26T22:16:28.623 回答
1

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

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

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

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

于 2011-12-17T05:33:53.703 回答