Cypress testing — praktyczny przewodnik po testach end-to-end

Cypress testing to metoda automatyzacji testów end-to-end, w której kod testowy działa w tym samym cyklu zdarzeń co aplikacja, bezpośrednio w przeglądarce. Taka architektura sprawia, że cypress testing daje natychmiastowy podgląd każdego kroku scenariusza, pełny dostęp do obiektu window oraz możliwość podmiany odpowiedzi sieciowych bez uruchamiania osobnego sterownika. Dla zespołów utrzymujących sklepy, panele administracyjne i aplikacje jednostronicowe oznacza to skrócenie pętli zwrotnej z kilkunastu minut do kilkudziesięciu sekund. W tym przewodniku pokazuję, jak zbudować stabilny zestaw testów: od instalacji i struktury katalogów, przez selektory odporne na zmiany w interfejsie, po uruchamianie zadań na własnym serwerze i w pipeline CI/CD. Znajdziesz tu konkretne liczby, koszty w złotówkach, przykłady konfiguracji sprzętowej oraz porównanie z Playwrightem i Selenium — bez teorii, której nie da się przełożyć na codzienną pracę zespołu.

Czym jest cypress testing i jak działa pod maską

Narzędzie instaluje się jako pakiet npm i uruchamia własny serwer proxy, przez który przechodzi cały ruch testowanej aplikacji. Testy wykonują się w kontekście przeglądarki, więc mają bezpośredni dostęp do drzewa DOM, localStorage oraz żądań sieciowych w czasie rzeczywistym. To odróżnia je od rozwiązań komunikujących się z przeglądarką przez zewnętrzny protokół sterujący.

Automatyczne oczekiwanie na elementy usuwa większość ręcznych opóźnień z kodu. Polecenie cy.get ponawia zapytanie przez domyślne cztery sekundy, zanim zgłosi błąd, a cy.intercept pozwala przechwycić żądanie API i podstawić własną odpowiedź. Dzięki temu scenariusz koszyka można przetestować bez działającej bazy danych i bez sztucznych pauz rozsianych po całym pliku.

Ograniczeniem pozostaje model jednej domeny w obrębie pojedynczego testu oraz brak natywnej obsługi wielu kart przeglądarki. W praktyce obchodzi się to poleceniem cy.origin oraz sprawdzaniem linków wychodzących przez zapytania HTTP zamiast fizycznego otwierania nowego okna. Dla większości aplikacji biznesowych to kompromis całkowicie akceptowalny i tani w utrzymaniu.

Cypress, Playwright i Selenium — twarde porównanie

Wybór narzędzia rzadko sprowadza się do samej składni. Decydują: czas zimnego startu, próg wejścia dla juniora, jakość raportów wideo oraz koszt licencji chmurowej przy równoległym uruchamianiu setek scenariuszy. Poniższa tabela zestawia cztery popularne rozwiązania w kryteriach, które faktycznie widać w budżecie i w kalendarzu wydań.

Cypress wygrywa czytelnością komunikatów błędów i wbudowanym runnerem z podglądem stanu aplikacji w każdym kroku. Playwright bierze przewagę tam, gdzie liczy się obsługa wielu przeglądarek naraz i praca w kilku językach programowania. Selenium zostaje przy projektach z historycznym zapleczem oraz wymogiem testowania starszych wersji przeglądarek korporacyjnych.

Stanowisko pracy, które skraca czas pisania testów

Debugowanie scenariuszy E2E to praca na trzech oknach jednocześnie: edytorze kodu, runnerze oraz konsoli przeglądarki. Monitor do komputera o przekątnej 27 cali i rozdzielczości 2560×1440 pikseli, w cenie od około 1200 do 2000 zł, mieści je obok siebie bez ciągłego przełączania. Sama ta zmiana potrafi skrócić analizę nieudanego przebiegu o kilka minut.

Pisanie asercji to tysiące znaków dziennie, więc klawiatura mechaniczna przestaje być gadżetem, a staje się narzędziem pracy. Modele z przełącznikami liniowymi kosztują zwykle 300-800 zł, przy czym klawiatura gamingowa mechaniczna z podświetleniem sprawdza się równie dobrze w edytorze, co w grach. Kompaktowa klawiatura mechaniczna 60 procent zwalnia miejsce na biurku pod myszkę i notatnik.

Tablet graficzny Wacom w wersji Intuos S, dostępny za mniej więcej 350-450 zł, przydaje się przy adnotacjach na zrzutach ekranu z nieudanych testów oraz przy szkicowaniu map przepływów użytkownika. Zespoły mieszane, w których testerzy współpracują z projektantami interfejsu, zyskują wspólny język: obrysowany element na zrzucie zastępuje trzy akapity opisu w zgłoszeniu.

Scenariusze o najwyższym priorytecie biznesowym

Ścieżką krytyczną prawie zawsze jest uwierzytelnianie. Jeśli projekt opiera się na popularnym CMS-ie, scenariusz typu wordpress logowanie powinien sprawdzać nie tylko poprawne dane, ale też komunikat przy błędnym haśle, przekierowanie po zalogowaniu oraz utrzymanie sesji między krokami. Ciasteczka sesji zachowuje się poleceniem cy.session, co skraca kolejne testy o kilka sekund każdy.

Agencje, dla których projektowanie stron internetowych to codzienna praca, zyskują na testach formularzy kontaktowych i konfiguratorów ofert. Jeden scenariusz sprawdzający walidację pola e-mail, wysyłkę oraz komunikat potwierdzenia zabezpiecza przychód z leadów lepiej niż comiesięczny przegląd ręczny. Koszt utrzymania takiego testu to kilkanaście minut pracy na kwartał.

W sklepach internetowych priorytetem jest koszyk i przejście do płatności. Jeśli katalog produktów zasila integracja z Google Merchant, dobrze jest testować spójność ceny i dostępności widocznej na karcie produktu z danymi wysyłanymi do pliku feedu. Rozbieżność w tych dwóch miejscach kończy się odrzuceniem ofert i realną stratą w kampaniach zakupowych.

Czwarty priorytet to wyszukiwarka wewnętrzna i filtry kategorii. Scenariusz może wpisać frazę, zaczekać na odpowiedź API przechwyconą przez cy.intercept i sprawdzić liczbę wyników oraz kolejność sortowania. Takie testy wychwytują regresje po każdej zmianie w indeksie produktowym, zanim zauważy je klient.

Uruchamianie testów w CI/CD i na własnej infrastrukturze

Nie każdy zespół potrzebuje płatnej chmury. Prosty OVH VPS w konfiguracji 2 vCPU i 4 GB RAM, kosztujący od około 30 do 60 zł miesięcznie, obsłuży nocny przebieg stu scenariuszy w trybie headless. Wystarczy obraz Dockera z zainstalowanymi zależnościami przeglądarki oraz zadanie cron uruchamiające polecenie npx cypress run po każdym wdrożeniu.

Raporty muszą trafiać tam, gdzie zespół faktycznie patrzy. Jeśli firma korzysta z pakietu biurowego Google, Workspace cena zaczyna się od mniej więcej 28 zł za użytkownika miesięcznie, a wbudowane narzędzia pozwalają automatycznie wysyłać wynik przebiegu na wspólną skrzynkę i zapisywać nagrania wideo na dysku współdzielonym. Alternatywą jest webhook do komunikatora zespołowego.

Przy większej liczbie testów kluczowa staje się równoległość. Podział zestawu na cztery kontenery skraca przebieg trwający 40 minut do mniej więcej 11-12 minut, bo narzut startowy pozostaje stały. Warunek jest jeden: testy muszą być niezależne, czyli każdy tworzy własne dane wejściowe i sprząta po sobie przez API, a nie przez interfejs.

Testy E2E a wydajność i widoczność strony w wyszukiwarce

Automatyzacja pilnuje rzeczy, które wpływają na ocenę serwisu przez roboty. Scenariusz może sprawdzać obecność tytułu, opisu meta, kanonicznego adresu URL oraz danych strukturalnych na kluczowych podstronach. Konsekwentne pozycjonowanie strony traci sens, jeśli po wdrożeniu nowego szablonu połowa kart produktów gubi znacznik canonical albo zwraca kod 404.

Testy końcowe wychwytują też błędy w przekierowaniach po migracji adresów. Zestaw asercji sprawdzających, że stare URL-e zwracają kod 301 i prowadzą do właściwych odpowiedników, chroni zgromadzony kapitał linkowy. Zespoły odpowiedzialne za pozycjonowanie strony w Google zyskują dowód, że wdrożenie nie zniszczyło struktury serwisu, zanim zrobi to spadek ruchu.

Regresja wizualna i Core Web Vitals

Wtyczki do porównywania zrzutów ekranu wykrywają przesunięcia układu, których nie widać w asercjach tekstowych. Połączenie takiego testu z pomiarem czasu odpowiedzi przechwyconych żądań daje wczesne ostrzeżenie o pogorszeniu wskaźników ładowania. Próg alarmowy ustawia się zwykle na 20 procent odchylenia od wartości bazowej z ostatniego stabilnego wydania.

Jak zacząć pracę z Cypress w istniejącym projekcie

Zacznij od instalacji pakietu poleceniem npm install cypress –save-dev i uruchomienia trybu interaktywnego, który wygeneruje strukturę katalogów oraz plik konfiguracyjny. Pierwszy tydzień poświęć na trzy scenariusze pokrywające ścieżkę przynoszącą pieniądze: wejście na stronę główną, logowanie i finalizację zamówienia lub wysyłkę formularza. Nie próbuj od razu pokryć całej aplikacji, bo zestaw stanie się niestabilny, zanim ktokolwiek zaufa jego wynikom. Dodaj do znaczników HTML dedykowane atrybuty testowe, żeby selektory nie łamały się przy zmianach klas CSS. Dopiero gdy trzy pierwsze testy przechodzą stabilnie przez dwa tygodnie z rzędu, rozszerzaj zakres o kolejne moduły i podłącz cypress testing do pipeline CI.

Czy Cypress nadaje się do testowania sklepów internetowych

Tak, i to jest jedno z jego najmocniejszych zastosowań. Sklep składa się z powtarzalnych ścieżek — listing kategorii, karta produktu, koszyk, dane dostawy, płatność — które da się opisać zestawem kilkunastu scenariuszy pokrywających znaczną część realnego ruchu. Przechwytywanie żądań pozwala symulować odpowiedzi bramki płatniczej bez wykonywania prawdziwej transakcji, co eliminuje koszty i ryzyko testów na środowisku produkcyjnym. Ograniczeniem bywają płatności przekierowujące na zewnętrzną domenę operatora, ale polecenie cy.origin obsługuje ten przypadek. Dodatkowo można weryfikować spójność cen między kartą produktu, koszykiem a danymi eksportowanymi do porównywarek i systemów reklamowych, co zapobiega odrzuceniu ofert.

Co zrobić, gdy testy Cypress są niestabilne

Niestabilność prawie zawsze ma jedną z czterech przyczyn: zależność między testami, sztywne opóźnienia w kodzie, selektory oparte na klasach CSS albo dane współdzielone między przebiegami. Zacznij od usunięcia wszystkich wywołań cy.wait z liczbą milisekund i zastąpienia ich oczekiwaniem na konkretny alias żądania lub na stan elementu. Następnie nadaj każdemu testowi własne dane, tworzone przez API w bloku przygotowawczym, i usuwaj je po zakończeniu. Selektory przenieś na dedykowane atrybuty danych. Jeśli mimo tego pojedynczy scenariusz nadal zawodzi losowo, uruchom go w pętli pięćdziesięciu powtórzeń na czystym środowisku — powtarzalny wzorzec błędu wskaże realny defekt aplikacji, a nie testu.