Niezawodna automatyzacja API tymczasowej skrzynki odbiorczej

Niewiarygodna wersja testu e‑mail jest krótka: utwórz adres, odczekaj pięć sekund, odczytaj pierwszą wiadomość i miej nadzieję, że należy do tego uruchomienia.

Niezawodna wersja jest nadal prosta, ale traktuje dostawę jako asynchroniczną. Tworzy unikalny adres, zapisuje czas rozpoczęcia, odpyta w ramach limitu czasu, dopasowuje właściwą wiadomość, weryfikuje akcję produktu i raportuje wystarczający kontekst, gdy coś się nie powiedzie.

Trzymaj klucz API poza URL

Wyślij klucz GPTMail w nagłówku X-API-Key. Nie umieszczaj go w parametrach zapytania ?api_key=. URL‑e są regularnie zapisywane w historii przeglądarki, logach dostępu, systemach monitoringu i danych referera.

X-API-Key: YOUR_API_KEY

Przechowuj klucz w menedżerze sekretów CI i maskuj go w logach. Publiczny dzienny klucz jest wygodny do eksploracji; kontrolowane zestawy automatyzacji powinny używać klucza, którego limit i użycie możesz śledzić.

Aktualne endpointy i przykłady odpowiedzi są utrzymywane na stronie dokumentacji API GPTMail.

Jeden adres na uruchomienie

Generuj nowy adres dla każdego niezależnie wykonywalnego testu. Nie wyciągaj poprawności z jednej skrzynki współdzielonej przez cały zestaw testów.

Zapisz adres, identyfikator scenariusza, środowisko i czas rozpoczęcia testu. Te wartości pozwalają odrzucać przestarzałe wiadomości i diagnozować kolizje bez logowania tajemnic wiadomości.

Odpytywanie w ramach limitu czasu, nie stałe opóźnienie

Czas dostarczenia e‑maila jest zmienny. Stałe pięciosekundowe opóźnienie jest marnotrawstwem, gdy dostawa jest szybka, i zawodnym, gdy jest wolna.

Użyj ograniczonej pętli:

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)

Limit czasu jest częścią umowy testowej. Przepływ resetowania hasła może wymagać innego limitu niż podgląd masowego newslettera. Trzymaj limit wyraźny, aby wolna zależność nie rozciągała cicho całego zadania CI.

Dopasuj precyzyjnie

„Pierwsza wiadomość w skrzynce” nie jest przydatnym selektorem. Dopasuj kilka sygnałów:

• odbiorca jest równy adresowi utworzonemu dla tego uruchomienia;
• czas utworzenia jest późniejszy niż czas wyzwolenia;
• nadawca należy do oczekiwanej usługi;
• temat lub typ wiadomości pasuje do przepływu;
• identyfikator wiadomości nie został już zużyty.

Gdy nadawca może wysłać kilka kodów, wybierz najnowszą pasującą wiadomość. Zachowaj jej ID w wynikach testu, aby ponowne próby nie mogły przypadkowo jej ponownie użyć.

Odczytuj tylko po dopasowaniu listy

Wylistowanie skrzynki powinno być tanim krokiem odkrywania. Pobierz pełną wiadomość tylko dla wybranego kandydata. To zmniejsza niepotrzebną pracę i unika parsowania niepowiązanej poczty promocyjnej.

Zweryfikuj wynik biznesowy, a nie tylko obecność sześciocyfrowego ciągu. Prześlij kod lub otwórz oczekiwany link, a następnie sprawdź, czy konto osiąga prawidłowy stan.

Traktuj limity szybkości jako sygnał

Jeśli API zwróci odpowiedź o limicie lub ograniczeniu szybkości, zatrzymaj bieżącą próbę i ujawnij informacje o resetowaniu. Agresywne ponowne próby zamieniają wyraźny sygnał pojemności w szum i mogą opóźniać niepowiązane testy.

Ogranicz równoczesność w uruchamiaczu testów, szczególnie gdy zestaw tworzy wiele adresów jednocześnie. Mała pula pracowników jest łatwiejsza do debugowania niż setki jednoczesnych pętli odpytywania.

Czyszczenie bez ukrywania niepowodzeń

Czyszczenie powinno odbywać się po zebraniu dowodów. Po sukcesie usuń wiadomości lub pozwól, aby krótkotrwałe przechowywanie je usunęło. Po niepowodzeniu zachowaj adres i ID wiadomości w chronionych artefaktach CI wystarczająco długo, aby umożliwić dochodzenie, a następnie je usuń.

Nigdy nie drukuj kodów weryfikacyjnych, prywatnych linków ani pełnych treści HTML w publicznych logach budowania.

Spraw, aby ponowne próby były idempotentne

Powtórz test jako nowe uruchomienie z nowym adresem. Nie zakładaj, że powtarzanie tego samego żądania wobec tego samego konta i skrzynki zaczyna się od czystego stanu. Nadawca może unieważnić stare kody, ograniczyć częstotliwość powtarzających się żądań lub odrzucić duplikaty zaproszeń.

Jeśli żądanie sieciowe przekroczy limit czasu, rozróżnij „brak odpowiedzi” od „operacja nie nastąpiła”. Sprawdź stan obserwowalny przed wykonaniem destrukcyjnej ponownej próby.

Zgłoś punkt niepowodzenia

Użyteczne niepowodzenie automatyzacji identyfikuje jeden z następujących etapów:

1. generowanie adresu nie powiodło się;
2. akcja produktu nie powiodła się przed umieszczeniem e‑maila w kolejce;
3. żadna pasująca wiadomość nie dotarła przed upływem limitu czasu;
4. wiadomość dotarła, ale jej treść nie pasowała;
5. akcja weryfikacji nie powiodła się;
6. czyszczenie nie powiodło się.

Ta klasyfikacja zamienia przerywane „test e‑mail nie powiódł się” w zadanie, które zespół może przejąć.

Aby poznać szerszą matrycę testów, przeczytaj Rzeczywisty plan testów e‑mail. Do diagnozy dostawy użyj Weryfikacja e‑mail nie dociera: znajdź uszkodzony krok.