開發者的 Email 測試完整指南

在自動化測試裡，email 大概是最難涵蓋的一環：最關鍵的那一步——驗證連結、OTP、重設密碼信——會離開你的應用程式，落進一個測試看不到的收件匣。這篇指南就是帶你穩穩測好它的地圖，並一路連到更深入、針對特定框架與情境的教學。

為什麼 email 這麼難測

Email 是非同步的，而且要走過 SMTP，所以信件可能要好幾秒才會到，偏偏測試又期待快速且確定的結果。多個測試共用同一個收件匣，還會互相干擾、讀到舊訊息。整個 email 測試這門功夫，講的就是怎麼把這些不穩定因素拿掉。

核心模式：一個測試一個收件匣

解法是替每次測試開一個全新、可收信的收件匣，再用程式去讀它。一個拋棄式 email API 給你的正是這個——建立一個地址，把 UI 操作推進到寄信那一步，接著抓下訊息、取出連結或代碼。create / poll / read 這幾個基本操作可以參考拋棄式 email API 指南，端對端的整體樣貌則看自動化 email 驗證測試總覽。

輪詢 vs webhook

你可以一直輪詢收件匣直到訊息抵達，或是讓服務在信件一落地就主動推一則通知給你。Webhook 能省掉延遲與多餘的請求——詳見用 webhook 接收進站郵件。在 CI 裡請把逾時設得積極一點：測試環境的交易型郵件通常五秒內就會到，所以輪詢上限抓 20～30 秒綽綽有餘。

依框架

模式到哪裡都一樣，差別在底層接線。先從專門的 Playwright email 測試教學開始，再看 Cypress 與 Selenium 指南。它們共同的關鍵想法是：把 create / await / extract 包進一個可重用的 helper，個別測試才會讀起來清爽。

依情境

真實流程多半是三種模式的變形：OTP 與 2FA 登入、重設密碼，以及魔術連結登入。每一種都需要同樣的讀收件匣步驟，再加上一個取出對應 token 的辦法。

用你的語言、在 CI 裡

不論你是從 Node.js、Python，還是在 GitHub Actions pipeline 裡接收郵件，收件匣 API 都是同一套 HTTP 介面——用你的金鑰認證、建立收件匣、讀取訊息。為每個 PR 開臨時收件匣，能讓 CI 跑起來彼此隔離。

MoeMail 怎麼搭上來

MoeMail 提供完整的 OpenAPI，支援 API 金鑰認證與 webhook，所以你可以從任何語言或 CI runner 建立郵箱、輪詢訊息、對進站郵件做出反應。它是開源的，也能自架，想要自訂網域、不受外部配額限制都行。到個人頁面拿一把金鑰，讀讀 OpenAPI 文件，或直接建立一個郵箱看看資料長什麼樣。