本节书摘来自异步社区《Cucumber：行为驱动开发指南》一书中的第1章，第1.4节，作者：【英】Matt Wynne , 【挪】Aslak Hellesy著，更多章节内容可以访问云栖社区“异步社区”公众号查看

1.4　Cucumber如何工作

在深入本书的核心内容之前，我们先简要介绍一个典型的Cucumber测试集，以帮助你了解Cucumber是如何工作的。

Cucumber是一个命令行工具。运行时它会从普通语言编写的称为特性（feature）的文本文件中读取你的规格说明，解析需要测试的场景（scenario），然后针对你的系统运行这些场景以达到测试的目的。每个场景由一系列步骤（step）组成，Cucumber会一步步执行这些步骤。为了让Cucumber能理解特性文件，这些文件必须遵循一些基本的语法规则，这套语法规则就叫Gherkin。

除了特性文件，你还要为Cucumber提供一组步骤定义（step definition），它们是匹配特性文件中每个步骤的Ruby代码，业务语言描述的步骤行为都由这些步骤定义执行。在一个成熟的测试集中，这些步骤定义自身可能只包含一两行Ruby代码，具体的工作都代理给支持代码（support code）库来完成，应用程序领域特定的支持代码库知道如何执行系统的常见任务。通常这会涉及使用一个自动化库（automation library），例如浏览器自动化库Capybara，来与待测系统进行交互。

整个层次结构从特性往下至自动化库，具体如图1-1所示。




图1-1 Cucumber测试栈

如果步骤定义中的Ruby代码执行无误，Cucumber就依次执行场景中的下一个步骤。如果场景的所有步骤执行都没有错误，那么Cucumber就将该场景标记为通过。但是，如果场景中任何一个步骤失败了，Cucumber就会将该场景标记为失败并转而执行下一个场景。运行场景的时候，Cucumber打印出相应的结果，告诉你它在干什么，以及它没干什么。

简单来说 Cucumber 就是这么一回事。但作为一个杰出的自动化验收测试框架，Cucumber 还有很多其他优点：你可以使用四十多种语言编写规格说明，可以使用标签（tag）把场景组织和归类，可以轻松集成大批高质量的 Ruby 自动化库，来驱动几乎任何种类的应用程序。随着阅读本书的其他部分，所有上述及更多的内容都将清晰地展现在你面前。