在测试邮件变更流程时避免链接混淆
修改账户邮箱看起来微不足道，但却是 QA 团队的一个常见陷阱。一名测试人员更新了地址，另一人却抢先打开了邮件。现在团队开始争论究竟是 React 页面坏了，还是链接属于错误的账户。
当你将收件箱视为共享工具而非功能的一部分时，这种混乱就会发生。
邮件变更流程非常脆弱。它们会修改活跃账户，涉及已认证用户和待处理状态。
常见问题包括：
- 邮件进入了没有明确归属者的共享收件箱。
- 链接有效，但 UI 显示的是旧数据。
- 后端已更新，但前端缓存仍是过时的。
- 测试人员点击了属于其他测试人员的链接。
要解决这个问题，请为每一次测试运行使用一个一次性邮箱（burner email）。不要使用单一的 staging 别名。
请遵循以下步骤：
- 通过应用创建一个测试用户。
- 在 React 设置中请求更改邮箱。
- 通过真实的后端发送邮件。
- 将邮件路由到一个单次使用的收件箱。
- 打开链接并验证设置页面是否显示了新地址。
隔离可以确保归属明确。你不再需要通过 Slack 发送乱七八糟的笔记来记录使用了哪个收件箱。
React 应用的一条准则：务必在重新读取数据后检查屏幕。不要信任乐观的客户端状态（optimistic client state）。mutation 可能返回成功，但页面刷新可能会带回旧值。这种情况发生的频率比人们承认的要高。
你的端到端（E2E）测试必须验证：
- 邮件发送到了新的待处理地址。
- 链接指向正确的 host。
- 链接更新了账户记录。
- 重新获取数据（refetch）后，旧地址消失。
- 重复使用链接时能安全地失败。
前端断言（assertions）是最重要的部分。如果用户看到的地址是错误的，那么后端日志显示“成功”也毫无意义。如果你的缓存或 store 是过时的，那么该功能就是损坏的。
可追溯性也很有帮助。在日志和邮件元数据中使用 correlation ID。这可以将请求、投递和确认环节连接起来。
需要权衡的因素：
- 收件箱轮询（polling）比 mocks 慢。
- 临时地址只能存放非生产环境数据。
- 预览环境需要清理规则。
不要跳过这一步。邮件流程往往在系统之间的缝隙中崩溃，而那正是 mocks 最薄弱的地方。