インボックスのノイズを発生させずに Node.js のダイジェストメールをテストする
プレビュー環境が1つの共有メールボックスにサマリーを送信する場合、ダイジェストメールは問題を引き起こします。
どのメッセージがどのビルドに属しているのか分からなくなります。配信停止リンクが最新のものかどうかも判断できません。テンプレートが正しいユーザーセグメントに一致しているかどうかの検証もできなくなります。
ダイジェストメールの QA をプロダクトパスとして扱ってください。JavaScript アプリがイベントをスケジュールし、Node.js がコンテンツをレンダリングし、インボックスのチェックがエクスペリエンスを確認します。どの部分かをスキップしても、テストは素早くパスしますが、何も教えてくれません。
多くのチームは、ローカルでテンプレートをレンダリングして HTML のスナップショットを作成しています。しかし、これでは読者が実際に受け取るメッセージを証明することはできません。
ノイズの原因は、メールボックスの再利用にあります。月曜日のダイジェストが火曜日のリトライメールの隣に並んでしまいます。チームメンバーが間違ったメッセージのリンクをクリックしてしまうかもしれません。テスト結果は「合格（green）」でも、レビューの履歴は混乱した状態になります。
次のシンプルなループを使用してください：
- ブラウザテストが、既知のユーザーセグメントに対してダイジェストのシナリオをトリガーします。
- Node.js が実際のステージングデータを使用してダイジェストを生成します。
- テストはその特定の実行のために、分離された1つのインボックスを使用します。
- ランナーがダイジェストを開き、サマリーブロックを確認します。
- テストが、リンク先が期待されるホストおよびキャンペーンパラメータを指していることを検証します。
メールアドレスを使い捨てのインフラとして扱ってください。シナリオごとに一時的なメールを作成します。これにより、1つの不安定な（flaky）ジョブが次のジョブを台無しにすることを防げます。
「メッセージが届いた」だけで終わらせないでください。優れたテストは、以下の詳細を確認します：
- ジョブが正しいセグメントに対して1つのダイジェストをキューに入れているか。
- 件名に正しい日付が表示されているか。
- プリヘッダーが現在のフィーチャーフラグと一致しているか。
- リンクが期待されるホストと UTM タグを使用しているか。
- 配信停止リンクが正しい環境に遷移するか。
- 同じユーザーに対して重複したダイジェストが表示されないか。
次の3つの間違いを避けてください：
- CI、プレビュービルド、および手動 QA の間で1つのメールボックスを共有すること。
- レンダリングされた HTML を最終目標とすること。
- 古くなったテストアカウントのクリーンアップを忘れること。
チェックリストは、頻繁に実行できるように小さく保ってください。分離（Isolation）によって結果の可読性が維持され、修正が迅速になります。
出典: https://dev.to/ryanlee91/how-i-test-nodejs-digest-emails-without-shared-inbox-noise-54fh