
Nesigurna verzija email testa je kratka: stvori adresu, spavaj pet sekundi, pročitaj prvu poruku i nadaj se da pripada ovom izvođenju.
Pouzdana verzija je i dalje jednostavna, ali tretira isporuku kao asinkronu. Stvara jedinstvenu adresu, bilježi vrijeme početka, upituje unutar roka, podudara namjeravanu poruku, provjerava radnju proizvoda i izvještava dovoljno konteksta kada nešto ne uspije.
Držite API ključ izvan URL-a
Pošaljite GPTMail ključ u zaglavlju X-API-Key. Nemojte ga stavljati u upitne parametre ?api_key=. URL-ovi se rutinski pohranjuju u povijesti preglednika, zapisima pristupa, sustavima nadzora i podacima referera.
X-API-Key: YOUR_API_KEYPohranite ključ u vaš CI upravitelj tajnama i maskirajte ga u zapisima. Javni dnevni ključ je praktičan za istraživanje; kontrolirane automatizirane suite trebaju koristiti ključ čiju kvotu i upotrebu možete pratiti.
Trenutni krajnji točke i primjeri odgovora održavaju se na stranici dokumentacije GPTMail API-ja.
Jedna adresa po izvođenju
Generirajte novu adresu za svaki samostalno izvršivi test. Nemojte izvoditi ispravnost iz sandučića koji dijeli cijeli testni paket.
Zabilježite adresu, ID scenarija, okruženje i vrijeme početka testa. Ove vrijednosti vam omogućuju odbacivanje zastarjelih poruka i dijagnosticiranje kolizija bez zapisivanja tajni poruka.
Upituj prema roku, ne prema fiksnom čekanju
Vrijeme isporuke e-pošte varira. Fiksno čekanje od pet sekundi je i rasipno kad je isporuka brza i nestabilno kad je spora.
Koristite ograničenu petlju:
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)Rok pripada ugovoru testa. Tok resetiranja lozinke može zahtijevati drugačiji limit od pregleda masovnog newslettera. Držite limit eksplicitnim kako spora ovisnost ne bi tiho produžila cijeli CI posao.
Precizno podudaranje
„Prva poruka u sandučiću“ nije koristan odabir. Podudarajte više signala:
- primatelj je jednak adresi stvorenom za ovo izvođenje;
- vrijeme stvaranja je kasnije od vremena okidača;
- pošiljatelj pripada očekivanom servisu;
- predmet ili tip poruke podudaraju se s tokom;
- ID poruke još nije iskorišten.
Kada pošiljatelj može izdati nekoliko kodova, odaberite najnoviju podudarajuću poruku. Sačuvajte njen ID u izlazu testa kako ponovni pokušaji ne bi slučajno ponovno iskoristili.
Čitaj tek nakon podudaranja popisa
Popis sandučića trebao bi biti jeftin korak otkrivanja. Preuzmite cijelu poruku samo za odabranog kandidata. Ovo smanjuje nepotrebni rad i izbjegava parsiranje nepovezane promotivne pošte.
Provjerite poslovni rezultat, a ne samo prisutnost šesteroznamenkaste stringa. Pošaljite kod ili otvorite očekivanu poveznicu, zatim potvrdite da račun doseže ispravno stanje.
Rukovanje ograničenjima brzine kao signalom
Ako API vrati odgovor o kvoti ili ograničenju brzine, zaustavite trenutni pokušaj i izložite informacije o resetiranju. Agresivni ponovni pokušaji pretvaraju jasan signal kapaciteta u šum i mogu odgoditi nepovezane testove.
Ograničite paralelnost u testnom izvršitelju, posebno kada paket stvara mnogo adresa odjednom. Mali radni bazen je lakše debugirati nego stotine simultanih petlji upita.
Čišćenje bez skrivanja neuspjeha
Čišćenje bi trebalo pokrenuti nakon što se prikupe dokazi. Kod uspjeha, uklonite poruke ili dopustite da kratko zadržavanje riješi to. Kod neuspjeha, zadržite adresu i ID poruke u zaštićenim CI artefaktima dovoljno dugo za istraživanje, zatim ih izbrišite.
Nikada ne ispisujte verifikacijske kodove, privatne poveznice ili cijela HTML tijela u javne zapisnike izgradnje.
Učinite ponovne pokušaje idempotentnim
Ponovite test kao novo izvođenje s novom adresom. Nemojte pretpostaviti da ponavljanje istog zahtjeva prema istom računu i sandučiću počinje od čistog stanja. Pošiljatelj može poništiti stare kodove, ograničiti ponovljene zahtjeve ili odbiti duplicirane pozive.
Ako mrežni zahtjev istekne, razlikujte „nema primljenog odgovora“ od „operacija se nije dogodila“. Provjerite vidljivo stanje prije pokretanja destruktivnog ponovnog pokušaja.
Prijavite točku neuspjeha
Koristan neuspjeh automatizacije identificira jednu od ovih faza:
- generiranje adrese nije uspjelo;
- radnja proizvoda nije uspjela prije stavljanja e-pošte u red;
- nijedna podudarajuća poruka nije stigla prije roka;
- poruka je stigla, ali sadržaj se nije podudarao;
- radnja verifikacije nije uspjela;
- čišćenje nije uspjelo.
Ta klasifikacija pretvara povremeni „test e-pošte nije uspio“ u zadatak koji tim može preuzeti.
Za veći testni matrix, pročitajte Stvarni plan testiranja e-pošte. Za dijagnostiku isporuke, koristite Verifikacijska e-pošta ne stiže: Pronađite slomljeni korak.