Każda funkcja wysyłająca maile wychodzi z limitami: capy per użytkownik, by zatrzymać spam, capy per skrzynka, by chronić skrzynki, limity dostawcy, by chronić reputację. Inżynierskie pytanie nigdy nie brzmi, czy limity istnieją — tylko czy zachowują się poprawnie po uderzeniu: czyste błędy, uczciwe nagłówki Retry-After i powiadomienie dla użytkownika, które mówi, co się stało i kiedy następuje reset. Testowanie tego na prawdziwych użytkownikach to dobry sposób na ich utratę. Świeże skrzynki jednorazowe czynią całą tę powierzchnię testowalną, nie mieszając nikomu z planu.
Zmapuj limity, zanim je przetestujesz
Nie możesz asertować względem limitów, których nikt nie zapisał. Najpierw inwentaryzacja:
- Capy per skrzynka: maksimum wiadomości na skrzynkę na okno.
- Capy per konto: maile weryfikacyjne lub resetujące na godzinę na użytkownika — przepływ resetu hasła to miejsce, gdzie pokazuje się to najczęściej, opisany w artykule jak testować emaile resetu hasła.
- Capy per IP i per tenant: limity całej organizacji lub poziomu infrastruktury.
- Limity dostawcy: własne throttlingi Twojego dostawcy wysyłki, których błędy Twoja aplikacja musi przetłumaczyć, a nigdy nie wyciec.
Dla każdego zapisz z konfiguracji lub kodu: okno, cap, akcję przy naruszeniu — kolejka, odrzucenie z 429 albo niestety ciche porzucenie — oraz czy powinien polecieć email powiadamiający. Ta tabela stanie się Twoją checklistą asercji.
Przepływ testu limitów
1. Provisionuj świeżą skrzynkę na przebieg. [Utwórz skrzynkę tymczasową](/) albo provisionuj przez API, jak opisano w artykule o tymczasowych testowych kontach email dla QA. Świeży stan ma znaczenie: resztkowe liczniki to główne źródło mylących wyników. 2. Znajdź rzeczywisty cap. Odczytaj go z konfiguracji. Jeśli nie jest konfigurowalny, probuj, aż zachowanie się zmieni, a potem potwierdź granicę wysyłkami dokładnie-na-limicie oraz limit-plus-jeden. 3. Odpal kontrolowany burst. Uderzaj w endpoint w ciasnej pętli, nagrywając każdą odpowiedź: status, nagłówki, treść. Chcesz pierwszej odpowiedzi stlumionej i dowodu, że wszystkie wcześniejsze były czyste. 4. Zweryfikuj semantykę 429. Prawidłowy kod statusu — nie 500, nie 200 z następującą pustką — maszynowo czytelny Retry-After zgodny z rzeczywistym oknem, stabilny payload błędu, który klienci potrafią parsować, oraz zero częściowych wysyłek: zkolejkowane albo odrzucone, nigdy jedno i drugie. 5. Sprawdź email powiadamiający. Tam, gdzie projekt mówi, że użytkownik dostaje informację — limit zbliża się, limit przekroczony — asertuj, że email przychodzi do skrzynki tymczasowej, podaje limit i czas resetu oraz zgadza się z rzeczywistością. 6. Zweryfikuj odzyskiwanie. Po wygaśnięciu okna wysyłka musi znów działać bez ręcznego odblokowania, a powiadomienie o zdjęciu limitów, jeśli je wysyłasz, musi odpaślić dokładnie raz. 7. Powtórz z ruchem ciągłym tuż pod limitem przez kilka okien; następna sekcja wyjaśnia dlaczego.
Prototypowanie pętli szybciej pójdzie w placu zabaw API, a odbiornik typu tester webhooków łapie nadejścia powiadomień bez opóźnienia pollingu.
Burst kontra ruch ciągły: dlaczego musisz testować oba
Limity to algorytmy, a algorytmy mają kształty. Limiter stałego okna zachowuje się uprzejmie przy strumieniu ciągłym, ale resetuje cały budżet na krawędzi okna — dwa bursty rozłożone na granicy mogą efektywnie podwoić cap. Bucket tokenowy pochłania bursty do rozmiaru bucketa, potem płynnie throttluje. Okno przesuwne jest sprawiedliwsze, ale droższe w weryfikacji. Testujesz jeden kształt ruchu — przetestowałeś jeden tryb, a resztę wydałeś niezweryfikowaną. To samo dotyczy powiadomień: test burstowy pokazuje, czy email o przekroczeniu odpala raz, a test ciągły ujawnia, czy ostrzegasz przy każdej odrzuconej wysyłce, czy raz na okno.
Co asertować
- Status i nagłówki: 429 tam, gdzie udokumentowane, Retry-After zgodny ze skonfigurowanym oknem, obecne nagłówki limitów, jeśli je obiecujesz.
- Stabilność payloadu błędu: kod błędu, po którym rozgałęziają się klienci, nie może dryfować między wydaniami; przypnij go testem.
- Treść powiadomienia: wartość limitu, czas resetu i droga naprzód są obecne, a czas resetu zgadza się z zaobserwowanym zachowaniem.
- Deduplikacja: dokładnie jeden email o przekroczeniu na okno — nie jeden na odrzucone żądanie.
- Higiena stanu: po odzyskaniu zwykła wysyłka działa, a liczniki nie przeciekają między użytkownikami ani skrzynkami.
- Zero cichych porzuceń: każda wysyłka jest doręczona, zkolejkowana albo jawnie odrzucona, a odrzucenia widać w logach.
Typowe fałszywe pozytywy
- Brudne liczniki: wczorajszy test zjadł dzisiejszy budżet, limiter odpala za wcześnie, a bug zgłaszasz sam sobie. Świeża skrzynka i świeże konto na przebieg.
- Throttling dostawcy mylony z throttlingiem aplikacji: błąd limitu dostawcy wynurza się jako Twoje 429. Sprawdź, która warstwa odrzuciła wysyłkę, zanim coś zgłosisz; logi wysyłki zwykle rozstrzygają jednym rzutem oka.
- Przekrzywienie zegara na granicach: jeśli maszyna testowa i limiter się rozjeżdżają w czasie, testy graniczne flappersują. Prowadź asercje ze znaczników czasu serwera w odpowiedziach, gdzie się da.
- Równoległe suity dzielące cap tenanta: dwa pipeline'y naraz rozdzielają jeden budżet i oba widzą throttling wcześniej, niż się spodziewały.
FAQ
Jak testować limity bez prawdziwego dostawcy w pętli? Skieruj staging na sink albo mocka do czystej logiki limitera, ale utrzymaj przynajmniej jedną ścieżkę przez prawdziwy potok — same emaile powiadamiające potrzebują prawdziwego doręczenia do weryfikacji, i właśnie tu skrzynki jednorazowe zarabiają na siebie.
Czy email o przekroczeniu limitu powinien iść do skrzynki, która limit przekroczyła? Zazwyczaj tak, jeśli ta skrzynka jeszcze potrafi odbierać. Jeśli cap siedzi wyżej, wyślij na główny adres konta. Nigdy nie może się zdarzyć, by powiadomienie zostało po cichu zablokowane przez limiter, o którym donosi — zwolnij powiadomienia systemowe z limitów per użytkownik i przetestuj to zwolenienie jawnie.
Jaka asercja jest najczęściej pomijana? Odzyskiwanie. Zespoły hammerują throttling i nigdy nie weryfikują, że po oknie wysyłka znów działa albo że liczniki resetują się per skrzynka, a nie globalnie.
Ile wysyłek potrzebuje każdy test? Wystarczająco, by przekroczyć granicę z obu stron: dokładnie na limicie, limit plus jeden i jeden burst wyraźnie poza nim. Jeśli cap jest duży, zrób go konfigurowalnym w środowiskach testowych zamiast wysyłać tysiące prawdziwych wiadomości.
Podsumowanie
Rate limiting to funkcja z interfejsem użytkownika, a dużą częścią tego interfejsu jest email: ostrzeżenia o limitach, powiadomienia o przekroczeniu, potwierdzenia resetu. Testuj limity jak każdy inny kontrakt — burstem i ruchem ciągłym, dokładnie na granicy, asertując kody statusów, nagłówki, stabilność payloadu oraz treść i czas emaili powiadamiających. Świeże skrzynki jednorazowe na przebieg utrzymują czysty stan liczników, więc mierzysz limiter, a nie resztki.