Mapagkakatiwalaang Automation ng Temporary-Inbox API

Ang hindi mapagkakatiwalaang bersyon ng pagsubok sa email ay maikli: lumikha ng address, matulog ng limang segundo, basahin ang unang mensahe, at umasa na ito ay para sa takbong ito.

Ang mapagkakatiwalaang bersyon ay simple pa rin, ngunit itinuturing ang paghahatid bilang asynchronous. Lumilikha ito ng natatanging address, nagtatala ng oras ng pagsisimula, nagpo‑poll sa loob ng isang deadline, tumutugma sa inaasahang mensahe, nagva‑validate ng aksyon ng produkto, at nag-uulat ng sapat na konteksto kapag may nabigong bahagi.

Panatilihing nasa labas ng URL ang API key

Ipadala ang GPTMail key sa X-API-Key header. Huwag ilagay ito sa ?api_key= query parameters. Ang mga URL ay regular na nasusulat sa kasaysayan ng browser, access logs, monitoring systems, at referrer data.

X-API-Key: YOUR_API_KEY

Itago ang susi sa iyong CI secret manager at i‑mask ito sa mga log. Ang pampublikong pang‑araw‑araw na susi ay maginhawa para sa pag‑explore; ang mga kontroladong automated suite ay dapat gumamit ng susi na ang quota at paggamit ay nasusubaybayan mo.

Ang kasalukuyang mga endpoint at halimbawa ng tugon ay pinananatili sa pahina ng dokumentasyon ng GPTMail API.

Isang address bawat takbo

Lumikha ng bagong address para sa bawat independiyenteng ma‑execute na pagsubok. Huwag umasa sa katumpakan mula sa isang inbox na ibinabahagi ng buong test suite.

Itala ang address, scenario ID, environment, at oras ng pagsisimula ng pagsubok. Ang mga halagang ito ay nagpapahintulot na tanggihan ang mga luma nang mensahe at madiagnose ang mga banggaan nang hindi nagla‑log ng mga lihim ng mensahe.

Mag‑poll laban sa deadline, hindi sa nakapirming pagtulog

Ang oras ng paghahatid ng email ay nagbabago‑bago. Ang nakapirming limang‑segundong pagtulog ay parehong nasasayang kapag mabilis ang paghahatid at hindi matatag kapag mabagal.

Gumamit ng limitadong 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)

Ang deadline ay bahagi ng kontrata ng pagsubok. Maaaring kailanganin ng isang password‑reset flow ang ibang limit kumpara sa bulk newsletter preview. Panatilihing malinaw ang limit upang ang mabagal na dependency ay hindi tahimik na mag‑extend ng buong CI job.

Tumpak na pagtutugma

Ang “unang mensahe sa inbox” ay hindi kapaki‑pakinabang na selector. Tumugma sa ilang signal:

• ang recipient ay katumbas ng address na nilikha para sa takbong ito;
• ang oras ng paglikha ay mas huli kaysa sa oras ng trigger;
• ang sender ay kabilang sa inaasahang serbisyo;
• ang subject o uri ng mensahe ay tumutugma sa flow;
• ang message ID ay hindi pa nagamit.

Kapag ang sender ay maaaring mag‑issue ng maraming code, piliin ang pinakabagong tumutugmang mensahe. Itago ang ID nito sa output ng pagsubok upang ang mga retry ay hindi aksidenteng mag‑reuse nito.

Basahin lamang pagkatapos ng pagtutugma sa listahan

Ang pag‑list ng inbox ay dapat maging murang hakbang sa pagtuklas. Kunin ang buong mensahe lamang para sa napiling kandidato. Binabawasan nito ang hindi kailangang trabaho at iniiwasan ang pag‑parse ng hindi kaugnay na promotional mail.

I‑validate ang business outcome, hindi lamang ang pagkakaroon ng anim‑digit na string. Isumite ang code o buksan ang inaasahang link, pagkatapos ay i‑assert na ang account ay umabot sa tamang estado.

Hawakan ang rate limits bilang senyales

Kung ang API ay nagbabalik ng quota o rate‑limit na tugon, ihinto ang kasalukuyang pagtatangka at ilahad ang impormasyon ng reset. Ang agresibong retries ay nagiging ingay mula sa malinaw na signal ng kapasidad at maaaring mag‑antala ng mga hindi kaugnay na pagsubok.

Limitahan ang concurrency sa test runner, lalo na kapag maraming address ang nilikha nang sabay. Mas madaling i‑debug ang maliit na worker pool kaysa sa daan‑daang sabay‑sabay na polling loop.

Linisin nang hindi itinatago ang mga pagkabigo

Ang cleanup ay dapat tumakbo pagkatapos makuha ang ebidensya. Sa tagumpay, tanggalin ang mga mensahe o hayaang pang‑maikling retention ang mag‑handle nito. Sa pagkabigo, panatilihin ang address at message ID sa protektadong CI artifacts nang sapat na panahon para sa imbestigasyon, pagkatapos ay burahin ang mga ito.

Huwag kailanman i‑print ang verification codes, private links, o kumpletong HTML bodies sa pampublikong build logs.

Gawing idempotent ang mga muling pagsubok

I‑retry ang pagsubok bilang bagong takbo na may bagong address. Huwag ipalagay na ang pag‑ulit ng parehong request laban sa parehong account at inbox ay magsisimula sa malinis na estado. Maaaring i‑invalidate ng sender ang lumang code, mag‑throttle ng paulit‑ulang request, o tanggihan ang duplicate invitations.

Kung ang network request ay nag‑timeout, pag‑hiwalayin ang “walang natanggap na tugon” mula sa “hindi nangyari ang operasyon”. Suriin ang observable state bago mag‑issue ng destructive retry.

Iulat ang punto ng pagkabigo

Ang kapaki‑pakinabang na automation failure ay nag‑identipika ng isa sa mga sumusunod na yugto:

1. nabigong lumikha ng address;
2. nabigong gawin ang product action bago i‑enqueue ang email;
3. walang tumugmang mensahe na dumating bago ang deadline;
4. dumating ang mensahe ngunit hindi tumugma ang nilalaman;
5. nabigong gawin ang verification action;
6. nabigong mag‑cleanup.

Ang klasipikasyong iyon ay nagiging “email test failed” na maaaring pagtrabahuan ng team.

Para sa mas malaking test matrix, basahin ang Isang Tunay na Email Test Plan. Para sa diagnosis ng paghahatid, gamitin ang Hindi Dumarating ang Email ng Beripikasyon: Hanapin ang Sirang Hakbang.