
Versi tes email sing ora dipercaya cekak: gawe alamat, turu limang detik, maca pesen pisanan, lan ngarep-arep iku kagolong menyang run iki.
Versi sing dipercaya isih prasaja, nanging nganggep pangiriman minangka asinkron. Iku nggawe alamat unik, nyathet wektu wiwitan, polling sajrone deadline, nyocogake pesen sing dimaksud, validasi aksi produk, lan nglaporake konteks sing cukup nalika ana sing gagal.
Jaga kunci API supaya ora mlebu ing URL
Kirim kunci GPTMail ing header X-API-Key. Aja diselehake ing parameter query ?api_key=. URL asring disimpen ing riwayat browser, log akses, sistem monitoring, lan data referrer.
X-API-Key: YOUR_API_KEYSimpan kunci ing manajer rahasia CI sampeyan lan tutupi ing log. Kunci harian publik trep kanggo eksplorasi; suite otomatis sing dikontrol kudu nggunakake kunci sing kuotane lan panggunaane bisa dilacak.
Endpoint lan contoh respon saiki dijaga ing halaman dokumentasi API GPTMail.
Siji alamat saben run
Gawe alamat anyar kanggo saben tes sing bisa dieksekusi mandiri. Aja njupuk kebenaran saka kotak mlebu sing dienggo bareng dening sakabèhing suite tes.
Cathet alamat, ID skenario, lingkungan, lan wektu wiwitan tes. Nilai iki ngidini sampeyan nolak pesen lawas lan ndeteksi tabrakan tanpa nyathet rahasia pesen.
Poll nganti deadline, ora turu tetep
Waktu pangiriman email beda-beda. Turu limang detik sing tetep mbuwang-buwang wektu nalika pangiriman cepet lan ora stabil nalika alon.
Gunakake loop winates:
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)Deadline iku bagéan saka kontrak tes. Alur reset sandhi bisa butuh wates wektu sing beda karo pratinjau newsletter massal. Jaga wates kasebut cetha supaya ketergantungan sing alon ora nambah wektu job CI kanthi diam-diam.
Cocog kanthi tepat
“Pesen pertama ing kotak mlebu” ora dadi selector sing migunani. Cocogake sawetara sinyal:
- penerima padha karo alamat sing digawe kanggo run iki;
- waktu pembuatan luwih anyar tinimbang waktu pemicu;
- pengirim saka layanan sing diantisipasi;
- subjek utawa tipe pesen cocok karo alur;
- ID pesen durung pernah dipakai.
Nalika pengirim bisa ngirim sawetara kode, pilih pesen paling anyar sing cocok. Simpen ID-e ing output tes supaya retry ora sengaja nggunakake maneh.
Mung maca sawisé cocok ing dhaptar
Dhaptar kotak mlebu kudu dadi langkah penemuan sing murah. Mung njupuk pesen lengkap kanggo kandidat sing dipilih. Iki ngurangi kerja sing ora perlu lan ngindhari parsing email promosi sing ora terkait.
Validasi asil bisnis, ora mung anané string enem digit. Kirim kode utawa bukak tautan sing diantisipasi, banjur pastèkaké akun tekan kondisi sing bener.
Anggep wates laju minangka sinyal
Yen API mbalèkaké respon kuota utawa wates laju, mandhegake upaya saiki lan tampilake informasi reset. Retry agresif ngowahi sinyal kapasitas sing cetha dadi gangguan lan bisa nundha tes sing ora terkait.
Batasi konkuren ing runner tes, utamané nalika suite nggawe akèh alamat sekaligus. Kolam pekerja cilik luwih gampang di-debug tinimbang atusan loop polling bersamaan.
Resik-resik tanpa ndhelikake kegagalan
Resik-resik kudu dilakokaké sawisé bukti dikumpulake. Yen sukses, hapus pesen utawa wenehi retensi sing cendhak. Yen gagal, simpen alamat lan ID pesen ing artefak CI sing dilindhungi cukup suwe kanggo penyelidikan, banjur hapus.
Aja tau ngetokaké kode verifikasi, tautan pribadi, utawa isi HTML lengkap ing log build publik.
Gawe retry dadi idempotèn
Retry tes minangka run anyar nganggo alamat anyar. Aja nganggep manawa mbaleni panjaluk sing padha marang akun lan kotak mlebu sing padha bakal diwiwiti saka kondisi bersih. Pengirim bisa mbatalake kode lawas, mbatesi panjaluk berulang, utawa nolak undhangan duplikat.
Yen panjaluk jaringan kadaluwarsa, bedakake “ora ana respon” saka “operasi ora kedaden.” Priksa kondisi sing bisa diamati sadurunge nindakake retry sing ngrusak.
Laporke titik kegagalan
Kegagalan otomasi sing migunani ngenali salah siji saka tahap iki:
- generasi alamat gagal;
- aksi produk gagal sadurunge email dimasukkan antrian;
- ora ana pesen sing cocok teka sadurunge deadline;
- pesen teka nanging isi ora cocok;
- aksi verifikasi gagal;
- resik-resik gagal.
Klasifikasi iki ngowahi “tes email gagal” sing intermiten dadi tugas sing bisa diparingi tanggung jawab tim.
Kanggo matriks tes sing luwih gedhe, waca Rencana Tes Email Sungguhan. Kanggo diagnosis pangiriman, gunakake Email Verifikasi Ora Teka: Temokake Langkah Rusak.