提交后测试策略

提交后测试验证 Beam 在实时环境中是否正常运行。这些测试还可以捕获在设计和实施阶段难以预测的错误。

即使提交后测试在代码合并到仓库后运行，但测试必须可靠地通过。Jenkins 对 master 分支的 HEAD 执行提交后测试。如果提交后测试失败，则 HEAD 构建存在问题。此外，提交后测试运行起来很耗时，而且通常很难排查测试失败问题。

策略

为了确保 Beam 的提交后测试可靠且健康，Beam 社区遵循以下提交后测试策略。

• 首先回滚
• 测试失败是一个严重错误
• 不稳定的测试是一个严重错误
• 不稳定的测试必须修复或删除
• 提交后失败的修复应包含相应的新的提交前测试

提交后测试失败场景

当提交后测试失败时，请按照针对您情况提供的步骤操作。

我发现了测试失败

1. 创建一个 GitHub 问题 并将其分配给自己。

• 组件：测试，其他相关内容
• 标签：提交前
• 在描述中引用此页面。

1. 对失败进行高级排查。
2. 将问题分配给相关人员.

我被分配了一个测试失败的问题

1. 回滚导致错误的变更.
2. 如果您确定回滚将花费超过 8 小时的时间，请在回滚或创建修复程序时 暂时禁用测试。

注意：回滚始终是首要行动方案。如果修复很简单，请在执行回滚时打开包含建议修复程序的拉取请求。

我的变更由于测试失败而被回滚

回滚后有时间进行更深入的调查。首先查看 GitHub 问题，了解回滚的背景信息。以下所有场景都很常见。

• 您的变更包含错误。
• 您的变更暴露了现有错误。
• 您的变更暴露了错误的测试（不稳定、过度指定等）。

这些都是回滚的正当理由。保持清晰的信号是最高优先级。

高级步骤相同

1. 创建修复程序并重新运行提交后测试。
2. 实施新的提交前测试，以便在将来将代码合并到仓库之前捕获类似的失败。
3. 打开包含修复程序和新的提交前测试的新 PR。

如果错误不在您的代码中，请了解如何“创建修复程序”。

1. 为现有错误提交工单，如果它尚未存在。请记住，不稳定的测试是一个严重错误。其他错误的测试类似：它们可能会因任意原因而失败，与所测试内容无关，从而导致我们的信号不可靠。
2. 标记有问题的测试，使其被跳过，并提供指向 GitHub 问题的链接。

有用链接

• 编写测试的最佳实践

参考

1. 保持提交后测试变绿 邮件列表建议线程。