BDD 与集成测试

是什么

BDD（行为驱动开发）是从用户视角验证系统的方式。和 TDD 关注"这个函数对不对"不同，BDD 关注的是"用户看到的整体行为对不对"。

举个例子：TDD 能证明"计算折扣的函数结果正确"，但不一定能证明"用户下单后，折扣被正确应用到总价、订单状态变为已确认、库存被扣减"这个完整流程。BDD 就是为了覆盖这类跨模块的场景。

工作原理

BDD 在 OpenFlow 中是自动执行的，你不需要额外配置。它的工作流程是：

1. 需求阶段：把行为写下来

在 /openflow-feature 阶段，AI 会把用户可见的行为用 Given / When / Then 格式写入 behavior.md：

• Given（前提）：系统当前处于什么状态
• When（动作）：用户做了什么操作
• Then（结果）：系统应该表现出什么行为

这一步你在阶段一检查 behavior.md 时已经确认过了——这些行为描述就是后续验证的依据。

2. 实现阶段：按行为写集成测试

开发计划会根据行为场景生成对应的集成测试任务。AI 在实现代码的同时，会编写测试来覆盖这些行为。

3. 质量门：验证行为是否成立

质量门会检查：behavior.md 中描述的每一个行为场景，是否有对应的证据证明它成立——可能是集成测试通过、命令输出正确、日志符合预期等。

如果关键行为没有证据支持，质量门不会给出通过。

与 TDD 的区别

	TDD	BDD
关注点	单个函数或模块的逻辑是否正确	跨模块的用户可见行为是否正确
触发时机	关键代码节点	所有行为场景
写在什么阶段	开发计划中注入	需求阶段定义，实现阶段验证

简单来说：TDD 保证零件没问题，BDD 保证组装后的整机没问题。两者配合使用，才能既保证局部正确，又保证整体正确。

与其他机制的关系

BDD 直接连接 behavior.md 中的验收标准，并会影响 代码地图 中"行为场景 → 代码"的可追溯映射。