行为驱动设计，从解决编程问题，到解决各种问题

why

程序总会出 bug。

做过编程的人非常清楚，不管是否有写“好代码”的意识，都会写出无数 bug。

测试人员不仅会提出功能本身的 bug，还会提出功能优化点为 bug，堆积在上线前的无数 bug 让人苦不堪言。

如果能在开发前、开发中、自验证阶段能提早发现 bug，在转测后就会更加轻松。编程可能就会从“痛苦的维生打工”转换“有挑战兴趣的做出好东西”的事情，回归对编程最开始的热情。

为了提升代码质量，偶然间了解到整洁架构，然后领域驱动设计 DDD，然后测试驱动设计，但一直停留在探索阶段。

直到看到一句话“自己无法发现问题，是因为从开发的视角去找问题。而从用户使用的视角去使用，就能发现更多问题。测试人员的测试过程本身也是从用户使用的视角去发现问题的”，再了解到行为驱动设计 BDD，让我找到了对提升质量可落地的方案。

BDD 从用户视角审视每个业务场景，细化场景中的步骤，识别具体细节、限制。这一套流程下来，让开发、自验证变得更加清晰具体，对业务更加熟悉，知道自己要做什么。

具体，是消除恐惧的唯一方式。

我尝试把各种编程外复杂的问题，使用 BDD 的 Gherkin 语法形式来表述，各种错综关联的问题都开始井井有条。

列出的关键步骤提醒了我们解决问题先后要做的事情，帮助我们聚焦当前步骤。每步骤细节的完善让我们对整个方案的可行性有了有效判断。避免做着做着才发现不可行，投入过多沉默成本。

how

行为驱动设计（BDD，Behavior-Driven Development），是一种提升协作的软件开发方法。它将注意力从“测试”转移到“行为”上，确保构建的软件满足业务价值。（from Google Gemini）

BDD 将业务、开发、测试聚集到一起，通过一系列活动实现业务价值的准确实现与验证：

1. 梳理业务场景中的各个步骤，通过示例发现问题。（非常适配少量需求的敏捷开发模式）
2. 业务特性及其场景转换为文档，使用 Gherkin 语法描述，作为业务的验收标准（避免开发完成后扯皮），作为自动化的输入文档。
3. 根据文档的示例来驱动测试自动化。（若暂时不涉及自动化通常可以省略）

Gherkin 语法（from Google Gemini）：

• Feature，功能，描述整个功能模块的名称和目的（用户故事的上下文）。
• Scenario，场景，描述一个具体的、有名字的行为例子。
• Given，鉴于/已知，系统初始状态：建立测试的上下文环境。
• When，当，事件或操作：描述用户或系统执行的行为。
• Then，那么，预期结果：描述系统在操作后应达到的状态或结果。
• And/But，并且/但是，用于连接同一类型（Given/When/Then）的多个步骤，使语句更具可读性。

what

○ 来自 Cucumber 的示例

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

  # The second example has three steps
  Scenario: Breaker joins a game
    Given the Maker has started a game with the word "silky"
    When the Breaker joins the Maker's game
    Then the Breaker must guess a word with 5 characters

# 由 DeepSeek 转为中文
功能: 猜词游戏

  # 第一个例子有两个步骤
  场景: 出题者开始游戏
    当 出题者开始游戏
    那么 出题者等待猜题者加入

  # 第二个例子有三个步骤
  场景: 猜题者加入游戏
    已知/假如 出题者已经开始游戏，谜底是"silky"
    当 猜题者加入出题者的游戏
    那么 猜题者必须猜一个5个字母的单词

○ 个人使用的微调语法

微调语法适用于使用中文的开发者：

• 改用 md 格式来实现 BDD 文档
• 关键词使用英文，和中文描述形成肉眼上的显著区别，方便识别
• 关键词使用小写，减少 shift 反复切换中英文

例如根据下面英语学习目标，对“应用型口语表达”场景进行了相对详细的 BDD 描述，基于这个描述，去寻找合适的学习材料，实现快速英语口语表达。

# feature 英语学习

## 口语

scenario 应用型口语表达
- given 多种场景下
- when 描述场景（场景相关的主体，名词）
- or 准备做某事（场景主体相关的行为，计划句式，请求帮忙句式）
- or 询问相关信息（场景中要做的事情相关的信息：何时、在哪、多少、多上钱等，问句形式）
- then 流畅表达（在不知道相关专用词汇的情况下，能快速转换表达）

参考

• Behaviour-Driven Development | Cucumber