Jak zaplanować testy regresji sklepu w Playwright: koszyk, sesja, płatność i status zamówienia po błędzie?

Źródła sprawdzone 10 listopada 2026, na dokumentacji Playwright i Stripe.

Ten poradnik jest dla CTO, lidera zespołu albo osoby odpowiedzialnej za jakość sklepu internetowego, która chce, żeby każde wdrożenie sprawdzało ścieżkę zakupu automatycznie. Nie porównuje narzędzi i nie omawia testów aplikacji mobilnych. Opisuje, które scenariusze sklepu warto objąć regresją i jak je ustawić w Playwright.

W skrócie: zacznij od pięciu obszarów, w których błąd kosztuje sprzedaż albo tworzy złe zamówienie. Płatności w CI testuj na symulowanych odpowiedziach dostawcy, a jego ekran płatności sprawdzaj ręcznie w sandboxie. Każdy scenariusz kończ sprawdzeniem stanu zamówienia po stronie serwera. Strona podziękowania mówi tylko, że przeglądarka dotarła pod adres powrotu, a nie że płatność została zaksięgowana.

Plan regresji to nie lista wszystkich możliwych testów, tylko zestaw, który musi przejść przed każdym wdrożeniem. W sklepie najważniejsza jest ścieżka od produktu do opłaconego zamówienia i jej zachowanie przy błędach.

Tabela pokazuje minimalny zakres. Każdy wiersz to kilka testów, a nie jeden długi scenariusz od strony głównej do potwierdzenia.

Regresja płatności działa tylko na środowisku testowym z kluczami trybu testowego dostawcy płatności. Na produkcji nie uruchamiaj testów płacących prawdziwą kartą ani tworzących prawdziwe zamówienia.

Playwright tworzy osobny kontekst przeglądarki dla każdego testu, więc każdy test ma własne ciasteczka i pamięć lokalną. Wykorzystaj to: test nie powinien zależeć od koszyka zostawionego przez poprzedni. Opis: izolacja kontekstów w Playwright.

Logowanie możesz wykonać raz w projekcie przygotowującym i zapisać stan sesji do pliku. Dokumentacja Playwright zaleca dodanie katalogu z tym plikiem do .gitignore i odradza trzymanie go w repozytorium. Gdy testy zmieniają stan po stronie serwera, na przykład koszyk zalogowanego klienta, dokumentacja proponuje osobne konto na każdy równoległy proces. Opis: uwierzytelnianie w Playwright.

• Produkty testowe: kilka produktów o znanej cenie i stanie, także jeden z niskim stanem i jeden z wariantami.
• Konta testowe: osobne konto dla każdego procesu równoległego, jeśli testy zmieniają koszyk zalogowanego klienta.
• Własne dane magazynu i katalogu: test, który zmienia cenę albo stan, używa produktów, z których nie korzysta żaden inny test.
• Reset po stronie serwera: każda próba, także ponowienie, tworzy lub czyści koszyk i potrzebne dane przez API przed startem. Osobny kontekst przeglądarki i osobne konto nie izolują danych współdzielonych na serwerze.
• Klucze testowe: tylko w zmiennych środowiskowych CI, nigdy w kodzie testów.
• Sprzątanie danych: zamówienia testowe oznaczaj tak, żeby dało się je odfiltrować w raportach.

Testy koszyka sprawdzają, czy to, co widzi klient, zgadza się z tym, co zapisał serwer. Po każdej akcji porównaj sumę na stronie z odpowiedzią API koszyka, a nie tylko z tekstem na ekranie.

Testy sesji sprawdzają przejścia między stanami: gość, zalogowany klient, wygasła sesja. Typowe błędy to zniknięcie koszyka po zalogowaniu, zdublowanie pozycji po połączeniu koszyka gościa z koszykiem konta i utrata danych dostawy po wygaśnięciu sesji.

1. Dodanie i zmiana ilości: suma, rabat i koszt dostawy zgodne z serwerem.
2. Zmiana ceny lub stanu w trakcie: zmień cenę albo wyzeruj stan przez API i sprawdź komunikat w koszyku i przy płatności.
3. Odświeżenie strony: koszyk zostaje po przeładowaniu i po zamknięciu karty.
4. Logowanie w trakcie zakupu: koszyk gościa łączy się z koszykiem konta bez dublowania pozycji.
5. Wygasła sesja: po wygaśnięciu sesji klient wraca do koszyka z czytelnym komunikatem, a nie do pustej strony.

Stripe pisze, że interfejsy takie jak Stripe Checkout i Payment Element mają zabezpieczenia uniemożliwiające testy automatyczne, a do sprawdzania zachowania aplikacji zaleca symulowanie odpowiedzi danymi testowymi. Opis: testy automatyczne ze Stripe. Dlatego w CI Playwright sprawdza Twoją aplikację na symulowanych odpowiedziach dostawcy: sukces, odmowa, wymagane 3D Secure i powrót z bramki. Nie automatyzuje ekranu płatności dostawcy.

Ekran dostawcy sprawdzaj ręcznie w sandboxie, zwłaszcza po zmianach w płatnościach. Do tego służą dane testowe. Przykład Stripe: karta 4242 4242 4242 4242 przechodzi, 4000 0000 0000 0002 kończy się ogólną odmową, 4000 0000 0000 9995 odmową z powodu braku środków, a 4000 0027 6000 3184 zawsze wymaga uwierzytelnienia 3D Secure. Opis: dane testowe Stripe. Inni dostawcy mają własne tryby testowe i własne dane, więc sprawdź dokumentację swojego.

Stripe zaznacza, że stan karty z jednego testu może wpłynąć na kolejne testy używające tej samej karty, więc przy ręcznych sprawdzeniach używaj osobnej karty dla każdego niezależnego scenariusza. Osobna, rzadko uruchamiana kontrola kontraktu API może korzystać z sandboxa, z uwzględnieniem limitów zapytań.

Dla każdego wyniku płatności zapisz oczekiwany komunikat dla klienta i oczekiwany stan płatności po stronie sklepu. Test sprawdza oba.

Najczęściej pomijany scenariusz to sytuacja, w której płatność się udała, a przeglądarka nie wróciła do sklepu. Stripe pisze wprost, że nie można opierać realizacji zamówienia wyłącznie na stronie powrotu, bo klient może zapłacić i stracić połączenie, zanim ta strona się załaduje. Realizacja zamówienia wymaga obsługi webhooków. Opis: realizacja zamówień po płatności w Stripe.

Do symulacji tego przypadku w Playwright służy przechwytywanie żądań. Metoda page.route z route.abort pozwala przerwać ładowanie strony powrotu, a route.fulfill podstawić odpowiedź. Potwierdzenie płatności podaj wtedy jako symulowane zdarzenie dostawcy i sprawdź przez API albo panel, że zamówienie i tak ma status opłaconego. Opis: obsługa sieci w Playwright.

Stripe zaznacza też, że ten sam webhook może dotrzeć więcej niż raz, a kolejność zdarzeń nie jest gwarantowana. Opis: webhooki Stripe. Powtórzone zdarzenie sprawdzisz przez ponowną dostawę w sandboxie albo w teście integracyjnym z poprawnie podpisanym zdarzeniem testowym. Asercja dotyczy jednego skutku biznesowego: jednego zamówienia, jednej płatności i jednej rezerwacji.

Dodaj też dwa scenariusze kolejności. W pierwszym przeglądarka wraca przed webhookiem: strona powrotu pokazuje stan oczekujący, a zamówienie przechodzi na opłacone dopiero po potwierdzeniu płatności. W drugim starsze zdarzenie dociera po nowszym i nie cofa stanu zamówienia. Przy metodach płatności z opóźnionym wynikiem stan opłacony ustawia dopiero zdarzenie z ostatecznym wynikiem, w Stripe Checkout na przykład checkout.session.async_payment_succeeded.

Ten obszar zamienia reguły biznesowe w testy. Zanim napiszesz test, zespół musi ustalić, jaki status ma mieć zamówienie w każdym przypadku. Jeśli tej reguły nie ma, test ją ujawni, ale nie powinien jej wymyślać.

Tabela pokazuje przykład reguły. Twoja platforma może używać innych nazw statusów; ważne, żeby każdy wiersz miał jeden oczekiwany wynik.

Playwright domyślnie nie ponawia nieudanych testów. Po włączeniu ponowień test, który najpierw nie przeszedł, a potem przeszedł, jest oznaczany jako niestabilny. Opis: ponawianie testów w Playwright.

Dokumentacja Playwright zaleca w CI ustawienie trace na on-first-retry. Ślad rejestruje wtedy pierwsze ponowienie nieudanego testu, a nie pierwszą próbę. Ponowienie może przejść, więc ślad pokaże udany przebieg; porównaj go z logiem i zrzutem z pierwszej próby. Opis: przeglądarka śladów Playwright.

Niestabilny test płatności traktuj jako sygnał, a nie szum. Często oznacza wyścig między powrotem klienta a webhookiem, czyli dokładnie ten błąd, który może trafić na produkcję.

• Na każdy pull request: krótki zestaw koszyka i jednej udanej płatności na symulowanej odpowiedzi dostawcy.
• Przed wdrożeniem: pełny plan z odmowami, 3D Secure, powrotem z bramki i statusami po błędzie, na symulowanych odpowiedziach; przy zmianach w płatnościach także ręczne sprawdzenie ekranu dostawcy w sandboxie.
• Po wdrożeniu: monitorowanie ścieżki zakupu na produkcji, bez płatności testowych w produkcyjnych kluczach.

Plan obejmuje przeglądarkową ścieżkę zakupu. Nie zastępuje testów jednostkowych logiki cen i rabatów, testów wydajności przed szczytem sprzedaży ani testów aplikacji mobilnej, które wymagają innych narzędzi.

Regresja przed wdrożeniem nie zastępuje też obserwacji produkcji. O tym, jak mierzyć ścieżkę zakupu w czasie szczytów, piszemy w poradniku o obserwowalności sklepu w szczycie sprzedaży.