テスト環境でメールを捕まえる、という言い方は、届いたメールをどこか自分たちの手元に留めておいて、テストから直接読めるようにすることを指します。本記事では、外部のメールサービスに頼らずにこれを組み立てる理由と、確認を安定させるための考え方を整理します。読み終えると、待ち時間で悩まない確認の書き方が分かります。
外部のメールサービスに任せると何が困るのか？
テストから実際のメールサービスを経由してメールを送ると、確認は環境まかせになります。次のような困りごとが重なります。
- 通信できない場所では確認そのものが走らない。
- 相手側の混雑で、同じ手順でも結果が変わることがある。
- 送ったメールが外部の受信箱に残り、あとから消すのが面倒になる。
- 確認のための認証情報を、テストの実行環境に配る必要が出る。
どれも、確認したい対象とは関係のない問題です。確認したいのは「アプリが正しい内容のメールを組み立てて送り出したか」であって、外部の配送網が速いかどうかではありません。
送り先を手元に向けると何が変わるのか
発信の宛先を、自分たちで立てた受け口に向けます。届いたメールはファイルやメモリに落ち、テストはそれを直接読みます。これで確認は、外部の都合から切り離されます。
得られる利点ははっきりしています。速い、安定している、通信がなくても動く、そして中身が外へ出ない。とくに最後の項目は、本番に近い文面を扱う場面では見逃せません。実際の宛先へ送る確認は、内容によらず外部へ出ていく行為だからです。
待ち時間を書かずに確認するには？
メールの発信は非同期です。送信の処理が終わっても、受け口に現れるのは少し後になります。ここで固定の秒数を待つと、速い環境では無駄に遅くなり、遅い環境では取りこぼします。
代わりに、条件が満たされるまで一定の間隔で見に行き、上限を決めて打ち切ります。この形にすると、速い日はすぐ終わり、遅い日は上限まで粘ります。あわせて、次の点を決めておいてください。
- 何をもって「届いた」とみなすか。宛先か、件名か、両方か。
- 同じメールが二通来たときにどう扱うか。
- 上限に達したときに、何を手がかりに調べるか。
三つ目が抜けていると、失敗したときに原因を追えません。失敗のときに受け口の中身をそのまま残すようにしておくと、調べる手がかりになります。
捕まえたメールを安全に扱う境界
受け口に落ちたメールには、本番に近い文面が入っています。テスト用の値だけで組み立てるようにし、実在の利用者の情報を混ぜないでください。とくに本番のデータを複製してテスト環境へ持ち込んでいる場合、その中に本物の連絡先が含まれていないかを確かめる必要があります。
捕まえたメールは動作確認のための資料であり、そのまま保管し続けるものではありません。確認が終わったら消すところまでを手順に含めてください。実在の身元として使える情報は、この経路には入りません。
受け口を用意して確かめられること
手元の受け口を使うと、確認できる範囲が広がります。たとえば、宛先の組み立てが正しいか、件名が必要な語を含むか、本文に操作のための値が入っているか。どれも、外部へ送らずに確かめられます。
逆に、確かめられないこともあります。受け口は自分たちの都合で動くので、外部の配送網が抱える問題は再現しません。迷惑メールの判定、相手側の受信拒否、配送の遅延といった現象は、実際に外へ送って初めて分かります。普段の確認は受け口で速く回し、公開前に一度だけ外部の経路でも確かめる、という二段構えが現実的です。
開発者向け: 受け口の設計で決めること
まず、実行ごとに宛先を分けます。同じ宛先を共有すると、並行して走る確認が互いのメールを拾います。実行を識別する値を宛先の一部に入れておくと、どのメールが誰のものかが一意に決まります。
次に、内容の確認は「文字列が含まれるか」ではなく「必要な値が取り出せるか」で書きます。文面の言い回しは変わりますが、操作に必要な値の位置は仕様として決まっているはずです。文面全体を比較する確認は、些細な変更で壊れます。
第三に、確認に使う値を固定します。乱数で生成した宛先は再現に使えません。失敗したときに同じ入力でやり直せるよう、種を固定するか、使った値を記録しておいてください。
第四に、後片付けを仕組みにします。受け口の中身は、確認が成功しても失敗しても消します。ただし失敗のときは、調べ终わるまで残す余地を残してください。ここを一律に消すと、原因の追跡ができなくなります。
次のステップ
手元の確認のうち、待ち時間を固定の秒数で書いている箇所を一つ選び、条件が満たされるまで見に行く形へ置き換えてみてください。次に、失敗したときに受け口の中身を残すかどうかを決めます。
一時的な受信箱を確認に使いたい場合は使い捨てメールのツールが利用できます。受け口を一つにまとめる方法はcatch-all メールでステージングの受信を一本化するで、確認メールの流れ全体はメール認証テストの進め方で扱っています。