
Versi tidak dapat diandalkan dari tes email singkat: buat sebuah alamat, tunggu selama lima detik, baca pesan pertama, dan berharap itu milik run ini.
Versi yang dapat diandalkan tetap sederhana, tetapi memperlakukan pengiriman sebagai asinkron. Ia membuat alamat unik, mencatat waktu mulai, melakukan polling dalam batas waktu, mencocokkan pesan yang dimaksud, memvalidasi aksi produk, dan melaporkan konteks yang cukup ketika ada yang gagal.
Keep the API key out of the URL
Kirim kunci GPTMail dalam header X-API-Key. Jangan menaruhnya di parameter query ?api_key=. URL secara rutin disimpan dalam riwayat browser, log akses, sistem pemantauan, dan data referer.
X-API-Key: YOUR_API_KEYSimpan kunci di manajer rahasia CI Anda dan sembunyikan dalam log. Kunci publik harian memudahkan eksplorasi; suite otomatisasi yang terkontrol sebaiknya menggunakan kunci yang kuota dan penggunaannya dapat Anda lacak.
Endpoint dan contoh respons saat ini dipelihara di halaman dokumentasi API GPTMail.
One address per run
Hasilkan alamat baru untuk setiap tes yang dapat dijalankan secara independen. Jangan menilai kebenaran berdasarkan kotak masuk yang dibagi oleh seluruh suite tes.
Catat alamat, ID skenario, lingkungan, dan waktu mulai tes. Nilai-nilai ini memungkinkan Anda menolak pesan usang dan mendiagnosa tabrakan tanpa mencatat rahasia pesan.
Poll against a deadline, not a fixed sleep
Waktu pengiriman email bervariasi. Penundaan tetap lima detik sia-sia ketika pengiriman cepat dan tidak stabil ketika lambat.
Gunakan loop terbatas:
deadline = now + 90 seconds
delay = 2 seconds
while now < deadline:
messages = list inbox
candidate = newest message matching sender, subject, and start time
if candidate exists:
read candidate and continue the product test
wait delay with a small random jitter
delay = min(delay * 1.5, 10 seconds)Batas waktu merupakan bagian dari kontrak tes. Alur reset kata sandi mungkin memerlukan batas yang berbeda dari pratinjau buletin massal. Jaga batas tersebut eksplisit agar ketergantungan yang lambat tidak secara diam-diam memperpanjang seluruh pekerjaan CI.
Match precisely
"Pesan pertama di kotak masuk" bukan pemilih yang berguna. Cocokkan beberapa sinyal:
- penerima sama dengan alamat yang dibuat untuk run ini;
- waktu pembuatan lebih lama dari waktu pemicu;
- pengirim berasal dari layanan yang diharapkan;
- subjek atau tipe pesan cocok dengan alur;
- ID pesan belum pernah digunakan sebelumnya.
Ketika pengirim dapat mengeluarkan beberapa kode, pilih pesan terbaru yang cocok. Simpan ID-nya dalam output tes sehingga percobaan ulang tidak secara tidak sengaja menggunakannya kembali.
Read only after a list match
Daftar kotak masuk harus menjadi langkah penemuan yang murah. Ambil pesan lengkap hanya untuk kandidat yang dipilih. Ini mengurangi pekerjaan yang tidak perlu dan menghindari parsing email promosi yang tidak terkait.
Validasi hasil bisnis, bukan sekadar keberadaan string enam digit. Kirim kode atau buka tautan yang diharapkan, lalu pastikan akun mencapai status yang benar.
Handle rate limits as a signal
Jika API mengembalikan respons kuota atau batas kecepatan, hentikan percobaan saat ini dan tampilkan informasi reset. Percobaan ulang agresif mengubah sinyal kapasitas yang jelas menjadi kebisingan dan dapat menunda tes yang tidak terkait.
Batasi konkurensi pada runner tes, terutama ketika sebuah suite membuat banyak alamat sekaligus. Pool pekerja kecil lebih mudah di-debug daripada ratusan loop polling simultan.
Cleanup without hiding failures
Pembersihan harus dijalankan setelah bukti diambil. Pada keberhasilan, hapus pesan atau biarkan retensi singkat menanganinya. Pada kegagalan, simpan alamat dan ID pesan dalam artefak CI yang dilindungi cukup lama untuk penyelidikan, kemudian hapus.
Jangan pernah mencetak kode verifikasi, tautan pribadi, atau seluruh isi HTML ke dalam log build publik.
Make retries idempotent
Ulangi tes sebagai run baru dengan alamat baru. Jangan mengasumsikan bahwa mengulangi permintaan yang sama terhadap akun dan kotak masuk yang sama memulai dari keadaan bersih. Pengirim mungkin menolak kode lama, membatasi permintaan berulang, atau menolak undangan duplikat.
Jika permintaan jaringan timeout, bedakan “tidak ada respons yang diterima” dari “operasi tidak terjadi”. Periksa keadaan yang dapat diamati sebelum melakukan retry yang merusak.
Report the point of failure
Kegagalan otomasi yang berguna mengidentifikasi salah satu tahap berikut:
- pembuatan alamat gagal;
- aksi produk gagal sebelum email dimasukkan ke antrean;
- tidak ada pesan yang cocok tiba sebelum batas waktu;
- pesan tiba tetapi kontennya tidak cocok;
- aksi verifikasi gagal;
- pembersihan gagal.
Klasifikasi itu mengubah “tes email gagal” yang bersifat intermiten menjadi pekerjaan yang dapat dimiliki tim.
Untuk matriks tes yang lebih besar, baca Rencana Tes Email Nyata. Untuk diagnosis pengiriman, gunakan Email Verifikasi Tidak Tiba: Temukan Langkah yang Rusak.