行为驱动开发 - SpecFlow
SpecFlow 是一个开源项目。 源代码托管在 GitHub 上。 SpecFlow 用于存储应用程序中功能(用例、用户案例)的接受标准的功能文件是使用 Gherkin 语法定义的。
Gherkin 格式由 Cucumber 引入，也被其他工具使用。 Gherkin 语言作为 GitHub 上的项目进行维护 − https://github.com/cucumber/gherkin
功能元素和 SpecFlow
Feature 元素的主要特征是 −
feature 元素提供功能文件的标头。 功能元素包括应用程序中相应功能的名称和高级描述。
SpecFlow 为功能元素生成一个单元测试类，类名称源自功能名称。
SpecFlow 根据代表验收标准的场景生成可执行单元测试。
一个功能文件可能包含多个用于描述功能验收测试的场景。
场景有一个名称，并且可以包含多个场景步骤。
SpecFlow 为每个场景生成一个单元测试方法，方法名称源自场景名称。
多场景步骤
场景可以有多个场景步骤。 共有三种类型的步骤定义构成验收测试的前提条件、操作或验证步骤。
不同类型的步骤分别以 Given, When 或 Then 关键字开头，相同类型的后续步骤可以使用 And 和 But 关键字链接。
Gherkin 语法允许这三种类型的步骤的任意组合，但场景通常具有不同的 Given、When 和 Then 语句块。
场景步骤使用文本定义，并且可以具有称为 DataTable 的附加表或称为 DocString 参数的多行文本。
场景步骤是执行任何自定义代码以自动化应用程序的主要方法。
SpecFlow 在单元测试方法内为每个场景步骤生成一个调用。 该调用由 SpecFlow 运行时执行，该运行时将执行与场景步骤匹配的步骤定义。
匹配是在运行时完成的，因此即使尚未实现绑定，也可以编译和执行生成的测试。
您可以在场景步骤中包含表格和多行参数。 这些由步骤定义使用，并作为附加表或字符串参数传递。
标签
标签是可以分配给功能和场景的标记。 为某个要素分配标签相当于为要素文件中的所有场景分配标签。 带有前导 @ 的标签名称表示标签。
如果单元测试框架支持，SpecFlow 会从标签生成类别。
生成的类别名称与标签名称相同，但不带前导@。
您可以使用这些单元测试类别对要执行的测试进行过滤和分组。 例如，您可以使用@important标记关键测试，然后更频繁地执行这些测试。
背景元素
背景语言元素允许为功能文件中的所有场景指定共同的前提条件
文件的后台部分可以包含一个或多个场景步骤，这些步骤在场景的任何其他步骤之前执行。
SpecFlow 从后台元素生成一个方法，该方法从为场景生成的所有单元测试中调用。
场景概要
场景大纲可用于定义数据驱动的验收测试。 场景大纲始终由场景模板规范(使用
如果单元测试框架支持，SpecFlow 会根据场景大纲生成基于行的测试。
否则，它会为场景大纲生成参数化单元测试逻辑方法，并为每个示例集生成单独的单元测试方法。
为了更好的可追溯性，生成的单元测试方法名称源自场景大纲标题和示例的第一个值(示例表的第一列)。
因此，最好选择一个唯一的描述性参数作为示例集中的第一列。
由于 Gherkin 语法确实要求所有示例列在场景大纲中都具有匹配的占位符，因此您甚至可以在示例集中引入任意列，用于命名更具可读性的测试。
SpecFlow 在匹配步骤绑定之前将占位符替换作为单独的阶段执行。
因此，步骤绑定中的实现和参数与它们是通过直接场景还是场景大纲执行无关。
这允许您稍后在验收测试中指定更多示例，而无需更改步骤绑定。
注释
您可以通过以 # 开头的行将注释行添加到功能文件的任何位置。 但要小心，因为规范中的注释可能表明验收标准指定错误。 SpecFlow 忽略注释行。
