在 React 中测试邮箱变更流程，避免链接混淆
修改账户邮箱看起来是一件小事，但实际上它是测试错误的主要来源。
测试人员经常会混淆确认链接。一个人更新了地址，而另一个人先打开了邮件。这会造成混乱。团队开始争论是 React 页面坏了，还是链接属于错误的用户。
这个问题之所以发生，是因为团队将收件箱视为一种共享工具。你必须将收件箱视为功能契约的一部分。
邮箱变更流程非常脆弱。它们会改变一个活跃的账户。用户已经登录。待处理邮箱状态与已确认邮箱状态之间往往存在竞态条件。
常见问题包括：
- 确认邮件到达共享收件箱，无法进行追踪。
- 即使链接已确认新请求，UI 仍显示旧数据。
- 后端已更新，但前端缓存仍显示旧地址。
- 一名测试人员点击了本属于另一人的链接。
共享邮箱会让寻找 Bug 原因变得困难。请为每次测试运行使用唯一的临时（burner）邮箱地址，而不是使用单一的 staging 别名。
请遵循以下清晰的步骤：
- 创建一个测试用户。
- 在 React 设置界面请求变更邮箱。
- 通过真实的后端路径发送邮件。
- 将邮件路由到仅属于本次测试的收件箱。
- 打开链接并验证设置界面是否已使用新地址刷新。
这能保持权属清晰。你会清楚地知道哪个链接来自哪个用户。
对于 React 应用，请遵循一条额外的规则：仅在重新读取数据后才对页面进行断言。不要信任乐观客户端状态（optimistic client state）。即使 mutation 返回了成功，如果后端没有完成变更，页面重新加载后仍可能带回旧值。
一个良好的端到端测试必须验证以下几点：
- 邮件发送到了待处理地址，而不是旧地址。
- 链接指向正确的环境主机。
- 链接更新了账户记录。
- 重新获取数据（refetch）后，旧地址消失。
- 重复使用同一个链接时能安全失败。
如果你的 React query 缓存或客户端存储（client store）已过期，功能看起来就像坏了一样。客户只关心设置界面显示的是否是真实情况。
你还应该为每个请求添加一个关联 ID（correlation ID）。这有助于你追踪从用户发起请求、邮件投递到最终确认的整个过程。
隔离的收件箱不能取代单元测试。使用单元测试进行表单验证和 API 错误测试。使用收件箱流程来证明真实的客户路径在所有系统中都能正常工作。
在发布账户设置的变更之前，请检查以下项目：
- 从真实的 React UI 请求变更。
- 确认邮件进入了特定于本次运行的收件箱。
- 验证重新获取数据后显示了新地址。
- 确保旧链接无法被重复使用。
- 确认审计日志显示了是谁发起的变更。
这可以防止那些在隔离环境下看起来一切正常，但在现实世界中却会失败的 Bug。