Den upålitelige versjonen av en e‑posttest er kort: opprett en adresse, vent i fem sekunder, les den første meldingen, og håp at den tilhører denne kjøringen.
Den pålitelige versjonen er fortsatt enkel, men den behandler levering som asynkron. Den oppretter en unik adresse, registrerer en starttid, pøler innen en tidsfrist, matcher den tiltenkte meldingen, validerer produkthandlingen, og rapporterer nok kontekst når noe feiler.
Hold API-nøkkelen utenfor URL-en
Send GPTMail-nøkkelen i X-API-Key-headeren. Ikke legg den i ?api_key=-spørringsparametere. URL-er lagres rutinemessig i nettleserhistorikk, tilgangslogger, overvåkingssystemer og refererdata.
X-API-Key: YOUR_API_KEYLagre nøkkelen i din CI-hemmelige manager og maskér den i logger. En offentlig daglig nøkkel er praktisk for utforskning; kontrollerte automatiserte testsett bør bruke en nøkkel hvis kvote og bruk du kan spore.
De nåværende endepunktene og svar‑eksemplene vedlikeholdes på GPTMail API-dokumentasjonssiden.
En adresse per kjøring
Generer en ny adresse for hver uavhengig kjørbare test. Ikke avled korrekthet fra en innboks delt av hele testsettet.
Registrer adressen, scenario‑ID, miljø og teststarttid. Disse verdiene lar deg avvise utdaterte meldinger og diagnostisere kollisjoner uten å logge meldingshemmeligheter.
Poll mot en tidsfrist, ikke en fast ventetid
E‑postleveringstid varierer. En fast fem sekunders ventetid er både sløsing når leveringen er rask og ustabil når den er langsom.
Bruk en avgrenset 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)Tidsfristen tilhører testkontrakten. En passordtilbakestillingsflyt kan trenge en annen grense enn en forhåndsvisning av masseutsendelse. Hold grensen eksplisitt slik at en langsom avhengighet ikke stille forlenget hele CI‑jobben.
Match presist
«Første melding i innboksen» er ikke en nyttig selector. Match flere signaler:
- mottaker er lik adressen opprettet for denne kjøringen;
- opprettelsestid er senere enn utløsningstidspunktet;
- avsender tilhører den forventede tjenesten;
- emne eller meldingstype matcher flyten;
- meldingens ID er ikke allerede brukt.
Når avsenderen kan utstede flere koder, velg den nyeste matchende meldingen. Bevar dens ID i testutdataene slik at gjenforsøk ikke ved et uhell bruker den igjen.
Les kun etter en liste‑match
Innbokslisten bør være det rimelige oppdagelsestrinnet. Hent hele meldingen kun for den valgte kandidaten. Dette reduserer unødvendig arbeid og unngår å parse irrelevante reklame‑e‑poster.
Valider forretningsresultatet, ikke bare tilstedeværelsen av en sekssifret streng. Send inn koden eller åpne den forventede lenken, og bekreft deretter at kontoen når riktig tilstand.
Håndter hastighetsbegrensninger som et signal
Hvis API-et returnerer en kvote‑ eller hastighetsbegrensningsrespons, stopp det nåværende forsøket og vis tilbakestillingsinformasjonen. Aggressive gjenforsøk gjør et klart kapasitetsignal til støy og kan forsinke urelaterte tester.
Begrens samtidighet i testkjøreren, spesielt når et sett oppretter mange adresser samtidig. En liten arbeidsgruppe er lettere å feilsøke enn hundrevis av samtidige polling‑løkker.
Rydd opp uten å skjule feil
Opprydding bør kjøres etter at bevis er samlet. Ved suksess, fjern meldinger eller la kort lagring håndtere dem. Ved feil, behold adressen og meldingens ID i beskyttede CI‑artifakter lenge nok til undersøkelse, og slett dem deretter.
Skriv aldri ut verifiseringskoder, private lenker eller komplette HTML‑kropper i offentlige bygglogger.
Gjør gjenforsøk idempotente
Gjenforsøk testen som en ny kjøring med en ny adresse. Ikke anta at å gjenta samme forespørsel mot samme konto og innboks starter fra en ren tilstand. Avsenderen kan ugyldiggjøre gamle koder, begrense gjentatte forespørsler, eller avvise dupliserte invitasjoner.
Hvis en nettverksforespørsel får tidsavbrudd, skill mellom «ingen respons mottatt» og «operasjonen skjedde ikke». Sjekk den observerbare tilstanden før du utfører et destruktivt gjenforsøk.
Rapporter feilpunktet
En nyttig automatiseringsfeil identifiserer ett av disse stadiene:
- adressegenerering mislyktes;
- produkthandling mislyktes før e‑post ble satt i kø;
- ingen matchende melding ankom før tidsfristen;
- melding ankom, men innholdet matchet ikke;
- verifiseringshandling mislyktes;
- opprydding mislyktes.
Den klassifiseringen gjør en intermitterende «e‑posttest mislyktes» til arbeid et team kan eie.
For den større testmatrisen, les En reell e‑posttestplan. For leveringsdiagnose, bruk Verifiserings‑e‑post kommer ikke: Finn det ødelagte trinnet.