Specflow入门-（2）简单case的实现

我们已经创建好了一个空项目，可以为其加入test case

Specflow中用 .feature 文件包含一个用户故事。使用Gherkin语言规范来描述。

我们可以先创建一个feature文件来了解一下。为了使结构清楚，我们将所有feature文件放置在Features文件夹中。

一个feature文件只能有一个Feature头，用来描述该feature的名称。可以将该feature理解为一个用户故事，或者软件的一个功能描述。当前文件中的 ArithmeticFeature表示了该feature要描述的功能为四则运算。下面三行斜体字是对该feature的详细描述。

紧接着，出行一行Scenario (目前忽略@mytag)，表示该功能下的一个场景。此例中为，四则运算功能下的两数相加运算（Add two numbers)。一个Feature中可以有多个Scenario。我们可以在当前的Scenario下添加新的场景：Subtract two numbers，表示两数相减的场景。

注意到，每个Scenario下都有几行自然语言描述的语句，这些句子就叫做Step(步骤)。是Specflow中最小的可执行单元。

其中第一个蓝色的单词表示该步骤的行为：

1. Given 表示准备好的状态或条件，
2. When 表示触发系统（软件）的一个动作，
3. Then 表示要期待的结果，
4. And 与其上一步的行为一样，比如此处的And就等同于Given。

这些Step的作用就是将自然语言的Action链接到可执行的C#代码。

接下来，我们将创建StepDefinition，就是Step的链接代码。

注意到，当创建StepDefinition后，feature文件中的Step的颜色变为了黑色。在Step上面F12可以跳转到该Step对应的代码。也就是说，当Specflow在执行该Step的时候，实际上是在执行该Step链接的代码。当然，如果没有为其创建StepDefinition，该Step也无法执行。注意16行，我们没有为该Step创建对应的代码，其颜色未变黑。

至此，大家应该对Specflow有了直观的感受，这些Feature以及Scenario就是对软件或产品的功能性描述，而Specflow会将这些描述链接到可执行的代码，这样就将静态的业务或功能性描述变成了可以执行并验证的测试用例。每当需要验证产品的某个功能是否正常时，我就去运行一个Feature下的所有Scenario，看看这个功能是否还和我的描述一致，以达到测试并保证产品还与之前需求的描述一致的目的。