BDD之Gherkin(小黄瓜)语法

Gherkin 介绍

Gherkin是一种DSL（领域特定语言），它使得人们不具备技术背景的用户也能轻易读懂软件的行为描述。它的语法结构简单明晰，以关键字开始，可以被非程序员理解，是编写Cucumber测试的标准语言。

Gherkin旨在以自然语言编写，它鼓励的是行为驱动的开发（BDD）。
Gherkin的目的是让非技术人员能够理解软件的逻辑并参与自动化测试的编写。正确使用Gherkin能够提高团队成员之间的沟通，并帮助确保软件开发根据真实世界的业务需求进行

Gherkin 的写法

Gherkin 使用一组关键字来为可执行规范提供结构和含义
每个关键词可以使用多种语言（比如英文，中文等）
大多数行是以关键字开头
可以使用空格和制表符进行缩进，建议的缩进级别是两个空格
示例：

Feature: Guess the word

  # The first example has two steps
  Scenario: Maker starts a game
    When the Maker starts a game
    Then the Maker waits for a Breaker to join

每个步骤的关键字之后的部分与步骤定义代码相匹配

Gherkin 的关键词

主要关键词：

Feature
Rule
Example
Given, When, Then,And , But
Background
Scenario Outline (或者Scenario Template)
Examples (或者 Scenarios)

次要关键字：

""" 文档字符串
| 数据表
@ 标签
# 注释
除了Example， Scenario，Background，和Scenario Outline 行下方可以自由格式描述外，不是空行的行必须以关键字开头。

Gherkin的组成部分

以下是Gherkin语言的主要组成部分和它们在测试脚本中的作用：

Feature（特性）：描述了软件的一项或多项功能。通常是一组相关的场景（Scenarios）的集合。Feature从顶部开始，简单说明这组测试的业务目标。

以用户登录功能的Feature 为例， Feature 的描述如下：

  Feature: 登录功能验证
      用户应该能通过输入有效的凭据来登录系统。

Feature: 后面的 登录功能验证 是Feature 的名字
下面一行是对这个Feature的描述

Scenario（场景） ：一个Scenario代表一个具体的例子或一个业务规则的具体实现。它由若干个步骤（Step）组成，描述了一个特定功能的预期行为。

 Scenario: 登录成功
      Given 用户在登录页
      When 用户输入正确的用户名和密码
      And 用户点击登录按钮
      Then 用户应被重定向到主页

Scenario: 后面的是Scenario 的名字，下面的Given, When等是步骤。

Given, When, Then, And, But（假定，当，那么，而且，但是） ：这些是Gherkin的步骤关键字。每一个测试步骤都以这些关键字之一开始。
- Given：设置场景的背景。通常是关于某一特定状态的描述。
- When：描述一个动作或事件。这是触发测试场景的步骤。
- Then：描述期望的结果。
- And, But：用来结合多个Given、When或Then步骤，避免关键字的重复。
Background（背景） ：在多个场景中共享相同的Given步骤时使用。Background部分在Feature中的每个Scenario执行前都会先执行。

   Background: 用户已经在登录页
      Given 用户已导航到登录页面

Scenario Outline（场景大纲）和 Examples（例子） ：当想要用多种数据运行相同的场景时，Scenario Outline用来定义一个参数化的Scenario。后面跟着的Examples提供了具体的值。

  Scenario Outline: 多个用户登录验证
      Given "<user>"在登录页
      When "<user>"输入有效的凭证
      Then "<user>"应该能成功登录
    
    Examples:
      | user      |
      | Alice     |
      | Bob       |

Tags（标签）：可以被附加到Feature或Scenario上，允许组织和选择性地运行测试。

Tag 在 Gherkin 中用于标记场景和功能。它们以 “@” 符号开头，并可以在特定的场景或功能上添加。下面是 Tag 的一些用途和示例：

场景标签: Tag 可以用于标记场景，以便对它们进行组织和过滤。例如，可以使用 “@smoke” 标签来标记仅运行快速测试的场景。

示例:

@smoke
场景: 用户登录
  当用户输入有效的用户名和密码
  那么用户应该成功登录系统

功能标签: Tag 可以用于标记整个功能，以便在运行测试时对其进行过滤。例如，可以使用 “@login” 标签来标记与登录相关的所有场景。

示例:

功能: 用户管理

  @login
  场景: 用户登录
    当用户输入有效的用户名和密码
    那么用户应该成功登录系统

  场景: 用户注销
    当用户点击注销按钮
    那么用户应该成功注销系统

多个标签: Tag 可以在同一个场景或功能中多次使用。这可以用于更细粒度地过滤测试。

示例:

@smoke @login
场景: 用户登录
  当用户输入有效的用户名和密码
  那么用户应该成功登录系统

通过使用 Tag，可以更好地组织和过滤您的 Gherkin 场景和功能，能够更方便地运行所需的测试。

Comments（注释）：在行首加上#来进行注释，注释不会被解析器执行。

  # 这里的步骤用于测试登录

允许在任意位置的新行开始处添加注释。以零个或多个空格开头，后接井号（#）和文本。
不支持块注释

关键字详细使用介绍

1. Feature

用于软件功能的高层级的描述，也可以用来对相关的测试场景（Scenarios）进行分组
Feature 一般是Gherkin文档的第一个主关键词，后面接分号 :, 分号后就是功能的简单描述
一个 .feature 文件只能有一个 Feature 关键字
Feature 的下面可以添加自由输入的文本描述，这些描述在运行的时候会被Cucumber忽略，但是在报表中是可以看到的（它们包含在官方 HTML 格式化程序等报告工具中）。
Feature的名称和可选描述对 Cucumber 没有特殊含义。它们的目的是提供一个记录功能重要方面的地方，例如简要说明和业务规则列表。
在有自由输入的描述的规格中，当遇到Background, Rule, Example 或者 Scenario Outline关键字的时候，则认为自由输入的描述结束。
在Feature的上方可以定义标签用来对功能进行分组，可以跨文件和目录结构。

2. 描述（注释）

自由输入的描述可以位于Example/Scenario, Background, Scenario Outline 和Rule下面。只要不以关键字开头，可以随意输入。
描述支持Markdown 格式。

3. Rule

Rule关键字从 Gherkin v6 版本才开始出现的。
Rule关键字代表一个业务规则需要被实现，提供了一个feature 的额外信息。一个Rule可以用于将统一某一业务规则的场景组合在一起。
一个 Rule需要包含一个或多个场景用来解释这个特殊的规则。

Gherkin 6.0版本引入了一个新的关键字Rule，这为在Feature和Scenario之间增加了一个额外层次的结构化组织，同时它在进行复杂业务逻辑描述时提供了更好的组织性。

一个Feature通常涵盖一个较大范围的功能，而该功能可能包含多个不同的业务规则。以前只能通过注释或业务语言来描述这些规则，但是现在Rule允许更正式地组织它们，并能够包含其下的一个或多个Scenario或Scenario Outline。

下面是Rule的基础使用方法：

Feature: 用户身份验证

  Rule: 作为一个已注册用户
    Background: 
      Given 用户已经在身份验证页面

    Example: 登录成功
      Given 用户输入了有效的用户名和密码
      When 用户点击登录按钮
      Then 用户被重定向至个人主页
      
    Example: 登录失败
      Given 用户输入了无效的用户名和密码
      When 用户点击登录按钮
      Then 显示错误消息 "无效的登录凭证"

  Rule: 作为一位游客（未注册用户）
    Example: 游客尝试登录
      Given 用户输入了无效的用户名和密码
      When 用户点击登录按钮
      Then 显示错误消息 "无效的登录凭证"
      
    Example: 游客尝试注册
      Given 用户点击注册链接
      When 用户填写必要信息并提交
      Then 用户被重定向至注册成功页面

在上面的例子中，Feature定义的是用户身份验证，下面被分为两个不同的Rule代表了不同的业务逻辑或规则。每个Rule下面都可以定义多个Example（场景或场景大纲），这样既保持了测试脚本的组织性又没有失去Gherkin描述的清晰性。

通过Rule关键词，我们能够具体展示在满足一个业务规则的情况下如何测试系统的不同行为或特征。这让测试更加细粒度地映射到复杂的业务逻辑中，进而促进更准确的行为驱动开发(BDD)。

4. Example

说明业务规则的具体例子，由一系列的steps 组成。

Example 和 Scenario 是同义词
每一个example 建议3-5个步骤，太多的步骤会让作为规格和文档的例子失去表现力。
除了作为规格和文档之外，一个例子也是一个测试。例子是系统的可执行文档。
Example 遵循下面的规范：
描述初始化上下文（Given 步骤）
描述事件（When）
描述期望的结果(Then)

5. 网络

在Gherkin中，Example或Examples关键字用于与Scenario Outline一起使用，为其提供一组参数，使得可以对同一场景执行多次测试，每次使用不同的数据集。这是一种数据驱动测试的形式，通常用于测试相同的过程是否能够处理不同的输入数据并生成预期的结果。

以下是如何在Gherkin中使用Scenario Outline和Examples：

声明一个Scenario Outline，在这个大纲中定义了测试步骤，并使用尖括号< >包含变量。
紧随Scenario Outline，Examples提供了一个或多个数据表，这些表中列出了用于替换Scenario Outline中占位符的具体值。

这是一个简单的示例来说明其用法：

Feature: 用户身份验证

  Scenario Outline: 用户登录
    Given 用户已经在登录页面
    When 用户输入用户名 "<username>" 和密码 "<password>"
    Then 系统应该显示 "<outcome>"

  Examples:
    | username    | password    | outcome               |
    | correctUser | correctPass | 登录成功              |
    | correctUser | wrongPass   | 显示密码错误          |
    | wrongUser   | correctPass | 显示用户名不存在      |

在上面的例子中，Scenario Outline描述了一个用户尝试登录的场景，并且有3个占位符：<username>、<password>和<outcome>。Examples表则提供了具体的数据：

第一行数据用correctUser作为用户名，correctPass作为密码，预期结果是登录成功。
第二行数据使用了相同的用户名但不同的密码，预期结果为错误消息显示密码错误。
第三行数据使用了错误的用户名和正确的密码，预期结果为错误消息显示用户名不存在。

每当执行这个特性文件时，Scenario Outline会使用表中的每一行数据运行一次，这样就能够确保每个数据集都能够得到测试。这种方式让我们能够高效地重复测试场景，而不需要在特性文件中重复相同的步骤。

6. Steps 步骤

步骤以Given, When, Then, And, 或 But 开头。
Given用于描述系统的初始上下文，就是发生在过去的事情。
Cucumber 按照编写的顺序一次执行场景中的每个步骤。当 Cucumber 尝试执行步骤时，它会查找要执行的匹配步骤定义。

查找步骤定义时不考虑关键字。这意味着不能拥有Given、When、Then、And或But步骤与另一个步骤具有相同的文本。

也就是说下面的两个步骤是重复的：


Given 已经登录系统
Then 已经登录系统

这个限制有个好处就是强迫你使用更清晰的语言进行描述。

参考

https://cucumber.io/docs/gherkin/reference/