BDD工具Cucumber十周岁：创建者Aslak Hellesøy访谈

BDD

摘要

Cucumber的创建是为了应对不明确的需求和误解，但是，于2008年创建Cucumber的Aslak Hellesøy在几年前说过，如果你把Cucumber看成一个测试工具，那么你就错了。在接受InfoQ的采访时，他谈了自己从事行为驱动开发（BDD）和Cucumber相关工作的经历以及他对这个现在已经10周岁的工具的未来的思考。

正文

Cucumber的创建是为了应对不明确的需求和误解，供项目团队的非技术成员和技术成员使用，但是，于2008年创建Cucumber的Aslak Hellesøy在几年前说过，如果你把Cucumber看成一个测试工具，那么你就错了。在接受InfoQ的采访时，他谈了自己从事行为驱动开发（BDD）和Cucumber相关工作的经历以及他对这个现在已经10周岁的工具的未来的思考。

InfoQ：您能简要介绍下Cucumber以及它与行为驱动开发（BDD）的关系吗？

Aslak Hellesøy：Cucumber是一个支持BDD的工具，而BDD是TDD（测试驱动开发）的一个变种。借助BDD，所有的测试都是客户验收测试，这些测试是使用普通的（人类）语言编写的，因此，非技术的干系人也能理解。Cucumber把需求规格说明书、自动化测试和在线文档合并成了一种格式Gherkin，这种格式就是普通的英语，然后稍微加了点结构。

（如果做得好）BDD可以带来返工减少、Bug减少、代码可维护性提高等好处。为了获得这些好处，你必须花点精力挖掘需求，并设计出可测试的软件。通常，需求挖掘很快就会有回报，而设计可测试的软件往往会是一种长期的回报。BDD可以帮助团队快速发现错误，让软件开发更快乐、更可持续。

InfoQ：您10年前是因为什么创建了Cucumber？

Hellesøy：在创建Cucumber之前10年，我一直是一名软件顾问。在我职业生涯的头5年（1998年至2003年），我参与的所有项目都有同一个问题：

• 我经常不知道我是否完全理解了需求
• 我发现很难建立那样的自信，就是我们正在构建的东西可以正常运行
• 我害怕变更现有的代码，不知道会对哪里造成破坏
• 我们总是延期

在我创建Cucumber之前5年（2003年），我加入了三个部分重叠的社区，向现在我们称之为BDD的开发方法贡献了大量的想法。在这5年里，我有机会和一些真正高效的团队合作，这在我职业生涯初期是不曾遇到的。我们交付，我们自信，我们乐在其中。

第一个社区是XP社区，也就是TDD产生的地方。由Ward Cunningham创建的Fit和由Robert C. Martin创建的Fitnesse对我也有很大的启发。

第二个社区在ThoughtWorks内部，我那时在那里工作。Dan North、Chris Matts、Liz Keogh、Joe Walnes、Paul Hammant和Chris Stevenson正在开发TDD的变种，而且更关注语言，他们设法在业务需求和编程之间搭建一座桥梁。

第三个社区是Ruby社区，David Chelimsky、Steven Baker和Dave Astels构建了第一款具有重大影响的BDD工具RSpec。

Dan North和David Chelimksy在RSpec中实现了对Given-When-Then语法早期版本的支持。我喜欢上了可执行的规格说明书这一理念，希望可以更进一步，但是，我感觉自己受到RSpec设计决策的限制，它的关注点更底层。

我把RSpec的Given-When-Then解析器提取到一个单独的库里，开始大幅地改进，让它更友好，比如，有用的错误信息、打印代码段、为输出添加颜色、扩展语法、提升速度等等。

我的妻子建议我叫它Cucumber（没有特别的原因），它的名字就是那样来的。我还决定给Given-When-Then语法起个名，从这个工具中独立出来。那就是为什么我称之为Gherkin（腌制过的小黄瓜）。

InfoQ：这些年来，Cucumber在社区的使用情况怎么样？

Hellesøy：完全超出预期！10年来，其使用情况一直在稳步增长，用户数每18个月翻一番。其增长尚未出现放缓势头。单是在2017年，Cucumber的下载量就有2000万次（Java、.NET、Ruby、JavaScript、PHP和Python实现总计）。

第一个增长高潮是在2008年到2011年间，来自Ruby on Rails。

第二个高潮是在2011年，Matt Wynne和我出版了The Cucumber Book之后，该书已经卖了将近2万册。我们的书把Cucumber和BDD带给了新用户。产品经理和业务分析人员开始认识到，这是一种可以减少需求误解的方式。Gojko Adzic的著作Bridging the Communication Gap和Specification by Example也帮助推广了这种理念。

我们的书也把Cucumber带到了测试社区，他们把它视为一种自动化测试方式。具有讽刺意味的是，这导致人们误认为BDD和Cucumber是面向测试的，而且只是测试。当Dan North提出BDD的时候，他的目标是让TDD更好用，是了让开发人员更容易理解，TDD是一项设计和软件开发技术，而不是测试。

但是，我认为，如果你只有一把锤子，那么任何东西都会看上去像钉子。

现如今，Cucumber已经成为许多组织标准工具集的一部分。有些把它用作BDD，但大多数只是把它用于“BDD测试”，不管那意味着什么，它的名字都是“行为驱动开发”。

InfoQ：从创建至今的10年中，Cucumber经历了怎样的发展？

Hellesøy：在2008年，Cucumber的初始Ruby版本发布几年之后，更多其他语言的实现也相继推出：

• Gaspar Nagy创建了面向.NET的SpecFlow
• Julien Biezemans创建了面向JavaScript和Node.js的Cucumber.js
• Konstantin Kudryashov创建了面向Behat的PHP
• 我创建了面向Java和其他JVM语言的Cucumber-JVM

现如今，对于每一种主要的编程语言（也有许多面向非主流语言的），都有一种Cucumber实现。这些实现中的大多数都和最初的Ruby实现十分类似，但是，由于维护这些实现的团队彼此独立地工作，所以它们也有一点不同。这总的来说是一个好事；这样会有更多创新。那是一种很棒的共生关系。我们复制彼此的想法。下面是过去几年中新增的部分最重要的特性：

• Cucumber表达式——正则表达式的一种替代方案，比前者更友好
• 标签表达式——一种面向Gherkin标签的布尔查询语言，简化执行场景选择
• Suites（目前仅限于Behat）——更容易在不同的配置下运行同一个场景（通过UI或在后台）
• IDE集成，包括IDEA、IntelliJ和Visual Studio

不同实现的差异推动了创新，但也提出了一些挑战。每一种实现和文档的维护都有大量的重复工作。为了解决这个问题，我们很快将发布一个新的网站，它将提供一个统一的地方记录所有正式的Cucumber实现。这可以鼓励贡献者把他们的实现集中在一起，让它们更加一致。10年之后的今天，我们不再需要早期的这种差异和创新——我们现在更需要的是一致性和维护工作的可持续性。

近日，Cucumber.js团队的Charlie Rudolph使用Go编写了一个试验性的共享二进制文件，可以用作所有Cucumber实现的基础。这有可能简化所有的实现，这意味着我们可以为我们的用户提供更好的产品。

最后，我们计划对Gherkin语言本身做些修改，让它更符合BDD这些年的发展。我们会确保它向后兼容——我可不想被邮件轰炸！

InfoQ：Cucumber和BDD是什么关系？

Hellesøy：在过去的10年里，我自己（以及我的Cucumber/BDD伙伴）的BDD方法已经发生了很大的变化，这影响到了Cucumber。有时候，我们对Cucumber做了修改，那会改变人们的实践。Cucumber和BDD密不可分，我这里有几个例子。

Behat项目的Konstantin几年前向我介绍了一项新的BDD技术，他称之为“实例建模（Modeling By Example）”。思路很简单，就是从部分描述预期行为的几个场景入手。我知道声明式场景（没提供技术细节）比命令式场景（有大量的UI细节）好有一阵子了。在他向我展示之前，我没考虑过的是，这同时也让你选择一个不同的开发起点。

之前，我总是从UI开始。Konstantin让我知道，场景也可以用于推动领域逻辑的开发——在UI背后，协议层（如HTTP）之下。这让你可以在同一个进程中运行Cucumber和你正在开发的系统。这些测试速度极快，通常是毫秒级的，对生产力有深远的影响。它让你可以非常快速地向稳定的领域模型迭代。

这是着手开发UI（或者协议层，如HTTP）的更好时间。因为这些场景不受实现细节的影响，我们可以使用同样的场景（借助不同的自动化代码）推动UI或协议层的开发。

如果你只需要告诉Cucumber把每个场景运行两次，那么工作流程会大大简化——一次在后台（用可靠性换速度），一次通过UI（用速度换可靠性）。Konstantin向Behat添加了一个特别的特性“Suites”，这也是我希望在其他Cucumber实现中添加的东西。所以，这是BDD实践改变对工具产生影响的一种方式。

“实例映射（Example Mapping）”是最近出现的另外一种可能影响Cucumber的BDD实践。这是我同事Matt Wynne提出的一种分析技术。实例映射是一种简洁的协作技术，把用户故事分解成稍后可以变成场景的实例。现如今，我都是先做实例映射，我甚至都没有考虑过编写一个Cucumber场景。它已经从根本上改变了我们团队（以及我们培训过的数以百计的团队）的需求分析和测试设计方法。

实例映射按规则把实例分组。由于Gherkin没有一个规则结构，当你尝试把一个实例映射“翻译”成Gherkin语法时，这会导致一点阻抗失谐。因此，我们计划在Gherkin中增加关键词“Rule”，并把“Example”作为“Scenario”的同义词。

InfoQ：您是一名BDD及Cucumber专家。这些年，您针对这个工具所做的工作有变化吗？

Hellesøy：当然。其中有件事，我一直念念不忘，就是测试速度，在过去的几年中，这方面已经有了长足的进步。

Jakob Nielsen和Mihaly Csikszentmihalyi的研究表明，对于大多数人而言，等待反馈的时间超过10秒，他们就很难继续专注于手头的工作。UX设计人员知道这一点——这就是为什么当事情需要花点时间时会有进度条和旋转指针。为程序员开发工具的人们似乎还没有意识到这一点。

一个需要等待1到5秒就可以得到测试反馈的程序员，和需要等待30秒的程序员，其生产力会有显著的不同。在1到5秒内，你可以保持非常高效的状态，持续几个小时。如果你总是被打断，就不会出现那种情况。我们已经非常习惯于缓慢的反馈，我们已经预料到，并采取变通措施，而不是解决这个问题。测试金字塔就是这样的一种变通方案。传统观点告诉我们，通过UI进行的全栈测试缓慢而脆弱。因此，我们较少做缓慢的“不稳定测试（flaky test）”，而更多地做快速的一致性测试。

解决这个问题的更好方法是让缓慢的测试变快，让不稳定的测试变稳定。可靠性和速度，何乐而不为呢？

Nat Pryce和Josh Chisholm各自独立地研究出了让全栈测试在亚秒级完成的方法，他们移除了所有的I/O，并让所有的东西都在进程内运行。以前，我们只知道域级测试是这样做的。例如，如果你编写一个有DOM UI（如React）的Node.js应用，你可以使用Cucumber-Electron在一个Node.js进程中运行客户端和服务器，根本没有I/O。每秒执行成百上千的全栈测试。如果速度那么快，就没有人介意冰淇淋甜筒测试了。

降低脆弱性、提升可维护性的方法也变得越来越流行。Screenplay是其中的一种方式，感谢Antony Marcano、Andy Palmer、John Ferguson Smart和Jan Molak。

InfoQ：社区内有人使用Cucumber和BDD之外的工具实现同样的目标吗？

Hellesøy：那取决于目标是什么。老实说，大多数使用Cucumber的人都不是把它用于BDD。他们把它用于测试，后来编写测试。如果你的工作流程是那样的，那么Cucumber与其他的测试工具相比并没有什么明显的优势。除用户外，领域专家或产品经理会使用它阅读Gherkin文档，通常，我会建议使用一种典型的xUnit工具来代替（JUnit、RSpec、NUnit、Mocha等）。

我一般都是混着用：如果是希望从非技术干系人那里获得反馈，我就会使用Cucumber；如果是希望从技术干系人那里获得与业务需求没有直接关系的反馈，我就会使用xUnit。

Cucumber非常适合验证假设、发现不确定性、对要构建的东西建立一个共同的理解。有几种替代的方案和Cucumber有相同的目标，但远不及你能找到的传统测试工具的替代方案多。我不不确定其中哪一种最受欢迎，但是，Concordion、Robot框架、JBehave和Fitnesse与Cucumber最为相似。

InfoQ：Cucumber和BDD未来会怎样发展？

Hellesøy：Cucumber已经成长为一个有许多实现的大型生态系统。用户数庞大（几十万到几百万），而经常贡献者的数量相对较少（约10几个），这就是说，我们要不断地减少工作量或者扩大团队规模。一个共享的二进制文件可能可以减少部分工作量，但现在这样说还太早。

分布式执行和并行执行是人们要求比较多的特性。对于这一点，有些变通方案和第三方工具，但是Cucumber内没有提供原生的特性。我们希望加入这个特性。我们也希望改进报告工具。

至于BDD实践，我认为，作为一个社区，我们能做的最重要的事情是坚持对用户进行BDD培训。有些书可供阅读，但我认为，我们需要人们更容易获得、更易于理解的教育资料。目前，我们花了大量的精力教人们实例映射——我们已经看到有团队从中获得了很大的好处，甚至都没有使用Cucumber。

我们还需要把用于快速测试的模式和技术写成文档，尤其是在分布式架构中，如微服务和无服务器架构。像端口、适配器和契约测试等模式都不是主流，我认为，它们可以解决在那些环境中使用BDD时面临的其中许多问题。

InfoQ：您和您的同事已经围绕Cucumber创立了一家公司。从那个角度讲，您对未来有什么看法？

Hellesøy：我们在2014年成立了Cucumber有限公司，从那时开始，我们的主要收入流就一直是培训。这些年来，我们构建了一个Cucumber协作工具，名为Cucumber Pro。这个工具可以发布Gherkin文档及其结果，让人们可以在那些文档上开展协作。当我们意识到客户需要的是不同的东西时，我们扔掉了第一个，从头开始。

早期，我们决定成立一家自力更生的公司，从第一天开始就没有任何外部投资。如今，我们有10名员工，有大约10个合伙人帮助我们在全世界开展培训。

我们没有办公室，因此，我们每天通过视频会议见面。在我们中间，从事Cucumber Pro开发的使用远程群体编程，而其他人则访问客户提供培训。我们每两个月见一次面，制定策略并聚会。

没有外部投资者让我们对于优先事项有更好的控制，让我们更容易创立我们希望创立的公司，但是，那也意味着，如果我们雇用10几名开发人员，我们就无法尽快发展我们的商业产品。这很难，但很有趣！

查看英文原文：BDD Tool Cucumber is 10 Years Old: Q&A with its Founder Aslak Hellesøy