Den upålidelige version af en e‑mailtest er kort: opret en adresse, vent fem sekunder, læs den første besked, og håb den tilhører denne kørsel.
Den pålidelige version er stadig enkel, men den behandler levering som asynkron. Den opretter en unik adresse, registrerer en starttid, poller inden for en deadline, matcher den tilsigtede besked, validerer produkt‑handlingen og rapporterer tilstrækkelig kontekst, når noget fejler.
Hold API-nøglen ude af URL'en
Send GPTMail‑nøglen i X-API-Key‑headeren. Undlad at placere den i ?api_key=‑forespørgselsparametre. URL'er gemmes rutinemæssigt i browserhistorik, adgangslogfiler, overvågningssystemer og referrer‑data.
X-API-Key: YOUR_API_KEYGem nøglen i din CI‑hemmelighedshåndtering og maskér den i logfiler. En offentlig daglig nøgle er praktisk til udforskning; kontrollerede automatiserede suites bør bruge en nøgle, hvis kvote og brug du kan spore.
De aktuelle slutpunkter og svar‑eksempler vedligeholdes på GPTMail API-dokumentationssiden.
En adresse pr. kørsel
Generér en ny adresse for hver uafhængigt eksekverbar test. Afled ikke korrekthed fra en indbakke, der deles af hele test‑suiten.
Registrér adressen, scenarie‑ID, miljø og test‑starttid. Disse værdier gør det muligt at afvise forældede beskeder og diagnosticere kollisioner uden at logge besked‑hemmeligheder.
Poll mod en deadline, ikke en fast ventetid
E‑mailleveringstiden varierer. En fast fem‑sekunders ventetid er både spild, når leveringen er hurtig, og ustabil, når den er langsom.
Brug en begrænset løkke:
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’en tilhører testkontrakten. En adgangskode‑nulstillings‑flow kan kræve en anden grænse end en masse‑nyhedsbrev‑forhåndsvisning. Hold grænsen eksplicit, så en langsom afhængighed ikke stille udvider hele CI‑jobbet.
Match præcist
“Første besked i indbakken” er ikke en brugbar selector. Match flere signaler:
- modtageren svarer til den adresse, der er oprettet for denne kørsel;
- oprettelsestidspunktet er senere end udløser‑tiden;
- afsenderen tilhører den forventede tjeneste;
- emnet eller beskedtypen matcher flowet;
- besked‑ID’en er endnu ikke blevet brugt.
Når afsenderen kan udstede flere koder, vælg den nyeste matchende besked. Bevar dens ID i testoutputtet, så gentagelser ikke ved et uheld genbruger den.
Læs kun efter et liste‑match
Indbakke‑listning bør være det billige opdagelsestrin. Hent den fulde besked kun for den udvalgte kandidat. Dette reducerer unødvendigt arbejde og undgår at parse irrelevante reklame‑mails.
Valider forretningsresultatet, ikke blot tilstedeværelsen af en sekscifret streng. Indsend koden eller åbn det forventede link, og bekræft derefter, at kontoen når den korrekte tilstand.
Håndtér rate‑begrænsninger som et signal
Hvis API'et returnerer en kvote‑ eller rate‑begrænsnings‑respons, stop den aktuelle forsøg og gør nulstillings‑informationen synlig. Aggressive gentagelser forvandler et klart kapacitets‑signal til støj og kan forsinke urelaterede tests.
Begræns samtidighed i test‑køreren, især når en suite opretter mange adresser på én gang. En lille arbejds‑pool er lettere at fejlsøge end hundredevis af samtidige polling‑løkker.
Oprydning uden at skjule fejl
Oprydning skal køre efter at bevis er indsamlet. Ved succes, fjern beskeder eller lad kortvarig opbevaring håndtere dem. Ved fejl, behold adressen og besked‑ID’en i beskyttede CI‑artefakter længe nok til undersøgelse, og slet dem derefter.
Print aldrig verifikationskoder, private links eller komplette HTML‑kroppe i offentlige build‑logfiler.
Gør gentagelser idempotente
Gentag testen som en ny kørsel med en ny adresse. Antag ikke, at gentagelse af den samme anmodning mod den samme konto og indbakke starter fra en ren tilstand. Afsenderen kan ugyldiggøre gamle koder, throttlere gentagne anmodninger eller afvise dublerede invitationer.
Hvis en netværksanmodning får timeout, skeln mellem “ingen svar modtaget” og “handlingen fandt ikke sted”. Tjek den observerbare tilstand før du udfører en destruktiv gentagelse.
Rapporter fejlpunkten
En brugbar automatiseringsfejl identificerer et af disse trin:
- adressegenerering mislykkedes;
- produkt‑handlingen mislykkedes før e‑mail blev kølet;
- ingen matchende besked ankom før deadline;
- beskeden ankom, men indholdet matchede ikke;
- verifikationshandlingen mislykkedes;
- oprydning mislykkedes.
Den klassificering gør et intermitterende “e‑mailtest mislykkedes” til arbejde, som et team kan eje.
For den større testmatrix, læs En rigtig e-mail-testplan. For leveringsdiagnose, brug Verifikations-e-mail ankommer ikke: Find det ødelagte trin.