SpecFlow含等待状态多系统交互：单场景多When/Then还是多场景共享上下文？

核心判断原则 #

先明确两个方向的适用场景，你可以对照需求选择：

• 如果等待状态是完整业务闭环里的中间环节，整个流程是连贯的单一业务功能，优先用单场景。
• 如果等待状态前后是两个独立的业务触发点，或者需要单独验证等待阶段的系统特殊行为，再考虑拆成多场景共享上下文。

结合你的合同创建流程分析 #

你的例子是典型的连贯业务链条：销售事件触发合同创建 → 系统A请求客户信息（进入等待）→ 收到信息后完成合同发布。这整个是一个完整的业务功能，并非两个独立动作，因此优先选择单场景实现。

单场景的优势 #

1. 贴合业务视角：一个场景就能清晰描述从销售到合同发布的端到端流程，非技术人员（如产品、运营）也能快速理解测试逻辑。
2. 降低维护成本：无需额外处理场景间的状态传递（比如存储合同ID、请求状态），测试代码更简洁，减少出错概率。
3. 逻辑连贯性强：所有步骤按业务顺序执行，能直接验证整个流程的衔接是否正常，不会割裂完整的业务逻辑。

单场景示例：

Scenario: 销售完成后完整创建并发布合同
    When 系统A收到包含合同创建详情的销售事件
    Then 系统A启动新合同的创建流程
    And 系统A向System B发起客户信息请求（进入等待状态）
    When 系统A收到System B返回的客户信息
    Then 系统A打包合同相关信息并发布至其他系统

什么时候该拆分场景？ #

只有当你需要单独验证等待状态下的特殊行为时，才考虑拆分，比如：

• 验证等待超时后系统的重试/告警机制
• 验证等待期间收到重复请求的处理逻辑
• 模拟间隔较长时间（如几小时）才收到客户信息的场景

这种情况下，可以拆成两个场景，借助SpecFlow的ScenarioContext或自定义共享上下文类传递中间状态（如合同ID）：

Scenario: 销售事件触发合同创建并进入等待状态
    When 系统A收到包含合同创建详情的销售事件
    Then 系统A启动新合同的创建流程
    And 系统A向System B发起客户信息请求（进入等待状态）
    And 系统A中该合同的状态为「等待客户信息」

Scenario: 收到客户信息后完成合同发布
    Given 系统A存在状态为「等待客户信息」的合同（ID: <ContractId>）
    When 系统A收到System B返回的对应客户信息
    Then 系统A打包合同相关信息并发布至其他系统
    And 系统A中该合同的状态为「已完成」

总结 #

• 优先用单场景覆盖完整业务流程，除非需要单独验证等待阶段的独立行为。
• 单场景中可以用多个When步骤模拟不同触发事件，这符合Gherkin语法规范，只要每个When对应明确的业务动作即可。
• 如果拆分场景，务必保证上下文传递的可靠性，避免因状态不一致导致测试失败。

内容的提问来源于stack exchange，提问作者fabours