Megbízható ideiglenes postafiók API automatizálás

A megbízhatatlan e‑mail teszt változata rövid: létrehoz egy címet, öt másodpercig vár, elolvassa az első üzenetet, és reméli, hogy az ehhez a futáshoz tartozik.

A megbízható változat továbbra is egyszerű, de aszinkron módon kezeli a kézbesítést. Egyedi címet hoz létre, rögzít egy kezdési időpontot, határidőn belül lekérdez, egyezteti a kívánt üzenetet, ellenőrzi a termék műveletét, és elegendő kontextust jelent, ha valami hibát jelez.

Tartsd az API kulcsot a URL‑en kívül

Küldd a GPTMail kulcsot az X-API-Key fejlécben. Ne tedd a ?api_key= lekérdezési paraméterbe. Az URL‑eket rendszeresen tárolják a böngésző előzményei, hozzáférési naplók, felügyeleti rendszerek és a hivatkozó adatok.

X-API-Key: YOUR_API_KEY

Tárold a kulcsot a CI titkos menedzserében, és takard el a naplókban. Egy nyilvános napi kulcs kényelmes a felfedezéshez; a szabályozott automatizált tesztsorozatoknak olyan kulcsot kell használniuk, amelynek kvótáját és használatát nyomon tudod követni.

Az aktuális végpontok és válaszpéldák a GPTMail API dokumentációs oldalon találhatók.

Egy cím minden futáshoz

Generálj új címet minden önállóan futtatható teszthez. Ne a teljes tesztsorozat által megosztott postafiókból származtass helyességet.

Rögzítsd a címet, a forgatókönyv azonosítót, a környezetet és a teszt kezdési időpontját. Ezek az értékek lehetővé teszik a régi üzenetek elutasítását és az ütközések diagnosztizálását anélkül, hogy az üzenet titkait naplóznád.

Lekérdezés határidővel, nem fix várakozással

Az e‑mail kézbesítési idő változó. Egy fix öt másodperces várakozás pazarló, ha a kézbesítés gyors, és megbízhatatlan, ha lassú.

Használj korlátolt ciklust:

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)

A határidő a teszt szerződéséhez tartozik. A jelszó‑visszaállítási folyamat más limitet igényelhet, mint egy tömeges hírlevél előnézete. Tartsd a limitet explicit módon, hogy egy lassú függőség ne nyújtsa el csendben az egész CI feladatot.

Pontos egyezés

Az „első üzenet a postafiókban” nem hasznos kiválasztó. Egyeztesd több jelzéssel:

• a címzett megegyezik a futáshoz létrehozott címmel;
• a létrehozás időpontja későbbi, mint a trigger időpontja;
• a feladó a várt szolgáltatáshoz tartozik;
• a tárgy vagy az üzenettípus egyezik a folyamattal;
• az üzenetazonosító még nem lett felhasználva.

Ha a feladó több kódot is kiadhat, válaszd a legújabb egyező üzenetet. Őrizd meg az azonosítóját a teszt kimenetében, hogy az újrapróbálkozások ne használják fel véletlenül.

Olvasás csak a lista egyezés után

A postafiók listázása legyen a könnyű felfedezési lépés. A teljes üzenetet csak a kiválasztott jelölt esetén töltsd le. Ez csökkenti a felesleges munkát és elkerüli a nem kapcsolódó promóciós levelek feldolgozását.

Ellenőrizd az üzleti eredményt, ne csak egy hatjegyű karakterlánc jelenlétét. Küldd be a kódot vagy nyisd meg a várt linket, majd állapítsd meg, hogy a fiók a megfelelő állapotba került-e.

Kezeld a sebességkorlátokat jelzésként

Ha az API kvóta vagy sebességkorlát választ ad, állítsd le a jelenlegi kísérletet, és jelenítsd meg a visszaállítási információt. Az agresszív újrapróbálkozások egy egyértelmű kapacitásjelzést zajgá alakítanak, és késleltethetik a nem kapcsolódó teszteket.

Korlátozd a párhuzamosságot a teszt futtatónál, különösen ha egy sorozat egyszerre sok címet hoz létre. Egy kis munkavállalói pool könnyebben hibakereshető, mint a több száz egyidejű lekérdezési ciklus.

Takarítás anélkül, hogy elrejtené a hibákat

A takarítást a bizonyítékok rögzítése után kell végrehajtani. Siker esetén távolítsd el az üzeneteket vagy hagyd, hogy a rövid megőrzés kezelje őket. Hiba esetén tartsd meg a címet és az üzenetazonosítót védett CI artefaktumokban elég hosszú ideig a vizsgálathoz, majd töröld őket.

Soha ne írd ki a hitelesítési kódokat, privát linkeket vagy a teljes HTML tartalmat a nyilvános build naplókba.

Tedd az újrapróbálkozásokat idempotenssé

Próbáld újra a tesztet új futásként egy új címmel. Ne feltételezd, hogy ugyanazon kérés ismétlése ugyanazzal a fiókkal és postafiókkal tiszta állapotból indul. A feladó érvénytelenítheti a régi kódokat, korlátozhatja az ismételt kéréseket, vagy elutasíthatja a duplikált meghívásokat.

Ha egy hálózati kérés időtúllép, különböztess meg „nem érkezett válasz” és „a művelet nem történt meg” állapotokat. Ellenőrizd a megfigyelhető állapotot, mielőtt destruktív újrapróbálkozást indítanál.

Jelentsd a hiba pontját

Egy hasznos automatizálási hiba az alábbi szakaszok egyikét azonosítja:

1. címgenerálás sikertelen;
2. termék művelet sikertelen az e‑mail sorba állítása előtt;
3. nem érkezett egyező üzenet a határidő előtt;
4. az üzenet megérkezett, de a tartalom nem egyezett;
5. hitelesítési művelet sikertelen;
6. takarítás sikertelen.

Ez a besorolás egy időszakos „e‑mail teszt sikertelen” állapotot átalakít olyan feladattá, amelyet a csapat sajátként kezelhet.

A nagyobb tesztmátrixhoz olvasd el a Valódi e‑mail teszt tervet. A kézbesítés diagnosztizálásához használd a Az ellenőrző e-mail nem érkezik meg: a hibás lépés megtalálása cikket.