メールを送信するアプリケーションはすべて、実際に受信できるアドレスでテストする必要があります。モックオブジェクトは、コードが送信関数を呼んだことは検証できても、認証リンクが機能すること、テンプレートが正しく表示されること、オンボーディングのシーケンスが正しい順序で発火することまでは教えてくれません。そのためには、実在する受信箱への実際の配信が必要です。理想を言えば、費用がかからず、セットアップ不要で、後片付けも自動で済む受信箱です。それはまさに使い捨てメールの姿そのものです。
開発者が使い捨て受信箱に手を伸ばす理由
従来の代替手段には、どれも摩擦があります。
- プラスタグ付きの個人アドレスは、本物の受信箱を汚し、プラス記号を弾くアプリでは使えず、チームメイトと共有したりバグレポートに貼り付けたりするのも不便です。
- 通常のプロバイダでの専用テストアカウント群は、管理すべき認証情報、掃除すべき受信箱を意味し、自動テストが叩きまくればレート制限やロックアウトに遭います。
- 本格的なメールテストプラットフォーム(API付きキャプチャサーバー)は、成熟したCIパイプラインには正しい選択ですが、インフラです。アカウント、APIキー、設定、そして多くの場合は請求書が付いてきます。
MailDropの使い捨て受信箱はその対極にあります。アプリを開き、アドレスを使い、メッセージの到着を確認して、次へ進む。アカウントも、テストメモに書き残す認証情報も、後片付けもありません。手動または半手動で行われる多くのテスト作業にとって、このゼロセットアップという性質こそが価値のすべてです。
使い捨て受信箱でテストできること
登録・認証フロー
定番中の定番です。新しい使い捨てアドレスで登録し、ループ全体を検証します。メッセージが届くこと、速やかに届くこと、認証リンクが解決すること、トークンが想定どおりに失効すること、認証メールの再送要求がまともに動くこと。テスト実行ごとに真新しいアドレスを使えるため、以前に見たことのあるアドレスの経路ではなく、本当の初回ユーザーの経路を検証できます。
トランザクションメールの内容
パスワードリセット、領収書、通知ダイジェスト。中立的なウェブ受信箱で開き、件名がまともか、リンクがlocalhostではなく絶対URLか、パーソナライズ用のトークンが生のまま残っていないか、プレーンテキスト版が存在するかを確認しましょう。
エッジケースと異常系
- 登録して認証リンクを一切クリックせず、タイムアウト後に未認証アカウントがどう処理されるかを確認する。
- その後存在しなくなるアドレスに対してパスワードリセットを発動し、フローが行儀よく失敗するかを見る。
- 有効期間内にアドレスを再利用して、重複登録の処理をテストする。
使い捨てドメインポリシーのテスト
皮肉なことに、最良の用途の一つです。プロダクトが使い捨てドメインをブロックする方針なら、そのブロックリストが機能し、最新に保たれ、静かな失敗ではなく分かりやすいエラーを返すことを検証するために、本物の使い捨てアドレスが必要になります。
うまくいくパターン
- テストケースごとに1アドレス。 アドレスは無料で即座に使えます。シナリオをまたいで使い回さないこと。テスト実行間の状態漏れは、不安定なメールテストの古典的な原因です。
- テスト名にちなんだアドレスを付ける。 チケット番号やシナリオを織り込んだ読みやすいローカルパートにしておけば、後で誰かが受信箱を開いたときにトリアージが自己文書化されます。
- 生成したフィクスチャデータと組み合わせる。 登録フォームは名前やプロフィールも求めてきます。アイデンティティジェネレーターは一貫性のあるダミーユーザーを生成し、パスワードジェネレーターはすべてのテストアカウントに固有の認証情報を与えるので、ステージング環境のデータベースが漏れてもチームの使い回しパスワードが露出することはありません。
- 受信専用という制約を文書化する。 MailDropの受信箱は受信のみで、送信はできません。ユーザーのメールクライアントからの返信を必要とするフローには別のツールが必要です。スプリントの途中で気づくのではなく、テスト計画に書いておきましょう。
正直な限界──標準化する前に知っておくこと
- 受信箱は公開です。 使い捨て受信箱は、アドレスを知っている人なら誰でも読めます。実際のユーザーデータ、本番の認証情報、機密のリリース情報を決して送らないこと。テストフィクスチャのみです。(一般的なトレードオフは使い捨てメールは安全かで扱っています。)
- 期限切れは機能であり制約でもあります。 メッセージは予定どおりに消えます。チームが来月アクセスする必要のあるアカウントに使い捨てアドレスを使ってはいけません。ステージングの管理者アカウントは、本物の管理されたアドレスに置くべきです。
- CIの代替にはなりません。 メール内容をプログラムで検証する大量の自動テストスイートには、API駆動のキャプチャサービスやセルフホストのSMTPシンクが正しいツールです。使い捨てのウェブ受信箱が輝くのは、手動QA、探索的テスト、デモ、そしてユーザー報告の問題の再現です。
- サードパーティサービスの規約は依然として適用されます。 他社のプラットフォーム(OAuthプロバイダやマーケットプレイスなど)に対してテストする場合は、使い捨てアドレスに関する相手のルールが優先されます。自社システムは自由にテストし、他社の規約は尊重しましょう。
ユーザーへの共感について一言
使い捨てアドレスで一日テストしてみると、プロダクトについて有益な教訓が得られます。あなたのユーザーにも同じ選択肢があるということです。ファネル内の不必要なメール要求──デモの前の強制登録、ドキュメントの前のアドレスの壁──はすべて、プライバシー意識の高いユーザーが期限切れになるアドレスを差し出すポイントです。これはウェブサイトがあなたのメールアドレスを売る理由で述べたとおりです。収集したアドレスに価値あるものを届けるつもりがないなら、収集しないことを検討しましょう。メールテストから得られる最良の洞察は、時に「そのメールは存在すべきではない」ということなのです。
はじめかた
説明すべきオンボーディングはありません。MailDropを開き、次の登録テストで表示されたアドレスを使えば、認証メールがウェブ受信箱で待っています。テストが終わったら、後片付けのステップは「後片付けのステップがないこと」です。