在没有收件箱干扰的情况下测试 Node.js 定期汇总邮件

当预览环境将汇总信息发送到同一个共享收件箱时，定期汇总邮件（Digest emails）会引发问题。

你会搞不清哪条消息属于哪个构建版本。你无法判断退订链接是否是最新的。你可能会忽略模板是否与用户细分（segment）匹配。

我将定期汇总邮件的 QA 视为一条产品路径。JavaScript 应用调度事件，Node.js 渲染内容，收件箱检查则确认最终体验。

许多团队会犯以下错误：

• 他们在多次运行中重复使用同一个收件箱。周一的汇总邮件和周二的构建版本混在一起。
• 他们依赖带有临时邮件字符串的旧 Staging 数据。
• 他们将渲染后的 HTML 视为终点。即使实时数据错误，HTML 快照也能通过测试。

一个好的测试必须能够证明读者收到的真实消息。请改用这个简单的循环：

• 测试触发器为特定的用户细分创建一个汇总邮件。
• Node.js 使用真实的 Staging 数据生成汇总邮件。
• 测试为该次特定运行使用一个隔离的收件箱。
• 运行器打开汇总邮件并检查摘要区块。
• 测试验证链接是否指向正确的域名和营销活动参数（campaign parameters）。

将电子邮件地址视为可丢弃的基础设施。为每个场景创建一个临时邮件账户。这可以防止一个不稳定的任务（flaky job）破坏下一个任务。

一个有用的汇总邮件测试会检查以下细节：

• 定时任务为正确的细分群体排队了一个汇总邮件。
• 主题行显示正确的日期。
• 预览文本（preheader）与当前的特性开关（feature flags）相匹配。
• 链接使用正确的域名、UTM 标签和语言区域（locale）。
• 退订链接跳转到正确的环境。
• 同一个用户不会出现重复的汇总邮件。

停止在 CI、预览构建和手动 QA 之间共享同一个收件箱。起初这看起来很高效，但随后会产生误报（false positives）。

隔离可以加快修复速度。当汇总邮件失败时，你会知道问题出在调度器、渲染器还是消息本身。

Source: https://dev.to/ryanlee91/how-i-test-nodejs-digest-emails-without-shared-inbox-noise-54fh