Automatizim i Besueshëm i API-së për Kutinë e Përkohshme të Email-eve

Versioni i paqëndrueshëm i një testi email është i shkurtër: krijoni një adresë, prisni për pesë sekonda, lexoni mesazhin e parë, dhe shpresoni që i përket këtij ekzekutimi.

Versioni i besueshëm është ende i thjeshtë, por trajton dërgimin si asinkron. Krijon një adresë unike, regjistron kohën e fillimit, pyet brenda një afati, përputh mesazhin e synuar, vërteton veprimin e produktit, dhe raporton kontekst të mjaftueshëm kur diçka dështon.

Mbani çelësin e API-së jashtë URL-së

Dërgoni çelësin GPTMail në header-in X-API-Key. Mos e vendosni në parametrat e pyetjes ?api_key=. URL-të ruhen rregullisht në historikun e shfletuesit, regjistrat e aksesit, sistemet e monitorimit dhe të dhënat e referuesit.

X-API-Key: YOUR_API_KEY

Ruani çelësin në menaxherin e sekreteve të CI-së dhe maskojeni në regjistra. Një çelës publik ditor është i përshtatshëm për eksplorim; grupet e automatizuara të kontrolluara duhet të përdorin një çelës që kuotën dhe përdorimin e tij mund ta ndiqni.

Pikat e fundit dhe shembujt e përgjigjeve janë të mirëmbajtura në faqen e dokumentacionit të API-së GPTMail.

Një adresë për çdo ekzekutim

Gjeneroni një adresë të re për çdo test që ekzekutohet në mënyrë të pavarur. Mos nxirrni korrektësinë nga një kuti postare e përbashkët për të gjithë grupin e testeve.

Regjistroni adresën, ID-në e skenarit, mjedisin dhe kohën e fillimit të testit. Këto vlera ju lejojnë të refuzoni mesazhe të vjetra dhe të diagnostikoni përplasje pa regjistruar sekrete të mesazheve.

Pyetni deri në një afat kohor, jo me një pauzë fikse

Koha e dërgimit të email-it ndryshon. Një pauzë fikse prej pesë sekondash është si e tepërt kur dërgimi është i shpejtë, ashtu edhe e paqëndrueshme kur është i ngadalshëm.

Përdorni një cikël të kufizuar:

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)

Afati i përfundimit i përket kontratës së testit. Një rrjedhë rivendosjeje fjalëkalimi mund të kërkojë një kufi tjetër nga një paraprak i buletinit në masë. Mbani kufirin të qartë që një varësi e ngadaltë të mos zgjatë në heshtje gjithë punën e CI-së.

Përputhni saktësisht

“Mesazhi i parë në kutinë postare” nuk është një përzgjedhës i dobishëm. Përputhni disa sinjale:

• marrësi është i barabartë me adresën e krijuar për këtë ekzekutim;
• koha e krijimit është më vonë se koha e aktivizimit;
• dërguesi i përket shërbimit të pritur;
• subjekti ose lloji i mesazhit përputhet me rrjedhën;
• ID-ja e mesazhit nuk është konsumuar më parë.

Kur dërguesi mund të dërgojë disa kode, zgjidhni mesazhin më të ri që përputhet. Ruani ID-në e tij në output-in e testit që riprovimet të mos e përdorin aksidentalisht përsëri.

Lexoni vetëm pas përputhjes së listës

Listimi i kutisë postare duhet të jetë hapi i zbulimit të lirë. Merrni mesazhin e plotë vetëm për kandidatin e zgjedhur. Kjo redukton punën e panevojshme dhe shmang analizimin e postës promocionale të pa lidhur.

Vërtetoni rezultatin e biznesit, jo thjesht praninë e një vargu gjashtë-shifror. Dërgoni kodin ose hapni lidhjen e pritur, mandej kontrolloni që llogaria arrin në gjendjen e duhur.

Trajtoni kufizimet e shpejtësisë si një sinjal

Nëse API-ja kthen një përgjigje kuoteje ose kufiri të shpejtësisë, ndaloni përpjekjen aktuale dhe shfaqni informacionin e rivendosjes. Përpjekjet agresive e kthejnë sinjalin e qartë të kapacitetit në zhurmë dhe mund të vonojnë testet e tjera.

Kufizoni përbashkëtësinë në ekzekutorin e testeve, veçanërisht kur një grup krijon shumë adresa njëherësh. Një grup i vogël punonjësish është më i lehtë për t’u diagnostikuar sesa qindra cikle të njëkohshme pyetje.

Pastroni pa fshehur dështimet

Pastrimet duhet të ekzekutohen pasi të jenë kapur provat. Nëse testi ka sukses, hiqni mesazhet ose lejoni që mbajtja e shkurtër t’i trajtojë. Nëse dështoj, mbajeni adresën dhe ID-në e mesazhit në artefaktet e mbrojtura të CI-së për mjaftueshëm kohë për hetim, mandej fshini.

Kurrë mos shtypni kode verifikimi, lidhje private, apo trupa HTML të plotë në regjistrat publikë të ndërtimit.

Bëni riprovimet idempotente

Riprovojeni testin si një ekzekutim i ri me një adresë të re. Mos supozoni se përsëritja e të njëjtës kërkesë ndaj të njëjtës llogari dhe kutie postare fillon nga një gjendje e pastër. Dërguesi mund të anulojë kodet e vjetra, të ngadalësojë kërkesat e përsëritura, ose të refuzojë ftesa të dyfishta.

Nëse një kërkesë rrjeti skadon, dalloni “asnjë përgjigje e marrë” nga “operacioni nuk ndodhi”. Kontrolloni gjendjen e dukshme përpara se të bëni një riprovim destruktiv.

Raportoni pikën e dështimit

Një dështim i dobishëm i automatizimit identifikon një nga këto faza:

1. dështoi gjenerimi i adresës;
2. veprimi i produktit dështoi para vendosjes në radhë të email-it;
3. asnjë mesazh i përputhshëm nuk mbërriti para afatit;
4. mesazhi mbërriti, por përmbajtja nuk përputhej;
5. veprimi i verifikimit dështoi;
6. pastrimi dështoi.

Kjo klasifikim e kthen “testi i email-it dështoi” në punë që një ekip mund ta zotërojë.

Për matricën më të madhe të testeve, lexoni Një Plan i Vërtetë i Testimit të Email-it. Për diagnozën e dërgimit, përdorni Email Verifikimi Nuk Arrin: Gjeni Hapin e Thyer.