在需求的开发过程中，最令人困惑的地方就在于需求模糊。需求是解决业务的问题，那么验收的方式应该是由业务方提出，但是往往业务方(可能是产品经理，也可能是直接是客户)只能给出比较模糊的一个验收标准，而程序却是需要非常明确的输入输出的条件的。
这中间的鸿沟是否能够通过一些手段来减轻(个人认为是无法完全消除的，信息在传递的过程中一定会经历一些损耗)，Cucumber 就是一个为此提出的实例化需求框架。从这个框架提供的思路在于让业务方提供明确的场景，让开发为场景提供数据进行模拟，通过Cucumber进行衔接。
Cucumber 本身的定位是一个 BDD(Behavior Driven Development,行为驱动开发) 的测试框架。BDD是一种敏捷软件开发的技术，它鼓励软件项目中的开发者、QA和非技术人员或商业参与者之间的协作。BDD侧重设计,要求大家在设计测试用例的时候对系统进行定义，使用通用的语言将系统的行为描述出来，将系统设计和测试用例结合起来，从而以此为驱动进行开发工作。
假设我需要投票系统，在做出一系列分析和设计之后，得到这样的需求：
##### 目标
为方便收集大家的反馈和活动构建一个`投票系统`
##### 投票功能设计
【使用场景】
1. 每一人`每轮`只能投出指定的有限的`票数`
2. 可以根据配置展示`每轮`的`投票结果`
- 总是展示`投票结果`
- `每轮`投票完成之后才展示`投票结果`
【管理场景】
... ...
【编辑场景】
... ...
在设计这个功能的时候，我们已经需要开始注意需求中使用的词汇了，否则大家交流的功能的时候，可能就会发生歧义。在定义完这些需求之后，我们需要将这些需求沉淀到项目中。
Cucumber 使用了一个Gherkin的标记语言，有点像是YAML，的，Cucumber 解释器可以通过理解使用Gherkin编写的*.feature文件来执行对应的测试文件。采用Gherkin有两个目的：
- 实例化需求，澄清验收标准
- 自动化测试。
通过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的这个套路，把这整个套路整理一遍，这一切看起来还挺美好的：
- 需求分析和定义，整理需求
- 设计产品的功能，制定验收标准。
- 编写
Gherkin文件，将需求实例化到文档中，同时编写业务用例。 - 构建测试代码，测试业务代码。
- 长期持续集成/持续测试
但是实际操作中，会遇到的问题还是挺多的：
- 设计产品功能的时候，就能定义好
通用语言 - 验收标准具备可测量性
- 业务用例考虑能否充分。从何而来，是否有足够的场景支撑
- 业务代码本身是否具备可测试性
- 基础设施是否能长期支撑 CI/CD
- 团队是否能接受这种开发的模式
... ...
当然我们不能指望一个工具可以解决需求模糊的问题，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>
