受信トレイのノイズを発生させずに Nodejs のダイジェストメールをテストする
ダイジェストメールは、プレビュー環境が1つの共有メールボックスにサマリーを送信する場合に問題を引き起こします。
どのメッセージがどのビルドに属しているのか分からなくなります。配信停止リンクが最新のものかどうかも判断できません。テンプレートがユーザーセグメントと一致しているかを見逃す可能性もあります。
私はダイジェストメールのQAをプロダクトパスとして扱っています。JavaScript アプリがイベントをスケジュールし、Node.js がコンテンツをレンダリングします。そして、受信トレイのチェックによって最終的なエクスペリエンスを確認します。
多くのチームが次のような間違いを犯しています：
- 1つのメールボックスを多くの実行で使い回している。月曜日のダイジェストが火曜日のビルドの隣に並んでしまう。
- 一時的なメール文字列を含む古いステージングデータに依存している。
- レンダリングされたHTMLをゴールと考えている。ライブデータが間違っていても、HTMLのスナップショットはパスしてしまう。
優れたテストは、読者が実際に受け取るメッセージを証明できなければなりません。代わりに、次のようなシンプルなループを使用してください：
- テストトリガーが特定のユーザーセグメントに対してダイジェストを作成する。
- Node.js が実際のステージングデータを使用してダイジェストを生成する。
- テストはその特定の実行のために、隔離された1つの受信トレイを使用する。
- ランナーがダイジェストを開き、サマリーブロックをチェックする。
- テストが、リンクが正しいホストとキャンペーンパラメータを指していることを検証する。
メールアドレスを使い捨てのインフラとして扱ってください。シナリオごとに一時的なメールアカウントを作成します。これにより、1つの不安定なジョブが次のジョブを台無しにすることを防げます。
有用なダイジェストテストでは、以下の詳細を確認します：
- スケジュールされたジョブが、正しいセグメントに対して1つのダイジェストをキューに入れる。
- 件名に正しい日付が表示されている。
- プリヘッダーが現在のフィーチャーフラグと一致している。
- リンクが正しいホスト、UTMタグ、およびロケールを使用している。
- 配信停止リンクが正しい環境に遷移する。
- 同じユーザーに対して重複したダイジェストが表示されない。
CI、プレビュービルド、手動QAの間で1つのメールボックスを共有するのはやめましょう。最初は効率的に感じられますが、後になって偽陽性を生み出すことになります。
隔離することで修正が早まります。ダイジェストが失敗したとき、問題がスケジューラーにあるのか、レンダラーにあるのか、あるいはメッセージ自体にあるのかが分かります。
Source: https://dev.to/ryanlee91/how-i-test-nodejs-digest-emails-without-shared-inbox-noise-54fh