Spolehlivá automatizace API pro dočasnou schránku

Nespolehlivá verze e‑mailového testu je stručná: vytvoříte adresu, počkáte pět sekund, přečtete první zprávu a doufáte, že patří k tomuto běhu.

Spolehlivá verze je také jednoduchá, ale zachází s doručením jako s asynchronním procesem. Vytvoří unikátní adresu, zaznamená čas zahájení, dotazuje se do stanoveného termínu, přiřadí zamýšlenou zprávu, ověří akci produktu a při selhání poskytne dostatek kontextu.

Nenechávejte API klíč v URL

Pošlete klíč GPTMail v hlavičce X-API-Key. Neukládejte jej do dotazových parametrů ?api_key=. URL jsou běžně ukládány v historii prohlížeče, přístupových logech, monitorovacích systémech a v referrer datech.

X-API-Key: YOUR_API_KEY

Uložte klíč ve správci tajemství vašeho CI a maskujte jej v logách. Veřejný denní klíč je vhodný pro zkoušení; řízené automatizované sady by měly používat klíč, jehož kvótu a využití můžete sledovat.

Aktuální koncové body a příklady odpovědí jsou udržovány na stránce dokumentace GPTMail API.

Jedna adresa na běh

Vygenerujte novou adresu pro každý samostatně spustitelný test. Nespoléhejte na správnost na základě schránky sdílené celým testovacím souborem.

Zaznamenejte adresu, ID scénáře, prostředí a čas zahájení testu. Tyto hodnoty vám umožní odmítnout zastaralé zprávy a diagnostikovat kolize, aniž byste zaznamenávali tajemství zpráv.

Dotazujte do termínu, ne na pevný časový spánek

Doba doručení e‑mailu se liší. Pevný pětisekundový spánek je zbytečný, když je doručení rychlé, a nespolehlivý, když je pomalé.

Použijte omezenou smyčku:

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)

Termín patří do smlouvy testu. Tok resetování hesla může vyžadovat jiný limit než náhled hromadného newsletteru. Udržujte limit explicitní, aby pomalá závislost tiše neprodloužila celý CI úkol.

Přesně přiřaďte

„První zpráva ve schránce“ není užitečný výběr. Porovnejte několik signálů:

• příjemce se rovná adrese vytvořené pro tento běh;
• čas vytvoření je pozdější než čas spuštění;
• odesílatel patří očekávané službě;
• předmět nebo typ zprávy odpovídá toku;
• ID zprávy ještě nebylo použito.

Když odesílatel může vydat několik kódů, vyberte nejnovější odpovídající zprávu. Uchovejte její ID v výstupu testu, aby se při opakování nevyužilo omylem.

Čtěte pouze po shodě v seznamu

Výpis schránky by měl být levným krokem pro objevování. Plnou zprávu načtěte jen pro vybraného kandidáta. Tím se sníží zbytečná práce a vyhnete se parsování nesouvisející propagační pošty.

Ověřte obchodní výsledek, ne jen přítomnost šestimístného řetězce. Odeslat kód nebo otevřít očekávaný odkaz, pak potvrďte, že účet dosáhne správného stavu.

Zacházejte s limity rychlosti jako se signálem

Pokud API vrátí odpověď o kvótě nebo limitu rychlosti, zastavte aktuální pokus a zobrazte informace o resetu. Agresivní opakování promění jasný signál kapacity v šum a může zpozdit nesouvisející testy.

Omezte souběžnost v testovacím běžci, zejména když sada vytváří najednou mnoho adres. Malý pool pracovníků je snazší ladit než stovky současných smyček dotazování.

Úklid bez skrývání selhání

Úklid by měl proběhnout po zachycení důkazů. Při úspěchu odstraňte zprávy nebo nechte krátkodobou retenci, aby je vyřídila. Při selhání uchovejte adresu a ID zprávy v chráněných artefaktech CI dostatečně dlouho pro vyšetření, poté je odstraňte.

Nikdy nevyplácejte ověřovací kódy, soukromé odkazy ani celé HTML tělo do veřejných logů sestavení.

Zajistěte idempotenci opakování

Opakujte test jako nový běh s novou adresou. Nepředpokládejte, že opakování stejného požadavku proti stejnému účtu a schránce začne v čistém stavu. Odesílatel může neplatit staré kódy, omezovat opakované požadavky nebo odmítnout duplicitní pozvánky.

Pokud síťový požadavek vyprší, rozlište „neobdržena žádná odpověď“ od „operace se neuskutečnila“. Zkontrolujte pozorovatelný stav před provedením destruktivního opakování.

Nahlaste místo selhání

Užitečné selhání automatizace identifikuje jeden z těchto kroků:

1. generování adresy selhalo;
2. akce produktu selhala před zařazením e‑mailu do fronty;
3. žádná odpovídající zpráva nedorazila před uplynutím lhůty;
4. zpráva dorazila, ale její obsah neodpovídal;
5. ověřovací akce selhala;
6. úklid selhal.

Tato klasifikace promění příležitostné „selhání e‑mailového testu“ na úkol, který může tým převzít.

Pro širší testovací matici si přečtěte Skutečný plán e‑mailových testů. Pro diagnostiku doručení použijte Ověřovací e‑mail nedorazil: Najděte poškozený krok.