Zanesljiva avtomatizacija API-ja za začasni poštni predal

Nezanesljiva različica e‑mail testa je kratka: ustvarite naslov, počakajte pet sekund, preberite prvo sporočilo in upajte, da pripada temu zagonu.

Zanesljiva različica je še vedno preprosta, vendar obravnava dostavo kot asinhrono. Ustvari edinstven naslov, zabeleži začetni čas, polaga znotraj roka, ujame želeno sporočilo, potrdi dejanje izdelka in poroča dovolj konteksta, ko nekaj ne uspe.

Ključ API ne vstavite v URL

Pošljite ključ GPTMail v glavi X-API-Key. Ne vstavljajte ga v poizvedbene parametre ?api_key=. URL‑ji se redno shranjujejo v zgodovino brskalnika, dnevnike dostopa, nadzorne sisteme in podatke o napotitvah.

X-API-Key: YOUR_API_KEY

Shranjite ključ v vašem upravitelju skrivnosti CI in ga maskirajte v dnevnikih. Javni dnevni ključ je priročen za raziskovanje; nadzorovane avtomatizirane zbirke naj uporabljajo ključ, katerega kvoto in uporabo lahko spremljate.

Trenutne končne točke in primere odgovorov vzdržujemo na strani dokumentacije GPTMail API.

En naslov na zagon

Ustvarite nov naslov za vsak samostojno izvedljiv test. Ne izhajajte iz pravilnosti iz poštnega predala, ki ga deli celotna testna zbirka.

Zabeležite naslov, ID scenarija, okolje in čas začetka testa. Te vrednosti vam omogočajo zavrnitev zastarelih sporočil in diagnosticiranje trkov brez beleženja skrivnosti sporočil.

Polagajte do roka, ne po fiksnem spancu

Čas dostave e‑mailov se razlikuje. Fiksni petsekundni spanc je tako neproduktivno, ko je dostava hitra, kot tudi nestabilen, ko je počasna.

Uporabite omejeno zanko:

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 testni pogodbi. Potek ponastavitve gesla lahko potrebuje drugačen limit kot predogled množičnega novičnika. Ohranite limit izrecno, da počasna odvisnost ne podaljša tiho celotnega CI posla.

Natančno ujemanje

„Prvo sporočilo v poštnem predalu“ ni uporaben izbirnik. Ujemajte več signalov:

• prejemnik je enak naslovu, ustvarjenemu za ta zagon;
• čas nastanka je kasnejši od časa sprožitve;
• pošiljatelj pripada pričakovani storitvi;
• zadeva ali vrsta sporočila se ujema s tokom;
• ID sporočila še ni bil porabljen.

Ko pošiljatelj lahko izda več kod, izberite najnovejše ujemajoče se sporočilo. Ohranite njegov ID v izhodu testa, da ponovitve po nesreči ne morejo ponovno uporabiti.

Berite šele po ujemanju seznama

Seznam poštnega predala naj bo poceni korak odkrivanja. Celotno sporočilo pridobite le za izbranega kandidata. To zmanjša nepotrebno delo in prepreči razčlenjevanje nepovezanih promocijskih sporočil.

Potrdite poslovni izid, ne le prisotnost šestmestnega niza. Pošljite kodo ali odprite pričakovano povezavo, nato preverite, da račun doseže pravilno stanje.

Obravnavajte omejitve hitrosti kot signal

Če API vrne odgovor o kvoti ali omejitvi hitrosti, ustavite trenutni poskus in izpostavite informacije o ponastavitvi. Agresivne ponovitve spremenijo jasen signal kapacitete v šum in lahko zamudijo nepovezane teste.

Omejite sočasnost pri izvajalcu testov, še posebej, ko zbirka ustvari veliko naslovov hkrati. Majhen delovni bazen je lažji za odpravljanje napak kot stotine sočasnih zank polaganja.

Čiščenje brez skrivanja napak

Čiščenje naj se izvede po zajemu dokazov. Ob uspehu odstranite sporočila ali naj jih obravnava kratka hrambe. Ob napaki obdržite naslov in ID sporočila v zaščitenih artefaktih CI dovolj dolgo za preiskavo, nato jih izbrišite.

Nikoli ne izpisujte potrditvenih kod, zasebnih povezav ali celotnih HTML vsebin v javne dnevnike gradnje.

Naredite ponovitve idempotentne

Ponovite test kot nov zagon z novim naslovom. Ne predvidevajte, da ponavljanje iste zahteve proti istemu računu in poštnemu predalu začne iz čistega stanja. Pošiljatelj lahko razveljavi stare kode, omeji ponavljajoče se zahteve ali zavrne podvojena povabila.

Če omrežna zahteva časovno poteče, ločite “ni prejetega odgovora” od “operacija se ni zgodila”. Preverite opazno stanje pred izvedbo destruktivne ponovitve.

Prijavite točko napake

Učinkovita napaka avtomatizacije identificira eno od naslednjih faz:

1. ustvarjanje naslova je spodletelo;
2. dejanje izdelka je spodletelo pred vnosom e‑maila v čakalno vrsto;
3. ustrezno sporočilo ni prispelo pred rokom;
4. sporočilo je prispelo, vendar vsebina se ni ujemala;
5. dejanje potrditve je spodletelo;
6. čiščenje je spodletelo.

Ta klasifikacija spremeni občasno “test e‑maila je spodletel” v delo, ki ga lahko prevzame ekipa.

Za večji testni matriks preberite Resnični načrt testiranja e‑mailov. Za diagnozo dostave uporabite Preverjanje e‑maila ne prispe: najdite pokvarjen korak.