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忽略注释行。