Programy poleceń to jedne z najbardziej emailowych przepływów, jakie produkty wydają: udostępnienie generuje kod, polecony otrzymuje email, rejestracja tworzy atrybucję, a finalnie obie osoby dostają emaile z nagrodami. Każdy krok to osobna powierzchnia awarii, a przepływ z natury jest wieloskrzynkowy — jeden kompletny test potrzebuje co najmniej polecającego i poleconego. Właśnie tu błyszczą skrzynki jednorazowe: świeże adresy na przebieg, skryptowane wyciąganie kodów i zero prywatnych skrzynek kolegów zalewanych testowymi zaproszeniami.
Anatomia przepływu poleceń wartego testowania
Zanim cokolwiek zautomatyzujesz, zapisz zdarzenia, które emituje Twój produkt, i co każde musi zawierać:
- Generowanie kodu: unikalny per polecający, czasem per kanał, z ograniczeniami formatu takimi jak długość, zestaw znaków i rozróżnianie wielkości liter.
- Email udostępnienia: zawiera kod, spersonalizowany link z identyfikatorem kliknięcia albo jedno i drugie.
- Rejestracja z zastosowanym kodem: polecony klika link albo wpisuje kod ręcznie — dwie różne ścieżki kodu.
- Atrybucja: backend przypisuje poleconego do polecającego, zwykle z oknem atrybucji i regułami konfliktów.
- Emaile nagród: typowo dwa, po jednym na stronę, wysyłane, gdy polecony kończy kwalifikującą akcję — nie przy rejestracji.
Większość bugów poleceń mieszka w szwach: kod w emailu niezgodny z wygenerowanym, identyfikator linku zerwany przez redirect, nagrody odpalające przy rejestracji zamiast przy kwalifikacji albo dwa szablony nagród zamienione miejscami.
Wieloskrzynkowy przepływ testowy
1. Postaw skrzynkę A i zarejestruj polecającego. [Utwórz skrzynkę tymczasową](/) albo provisionuj konta przez API, jak opisano w artykule o tymczasowych testowych kontach email dla QA. 2. Wyzwól udostępnienie. Użyj ścieżki zaproszenia mailem z adresem skrzynki B jako odbiorcą. Asertuj, że email udostępnienia przychodzi, i wyciągnij kod oraz link — parser OTP pobiera kody z treści wiadomości bez regexów per szablon. 3. Postaw skrzynkę B jako naprawdę osobną skrzynkę. Wykrywanie samopoleceń to jedna z testowanych rzeczy; upewnij się, że Twój test łapie je celowo, nigdy przypadkiem aliasowania. 4. Dokończ rejestrację poleconego przez link z emaila. Link jest nośnikiem atrybucji; ręczne wpisanie kodu egzekwuje inną ścieżkę. Asertuj atrybucję po stronie serwera — w bazie albo admin API — nie tylko plakietkę w UI. 5. Zweryfikuj emaile nagród dla obu stron. Po akcji kwalifikującej skrzynka A i skrzynka B powinny każda otrzymać własny email z nagrodą. Sprawdź imiona, kwoty i linki osobno; zamienione szablony to klasyczny bug. 6. Przegonij ścieżki negatywne: wygasły kod, kod użyty ponad swój limit, samopolecenie, polecony będący klientem, wygaśnięcie okna atrybucji. Każda powinna dać jasny komunikat, nie ciszę. 7. Powtórz raz z kodem wpisanym ręcznie, by pokryć ścieżkę bez linku.
Kroki od pierwszego do piątego skryptują się czysto pod CI, a plac zabaw API to szybki sposób na zaprototypowanie choreografii dwóch skrzynek, zanim stanie się suitą.
Atrybucja linków: gdzie polecenia po cichu pękają
Wysłany emailem link to krucha część:
- Łańcuchy redirectów — z emaila na domenę trackującą do aplikacji — mogą zgubić parametry query przy każdym hopie. Złap finalny URL lądowania w teście i asertuj, że identyfikator kliknięcia przetrwał.
- First-click kontra last-click: gdy polecony klika dwa różne linki poleceń, o kredycie rozstrzyga Twoja reguła konfliktu. Przetestuj przypadek podwójnego kliknięcia jawnie; prawie nikt tego nie robi.
- Rzeczywistość międzyurządzeniowa: kliknięcie na telefonie, rejestracja na laptopie. Wiele programów gubi tu atrybucję z założenia; zweryfikuj, że udokumentowane zachowanie zgadza się z implementacją.
- Normalizacja kodu: wielkość liter, białe znaki i mylenie zera z literą O. Kod, który działa wklejony, a nie wpisany, to generator zgłoszeń do supportu.
Pułapki wyzwalaczy antyfraudowych
Programy poleceń są agresywnie patrolowane pod kątem nadużyć, a pętla testowa może wyglądać dokładnie jak nadużycie:
- Bursty z jednego IP: dziesiątki rejestracji z jednego runera CI w minuty przypominają farmę fraudową. Izoluj ruch testowy w stagingu albo pozwól listować konta testowe i zakresy IP.
- Blocklisty domen jednorazowych: przepływy poleceń często blokują domeny throwaway właśnie przez nadużycia poleceń. Twoje narzędzie testowe może zostać zablokowane przez feature, który testujesz — oczekuj tego i czytaj jako punkt danych o zachowaniu własnej blocklisty, a nie tajemniczą awarię.
- Reguły prędkości: szybkie pętle generuj-udostępnij-zarejestruj per konto wyzwalają sprawdzenia velocity. Rozsuwaj przebiegi automatyczne albo flaguj konta jako ruch testowy, gdzie system to wspiera.
- Capy nagród: cap na polecającym może po cichu przestać nagradzać po ustalonej liczbie poleconych, co wygląda jak zatrzymanie wysyłki emaili. Sprawdź liczniki, zanim obwinisz potok pocztowy.
Tryb awarii, którego unikać: suite dostaje shadow-flagę, polecenia przestają działać dla jej kont, a Ty zaczynasz zgłaszać bugi mailowe, które w rzeczywistości są werdyktami systemu antyfraudowego.
FAQ
Ile skrzynek potrzebuje test poleceń? Minimum dwie: polecający i polecony. Dodaj trzecią przy testowaniu konfliktów atrybucji — dwóch polecających rywalizujących o jednego poleconego — i używaj świeżych par na przebieg, by wcześniejszy stan nie mógł przeciekać między testami.
Jak wyciągać kody poleceń automatycznie? Pobieraj najnowszą wiadomość z każdej skrzynki i parsuj kod z treści dedykowanym parserem. Asertowanie obecności i formatu kodu jest dużo stabilniejsze niż asertowanie okalającego tekstu, który ciągle się zmienia.
Czy testy poleceń powinny działać w CI przy każdym commicie? Ścieżka szczęśliwa — tak, bo z skrzynkami provisionowanymi przez API jest tania. Scenariusze sąsiednie z fraudem, jak velocity i capy, trzymaj za flagą albo w nocnym środowisku, gdzie celowo dziwny ruch jest bezpieczny.
Jak odróżnić bug mailowy od werdyktu fraudowego? Najpierw prześledź wysyłkę po stronie serwera. Jeśli Twój system nigdy nie zkolejkował emaila, przyczyną jest zwykle reguła — cap, blocklista, sprawdzenie velocity — a nie potok pocztowy. Logi w punkcie decyzji biją zgadywanie od strony skrzynki za każdym razem.
Podsumowanie
Przepływy poleceń mnożą powierzchnie testów emailowych: dwie strony, kilka wiadomości, linki niosące atrybucję i systemy antyfraudowe patrzące na wszystko. Skrzynki jednorazowe czynią setup wielostronny trywialnym — świeże pary na przebieg, kody parsowane programowo, atrybucja asertowana po stronie serwera. Testuj ścieżki negatywne równie rygorystycznie jak szczęśliwą; w systemach poleceń to nieszczęśliwe ścieżki są miejscem, gdzie wycieka pieniądz.