テスト用のフェイクメールアドレス：登録フォームに安心して使えるアドレス
サイトを作ったりテストしたりしていると、フォームにメールアドレスを入れてばかりになります。決して 起きてはいけないのは、テストのメールが見知らぬ人の本物の受信箱に届いてしまうことだけです。このページでは、 テストの種類ごとにどのフェイクメールアドレスを使えばいいか — そして本当にメールを届ける必要があるのは いつか — を説明します。
まず、メールが届く必要があるかを決める
この一つの問いですべてが決まります。はっきり問う価値があります。答えが「いいえ」である場面は、思われて いるより多いからです。
| テストするもの | メールは届く必要がある？ | 使うもの |
|---|---|---|
| アドレスの検証・保存・表示 | いいえ | 予約済みドメイン — 下を参照 |
| 確認の流れ(手作業) | はい | ここの受信箱 |
| 確認の流れ(自動化) | はい、コードから読める形で | API のあるサービス |
| 負荷テスト・大量テスト | いいえ — 届いてはいけない | 必ず予約済みドメイン |
メールを届けてはいけないとき：予約済みの名前
まさにそのために存在し、誰のものにもならないことが保証されたドメインがあります。 example.com と、その兄弟の example.net、example.org(RFC 2606 で予約)、 そして .test の末尾全体です。
これらのドメイン上のアドレスは、サンプルデータ、初期データ、負荷テストの正解です。送ったものが人に届く ことはありません。そこには誰もいないからです — 運ではなく、国際的な取り決めによって。
test@mycompanytest.com は、思った以上に誰かの本物のドメインで、そこに向けた負荷テストは 攻撃と見分けがつきません。予約済みの名前は無料で、この種の事故をまるごとなくしてくれます。メールを届ける必要があるとき(手作業)
ここでアドレスを取り、流れを実行して、アプリが実際に何を送ったかを読んでください — ヘッダー、リンク、 そして自分のメールソフト以外で表示したときの見た目。ローカルのメールキャッチャーでは分からないことが 二つ見えます。
- 本物の配送。メッセージは本物のメールの経路を通るので、設定のおかしい送信側は本番ではなく ここで失敗します。
- 知らない人からの見え方。自分のセッションでしか動かないリンク、いつまでも読み込まれない画像、 localhost を指す配信停止リンク — すぐに目に入ります。
アプリがファイルを送るなら、添付ファイルの警告も見てください。ユーザーが目にするのと同じ警告です。
自動化しなければならないとき
代わりにページをスクレイピングするのは、動いたとしても割に合いません。壊れやすく、ドキュメントもなく、 いずれブロックされる種類の通信そのものだからです。
断られるケースのテスト
おもしろい失敗は「有効なアドレスが動く」ではありません。押さえておく価値があるのは次のものです。
- MX レコードのないドメインのアドレス — アドレスの書き方は正しいのに、配送が失敗します。 コードはこの二つを区別するべきです。 どちらがどちらか確かめる。
- 国際化ドメインを、Unicode の形と
xn--の形の両方で。たいていの検証は片方を 拒否して片方を受け付け、しかもたいてい逆です — コンバーター。 - ドットやプラスを使った Gmail の変種。重複チェックが生の文字列を比べていると、一人で いくらでもアカウントを作れます。 先に正規化を — あのページは、 あなたのチェックがすべきことをそのまま行います。
- とても長い @ より前の部分。規格では 64 文字まで認められていますが、多くのフォームは 黙って 20 文字で切り、どこにもつながらない文字列を保存します。
テストするのではなく、作るべきもの
あなたのサービスがフェイクメールアドレスを受け付けないなら、はっきり断ってください。まったく正しい アドレスに「無効なメールアドレス」と出すのは、この分野でいちばん混乱させるエラーです。利用者はつづりを確かめ、 打ち直し、同じメッセージを受け取ります。「フェイクメールアドレスはご利用いただけません」なら同じ場所で済み、 混乱も終わります。