Den opålitliga versionen av ett e‑posttest är kort: skapa en adress, vänta fem sekunder, läs det första meddelandet och hoppas att det tillhör denna körning.
Den pålitliga versionen är fortfarande enkel, men den behandlar leverans som asynkron. Den skapar en unik adress, registrerar en starttid, pollar inom en deadline, matchar det avsedda meddelandet, validerar produktåtgärden och rapporterar tillräckligt med kontext när något misslyckas.
Håll API‑nyckeln utanför URL:en
Skicka GPTMail‑nyckeln i X-API-Key‑headern. Lägg inte den i ?api_key=‑frågeparametrar. URL:er lagras rutinmässigt i webbläsarhistorik, åtkomstloggar, övervakningssystem och referensdata.
X-API-Key: YOUR_API_KEYFörvara nyckeln i din CI‑hemlighets‑hanterare och maskera den i loggar. En offentlig daglig nyckel är bekväm för utforskning; kontrollerade automatiserade sviter bör använda en nyckel vars kvot och användning du kan spåra.
De aktuella slutpunkterna och svarsexemplen underhålls på GPTMail API‑dokumentationssidan.
En adress per körning
Generera en ny adress för varje oberoende körbar test. Härled inte korrekthet från en inkorg som delas av hela testsviten.
Registrera adressen, scenario‑ID, miljö och teststarttid. Dessa värden låter dig avvisa föråldrade meddelanden och diagnostisera kollisioner utan att logga meddelandesecrets.
Polla mot en deadline, inte en fast väntetid
E‑postleveranstiden varierar. En fast femsekunders väntetid är både slö när leveransen är snabb och ostadig när den är långsam.
Använd en begränsad loop:
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)Deadlinen tillhör testkontraktet. Ett lösenords‑återställningsflöde kan behöva en annan gräns än en förhandsgranskning av ett massutskick. Håll gränsen explicit så att en långsam beroende inte tyst förlänger hela CI‑jobbet.
Matcha exakt
"Första meddelandet i inkorgen" är inte en användbar selector. Matcha flera signaler:
- mottagaren är lika med adressen som skapades för denna körning;
- skapandetiden är senare än utlösningstiden;
- avsändaren tillhör den förväntade tjänsten;
- ämnet eller meddelandetypen matchar flödet;
- meddelande‑ID:t har inte redan använts.
När avsändaren kan utfärda flera koder, välj det nyaste matchande meddelandet. Bevara dess ID i testutdata så att omförsök inte av misstag återanvänder det.
Läs endast efter en listmatchning
Inkorgslistning bör vara det billiga upptäcktssteget. Hämta hela meddelandet endast för den valda kandidaten. Detta minskar onödigt arbete och undviker att parsa orelaterad reklampost.
Validera affärsresultatet, inte bara närvaron av en sexsiffrig sträng. Skicka koden eller öppna den förväntade länken, och verifiera sedan att kontot når rätt tillstånd.
Hantera hastighetsgränser som en signal
Om API‑et returnerar ett kvot‑ eller hastighetsgränssvar, stoppa det pågående försöket och visa återställningsinformationen. Aggressiva omförsök förvandlar en klar kapacitetssignal till brus och kan fördröja orelaterade tester.
Begränsa samtidighet i test‑köraren, särskilt när en svit skapar många adresser på en gång. En liten arbets‑pool är lättare att felsöka än hundratals samtidiga poll‑loopar.
Rensa utan att dölja fel
Rensning bör köras efter att bevis har samlats. Vid framgång, ta bort meddelanden eller låt kort lagring hantera dem. Vid fel, behåll adressen och meddelande‑ID:t i skyddade CI‑artefakter tillräckligt länge för undersökning, och radera dem sedan.
Skriv aldrig ut verifieringskoder, privata länkar eller kompletta HTML‑kroppar i offentliga byggloggar.
Gör omförsök idempotenta
Omförsök testet som en ny körning med en ny adress. Anta inte att en upprepning av samma begäran mot samma konto och inkorg startar från ett rent tillstånd. Avsändaren kan ogiltigförklara gamla koder, strypa upprepade begäranden eller avvisa dubblett‑inbjudningar.
Om en nätverksbegäran får timeout, skilj på "inget svar mottaget" och "operationen inträffade inte". Kontrollera det observerbara tillståndet innan du utför en destruktiv omförsök.
Rapportera felpunkten
Ett användbart automatiseringsfel identifierar ett av följande steg:
- adressgenerering misslyckades;
- produktåtgärd misslyckades innan e‑post köades;
- ingen matchande meddelande anlände innan deadline;
- meddelandet anlände men innehållet matchade inte;
- verifieringsåtgärd misslyckades;
- rensning misslyckades.
Den klassificeringen förvandlar ett intermittent "e‑posttest misslyckades" till arbete som ett team kan äga.
För den större testmatrisen, läs En riktig e‑posttestplan. För leveransdiagnostik, använd Verifierings‑e‑post anländer inte: Hitta det brutna steget.