行为驱动开发工具 Cucumber 的质疑

行为驱动开发（BDD）工具 Cucumber 在 Ruby 的 TDD 社区中流行了有一段时间了。它提供了一种编写任何人都能够理解的测试的方法，而不管他们拥有什么技术知识。 这一切都很好，但是 Cucumber 的所有优点都是真正有益的么， Kevin Liddle 在一个 Cucumber 案例中提出了自己的质疑。

理论上 Cucumber 可以作为开发者和管理者之间的桥梁，但是 Kevin 的经验是我们从未按照这种方式去使用它。非技术人员并不会读代码，他们关心的是用例和应用程序的使用。

Kevin 使用 Cucumber 并不是为了测试而是为了收集功能需求。他发现 Gherkin 语法提供了一种非常清晰且简明的解释功能的方式。

Kevin 的建议是停止编写 Cucumber 测试，除非确实有一些不理解纯 Ruby 代码的人要阅读它们。

在一个回复中， Jon Frisby 写下他对 Cucumber 的看法。他发现真正的价值在于捕获功能的意图，要注意，这和 Kevin 的收集功能需求相比有一点细微的不同。

Jon 将需求描述为此刻的时间（moment-in-time）快照，是项目人员之间交流想法的一种手段 。根据那一时刻的上下文这是唯一有意义的东西。相比之下，Jon 将意图看作是一种更加上下文无关的解释目标的方式。他发现在交流需要构建什么的时候它们没那么有用，但是它们却填补了维护系统时需求的空白。Jon 通过一个场景做了例证，在该场景中你正在实现一个功能，但在你这样做的时候测试会失败。按照 Cucumber 即意图规范（Cucumber-As-Intent-Specification）的方式正确编写测试，那么测试将告诉你功能的高层目的是什么。这通常会让它非常容易理解为什么测试会失败，以及如何解决。在他的文章中，Jon 给出了一些他认为能够很好地描述这一意图的功能示例。

Matt Polito 也对 Kevin 的观点做了回应，他阐述的观点可以概括为，Cucumber 让我们能够使用普通的英语描述应用程序的预期行为，而不需要依赖于代码库作为描述这些行为的唯一来源。

Cucumber 是一个开源的 BDD 工具，目前支持 9 中编程语言，包括 Ruby、基于 JVM 的语言和 JavaScript。

.NET 语言是通过 SpecFlow 项目支持的。

查看英文原文： Behaviour Driven Development Tool Cucumber Questioned