任何會發送電郵的應用程式,都需要用真正收得到郵件的地址來測試。Mock 物件只能驗證你的程式碼呼叫了發送函式;它無法告訴你驗證連結是否有效、範本是否正常顯示,或者你的入門引導序列是否按正確次序觸發。要做到這些,你需要把郵件真正投遞到真實的收件箱——最好是零成本、免設置、用完自動清理的收件箱。這正正是拋棄式電郵的形態。
為甚麼開發者會選用拋棄式收件箱
傳統的替代方案都有阻力:
- 個人地址加 plus 標籤會污染你的真實收件箱,在拒絕加號的應用程式上會失效,而且不便與隊友共用或貼進錯誤報告。
- 在一般供應商開設一批專用測試帳戶,意味着要管理憑證、清理收件箱,而自動化測試連番轟炸時,還會遇上速率限制或帳戶封鎖。
- 完整的電郵測試平台(附 API 的攔截伺服器)對成熟的 CI 流水線是正確之選,但它們是基礎設施:帳戶、API 金鑰、設定,而且往往有帳單。
MailDrop 的拋棄式收件箱正處於另一端:開啟應用程式,使用一個地址,看着郵件到達,繼續工作。沒有帳戶、測試筆記中沒有憑證、毋須清理。對於眾多手動或半手動的測試工作而言,這種零設置特性就是全部價值所在。
拋棄式收件箱可以測試甚麼
註冊與驗證流程
最基本的用例。用全新的拋棄式地址註冊,驗證整個循環:郵件有到達、及時到達、驗證連結可以打開、權杖在應到期時到期,以及重新索取驗證電郵時行為正常。由於每次測試都可以使用全新地址,你演練的是真正的首次用戶路徑,而不是曾出現過的地址的路徑。
交易類電郵內容
密碼重設、收據、通知摘要:在中立的網頁收件箱開啟它們,檢查主旨是否合理、連結是絕對路徑而非 localhost、個人化變數已填入而非原樣輸出,以及有純文字後備版本。
邊緣情況與負面路徑
- 註冊後一直不點擊驗證連結,確認系統在時限過後如何處理未驗證帳戶。
- 為一個其後不再存在的地址觸發密碼重設——你的流程能否妥善失敗?
- 在地址有效期內重用它,測試重複註冊的處理。
拋棄式網域政策測試
諷刺的是,這是最佳用途之一:如果你的產品打算封鎖拋棄式網域,你就需要真實的拋棄式地址,來驗證封鎖清單有效、保持更新,並回傳有用的錯誤訊息而非無聲失敗。
行之有效的模式
- 每個測試用例一個地址。 地址免費而且即時可得;切勿在不同情境共用。測試之間的狀態洩漏,是電郵測試不穩定的經典根源。
- 以測試命名地址。 一個可讀、編入工單編號或情境的本地部分,令日後有人開啟收件箱時,分流工作不言自明。
- 配合產生的測試資料。 註冊表格還需要姓名和個人資料;身份產生器可產生連貫的佔位用戶,密碼產生器則為每個測試帳戶提供獨一無二的憑證,即使測試環境資料庫外洩,也不會暴露團隊重用的密碼。
- 記錄「只收不發」的限制。 MailDrop 收件箱只作接收,不能發送。需要用戶從郵件程式回覆的流程要用其他工具——寫進測試計劃,好過在衝刺中途才發現。
誠實的局限——標準化之前先了解
- 公開收件箱。 拋棄式收件箱任何知道地址的人都能閱讀。切勿向它發送真實用戶資料、生產環境憑證或機密發佈資訊。只限測試資料。(整體取捨見臨時郵箱安全嗎。)
- 過期既是功能也是限制。 郵件會如期消失。任何團隊下個月還要存取的帳戶,都不要用拋棄式地址——測試環境的管理員帳戶應綁定真實、受控的地址。
- 不能取代 CI。 對於需要以程式驗證電郵內容的大量自動化測試,API 驅動的攔截服務或自行架設的 SMTP sink 才是正確工具。拋棄式網頁收件箱的強項在於手動 QA、探索性測試、示範,以及重現用戶回報的問題。
- 第三方服務的條款仍然適用。 針對別人的平台(OAuth 供應商、交易市集)測試時,對方關於拋棄式地址的規則說了算。測試自己的系統儘管放手做;尊重其他所有人的條款。
給用戶多一分同理心
花一天用拋棄式地址做測試,會學到一課有用的產品啟示:你的用戶也有同樣的選擇。你的轉化漏斗中每一個多餘的電郵要求——示範前的強制註冊、文件前的電郵閘門——都是一個讓注重私隱的用戶交出過期地址的節點,正如為何網站售賣你的電郵所述。如果你收集的地址永遠不會換來任何有價值的回報,不如索性不收集。電郵測試最好的洞見,有時就是那封電郵根本不應存在。
開始使用
沒有甚麼入門流程可言。開啟 MailDrop,把下一個註冊測試指向所顯示的地址,驗證電郵就會在網頁收件箱等着你。測試完成後,清理步驟就是——沒有清理步驟。