在需求的开发过程中，最令人困惑的地方就在于需求模糊。需求是解决业务的问题，那么验收的方式应该是由业务方提出，但是往往业务方(可能是产品经理，也可能是直接是客户)只能给出比较模糊的一个验收标准，而程序却是需要非常明确的输入输出的条件的。

这中间的鸿沟是否能够通过一些手段来减轻(个人认为是无法完全消除的，信息在传递的过程中一定会经历一些损耗)，Cucumber 就是一个为此提出的实例化需求框架。从这个框架提供的思路在于让业务方提供明确的场景，让开发为场景提供数据进行模拟，通过Cucumber进行衔接。

Cucumber 本身的定位是一个 BDD(Behavior Driven Development,行为驱动开发) 的测试框架。BDD是一种敏捷软件开发的技术，它鼓励软件项目中的开发者、QA和非技术人员或商业参与者之间的协作。BDD侧重设计,要求大家在设计测试用例的时候对系统进行定义，使用通用的语言将系统的行为描述出来，将系统设计和测试用例结合起来，从而以此为驱动进行开发工作。

假设我需要投票系统，在做出一系列分析和设计之后，得到这样的需求：

##### 目标

为方便收集大家的反馈和活动构建一个`投票系统`

##### 投票功能设计

【使用场景】

1. 每一人`每轮`只能投出指定的有限的`票数`
2. 可以根据配置展示`每轮`的`投票结果`
   - 总是展示`投票结果`
   - `每轮`投票完成之后才展示`投票结果`

【管理场景】

... ...

【编辑场景】

... ...

在设计这个功能的时候，我们已经需要开始注意需求中使用的词汇了，否则大家交流的功能的时候，可能就会发生歧义。在定义完这些需求之后，我们需要将这些需求沉淀到项目中。

Cucumber 使用了一个Gherkin的标记语言，有点像是YAML，的，Cucumber 解释器可以通过理解使用Gherkin编写的*.feature文件来执行对应的测试文件。采用Gherkin有两个目的：

1. 实例化需求，澄清验收标准
2. 自动化测试。

通过Gherkin形成业务方能阅读理解的文件形式。这里我们挑中投票使用场景中的一个功能编写一个例子：

@投票功能
Feature: 【投票-使用场景】投票功能

  每一人`每轮`只能投出指定的有限的`票数`

  Scenario Outline: 每位`参与人``每轮`只能投出指定的有限的`票数`
    Given 发起一轮投票，设置`选项`
      | A | B | C |
    Given <recipientNumber>个`参与人`，每人投票<voteTimes>次
    When 所有`参与人`完成投票
    Then `投票结果`中总票数应该为<totalVotes>票

    Examples: 正常情况的用例
      | recipientNumber | voteTimes | totalVotes |
      | 2               | 1         | 2          |
      | 3               | 2         | 6          |

    Examples: 异常情况下的用例
      | recipientNumber | voteTimes | totalVotes |
      | 4               | 2         | 4          |

这里将Feature中定义出这个功能。接着在下面写出这个功能对应的场景Scenario。然后通过Given、When、Then等关键字定义这个场景中的步骤。然后在下方通过Example关键字将用例中关键的信息用表格的形式列出。

通过以上这些关键字加上对场景的描述，最终将需求落到的项目中，假如希望语言阅读更加连贯，这些关键字也有对应的中文关键字支持编写。

Gherkin的语法在网站上有比较详细的描述，关于它的语法可以参考：https://cucumber.io/docs/gherkin/reference/

编写这样的一个feature文件之后可以将它放在test目录的resources文件夹下：

.
├── java
│   └── io.github.whthomas.demo.cucumber
└── resources
    ├── cucumber-reporting.properties
    ├── cucumber.properties
    └── io.github.whthomas.demo.cucumber.vote
        ├── displayVoteResultScenario.feature
        └── useVoteScenario.feature

在没有 Java 代码的情况之下，编写一个RunCucumberTest类：

import io.cucumber.junit.Cucumber;
import io.cucumber.junit.CucumberOptions;
import org.junit.runner.RunWith;

@RunWith(Cucumber.class)
@CucumberOptions(plugin = {"pretty"})
public class RunCucumberTest {
}

运行RunCucumberTest，会给出如下提示，告知我们要怎么做：

建立和 feature 文件同级的test目录的src目录，将这些提示代码拷贝到这个同package的类中(新建 Java 类，名称可以根据需求和场景来取名)，Java 类中就是一些驱动测试场景的代码了。Cucumber会根据Feature文件中的描述的步骤，逐一执行Java中的代码，并将参数传递进去。

这个时候目录结构应该这些构建：

.
├── java
│   └── io.github.whthomas.demo.cucumber
│       ├── RunCucumberTest.java
│       └── vote
│          ├── DisplayVoteResultScenario.java
│          └── UseVoteScenario.java
└── resources
    ├── cucumber-reporting.properties
    ├── cucumber.properties
    └── io.github.whthomas.demo.cucumber
        └── vote
            ├── displayVoteResultScenario.feature
            └── useVoteScenario.feature

每次去执行RunCucumberTest的时候，就会在 IDE 中像展示文档一样，将需求和用例结合展示出来。

Cucumber也提供了一些第三方插件，将结果通过报告展示出来：

但是我觉得展示的效果，还是太偏向于是给技术人员阅读的了。如果我们力求一份好的文档能让业务人员也能很好理解，可能还是需要利用它产生的json文件自己来开发一下才行。

现在在回过头来看BDD的这个套路，把这整个套路整理一遍，这一切看起来还挺美好的：

1. 需求分析和定义，整理需求
2. 设计产品的功能，制定验收标准。
3. 编写Gherkin文件，将需求实例化到文档中，同时编写业务用例。
4. 构建测试代码，测试业务代码。
5. 长期持续集成/持续测试

但是实际操作中，会遇到的问题还是挺多的：

1. 设计产品功能的时候，就能定义好通用语言
2. 验收标准具备可测量性
3. 业务用例考虑能否充分。从何而来，是否有足够的场景支撑
4. 业务代码本身是否具备可测试性
5. 基础设施是否能长期支撑 CI/CD
6. 团队是否能接受这种开发的模式

… …

当然我们不能指望一个工具可以解决需求模糊的问题，Cucumber只是去解决这个问题中的一环，团队更加需要的是一套流程、一系列实践和改变的决心。它需要团队成员的通力合作，才可以帮助整个团队更好的理解业务，理解软件，理解这个复杂的客观世界。

文章对应的代码已经放在了GitHub上：https://github.com/whthomas/cucumber-demo

---

附：如何安装Cucumber

如果要使用Cucumber在项目中可以添加如下的依赖：

<dependency>
    <groupId>io.cucumber</groupId>
    <artifactId>cucumber-java</artifactId>
    <version>${cucumber.version}</version>
    <scope>test</scope>
</dependency>
<dependency>
    <groupId>io.cucumber</groupId>
    <artifactId>cucumber-junit</artifactId>
    <version>${cucumber.version}</version>
    <scope>test</scope>
</dependency>

如果是使用JUnit5，可以把第二个依赖包改成是：

<dependency>
    <groupId>io.cucumber</groupId>
    <artifactId>cucumber-junit-platform-engine</artifactId>
    <version>${cucumber.version}</version>
    <scope>test</scope>
</dependency>