Cypress News 2026 – wydanie v. 16

Cypress News 2026 – wydanie v. 16 – to wpis w którym będę przedstawiał Wam news związany z migracją Cypressa i zmianami przy wersji 16. Jeżeli jesteś zainteresowany innymi wpisami dotyczącymi Cypressa, zapraszamy do odpowiedniego działu.

Wprowadzenie

Tworząc testy automatyczne z wykorzystaniem Cypressa może spotkać się z sytuacjami, że bziemy potrzebowali dodatkowego wsparcia by napisać nasze testy. Czasami będzie to spowodowane faktem niemożności obsłużenia w inny sposób danego przypadku, czasami też po prostu skorzystanie z pluginów będzie dla nas łatwiejsze.

Jako Ambasador Cypressa mam na celu rozpowszechnianie wiedzy o tym narzędziu, promowanie wartości jakie nam przyświecają.

 

Cypress 16 – szybsze testy, HTTP/2 i kilka zmian, których nie warto przegapić

Cypress 16.0.0 został wydany 1 września 2026 roku. To duże wydanie, ale nie takie, które sprowadza się wyłącznie do aktualizacji numeru w package.json. Z jednej strony otrzymujemy szybsze wykonywanie testów, obsługę HTTP/2 i HTTP/3 oraz lepsze zarządzanie pamięcią. Z drugiej – pojawiają się zmiany, które mogą dotknąć konfigurację, integrację z siecią, sposób pracy ze zmiennymi środowiskowymi i starsze custom commands.

Najważniejsza wiadomość jest jednak dobra: dla wielu projektów aktualizacja nie będzie oznaczała przepisywania całego zestawu testów. Warto jednak potraktować ją jak każdą zmianę majorową: najpierw przejrzeć zależności i kod, potem wykonać migrację na osobnej gałęzi, a na końcu uruchomić pełen zestaw testów lokalnie i w CI.

HTTP/2 i natywna sieć przeglądarki

Największą zmianą w Cypressie 16 jest nowy sposób obsługi ruchu sieciowego w Chrome, Chromium i Edge. Cypress korzysta tam z natywnego mechanizmu sieciowego przeglądarki, a aplikacja komunikuje się z serwerem tak, jak w realnym użyciu – przez HTTP/1.1, HTTP/2 lub HTTP/3, zależnie od tego, co obsługuje serwer.

To ważne z kilku powodów:

• testy lepiej odzwierciedlają faktyczne zachowanie aplikacji u użytkownika;
• HTTP/2 umożliwia multipleksowanie zapytań i znosi limit sześciu równoległych połączeń;
• Cypress nie kończy już TLS po swojej stronie, więc przeglądarka waliduje rzeczywisty certyfikat originu;
• nowoczesne aplikacje mogą szybciej ładować zasoby również podczas testów.

W swoim benchmarku Cypress porównał stronę ładującą 1000 obrazów. Przy HTTP/2 jej załadowanie zajęło 1362 ms, a przy HTTP/1.1 – 3896 ms. Nie oznacza to oczywiście, że każda aplikacja przyspieszy dokładnie w takim samym stopniu, ale w projektach wykonujących dużo małych requestów różnica może być zauważalna zarówno lokalnie, jak i w CI.

To może być też istotne dla aplikacji korzystających ze streamingu. Limity HTTP/1.1 utrudniały testowanie rozwiązań opartych na Server-Sent Events, np. powiadomień live, feedów aktywności czy wskaźników postępu uploadu. HTTP/2 pozwala na większą liczbę równoległych strumieni, więc warto ponownie przyjrzeć się takim scenariuszom testowym.

cy.intercept() nadal działa, podobnie jak aliasy, stubowanie i oczekiwanie na requesty. Trzeba jednak sprawdzić testy, które asercjami wchodzą w bardzo techniczne szczegóły odpowiedzi. W nowym trybie req.httpVersion nie jest raportowane, nagłówki kompresji nie są dostępne w przechwyconej odpowiedzi, a odpowiedź wcześniej raportowana jako 304 może zostać pokazana jako 200. W HTTP/2 i HTTP/3 res.statusMessage będzie też pustym stringiem, ponieważ te protokoły nie korzystają z reason phrase.

Większość zestawów testów nie będzie wymagała żadnych zmian. Warto jednak szczególnie przejrzeć asercje dotyczące transportu HTTP, nagłówków oraz konkretnych kodów odpowiedzi po rewalidacji cache.

Zmiana dotyczy obecnie przeglądarek opartych na Chromium. Firefox, WebKit i Electron nadal korzystają z dotychczasowej ścieżki sieciowej.

Jeżeli po aktualizacji coś nie działa, istnieje opcja forceHttp1: true, która czasowo przywraca stary mechanizm. Nie traktowałbym jej jednak jako docelowego rozwiązania – jest od razu oznaczona jako przestarzała i ma być tylko pomocą w migracji.

Szybciej, ale sprawdź testy zależne od czasu

Cypress 16 zmienia domyślny keystrokeDelay dla cy.type() z 10 ms na 0 ms. To bardzo sensowna optymalizacja, szczególnie w zestawach, które intensywnie wypełniają formularze. Jednocześnie może ujawnić testy, które przez przypadek polegały na tym małym, ukrytym opóźnieniu.

Jeżeli konkretny komponent nie nadąża z obsługą wprowadzanych znaków, nie warto od razu przywracać opóźnienia globalnie. Najpierw sprawdźmy, czy nie jest to realny problem aplikacji albo źle zsynchronizowany test. Gdy potrzebujemy tymczasowego obejścia, opóźnienie można ustawić lokalnie:

cy.get('[name=search]').type('Cypress 16', { delay: 10 })

Cypress 16 domyślnie korzysta też z nowoczesnego algorytmu widoczności opartego na przeglądarkowym Element.checkVisibility(). Następnie Cypress sprawdza zasłonięcie elementu adaptacyjnym próbkowaniem punktów. Takie podejście ma ograniczyć kosztowne przeliczanie layoutu, szczególnie w dużych i głęboko zagnieżdżonych aplikacjach.

Efekt ma być korzystny dla wydajności, ale mogą ujawnić się testy oparte na szczegółach starego algorytmu, np. w przypadkach overflow, transformacji czy elementów fixed/sticky. Starszą strategię można chwilowo włączyć przez visibilityStrategy: 'legacy', jednak to również jest wyłącznie ścieżka migracyjna.

Mniej ręcznych waitów przy cookies i storage

Dobra zmiana dla stabilności testów: cy.getCookie(), cy.getCookies(), cy.getAllCookies(), cy.getAllLocalStorage() i cy.getAllSessionStorage() stają się query commands. Oznacza to, że przy asercji dołączonej przez .should() Cypress będzie ponawiał odczyt do czasu sukcesu lub przekroczenia defaultCommandTimeout.

Przykład podejścia, które warto zmienić:

// Odczyt jednorazowy - callback .then() nie będzie ponawiany
cy.getCookie('session_id').then((cookie) => {
  expect(cookie).to.have.property('value', 'abc123')
})

W Cypressie 16 lepiej skorzystać z bezpośredniej asercji:

// Cypress odczyta cookie ponownie, aż asercja przejdzie lub nastąpi timeout
cy.getCookie('session_id').should('have.property', 'value', 'abc123')

To nie oznacza, że .then() znika – nadal jest właściwe wtedy, gdy celowo chcemy wykonać jednorazowy odczyt, np. potwierdzić, że cookie jeszcze nie istnieje. Warto też pamiętać, że jeśli nadpisywaliście te komendy, należy przejść z Cypress.Commands.overwrite() na Cypress.Commands.overwriteQuery().

To potencjalnie mniej flaky testów, mniej niepotrzebnych retry i mniej ponownych uruchomień pipeline’u tylko dlatego, że cookie lub storage zostały zapisane kilka milisekund później.

Cypress.env() znika. Rozdzielmy wartości publiczne od sekretów

To jedna z najistotniejszych zmian wymagających pracy w kodzie. Cypress.env() zostało usunięte. Wcześniej wszystkie skonfigurowane wartości środowiskowe były dostępne w kontekście przeglądarki. Oznaczało to ryzyko, że sekret – nawet taki, którego test w ogóle nie używa – mógł zostać odczytany przez kod aplikacji, zewnętrzny skrypt lub kontekst cross-origin.

Cypress rozdziela teraz dwa przypadki użycia:

• Cypress.expose() oraz pole expose w konfiguracji – dla wartości niesekretnych, które mogą być dostępne w przeglądarce, np. publicznego URL-a lub feature flaga;
• cy.env() – dla danych wrażliwych, takich jak tokeny, hasła czy klucze, które powinny pozostać po stronie procesu Node.

To dobry kierunek, ponieważ zmusza nas do świadomego rozróżnienia: co test rzeczywiście musi ujawnić aplikacji uruchomionej w przeglądarce, a co powinno pozostać sekretem. Przy migracji warto wyszukać nie tylko Cypress.env(), ale też flagi --env, użycia w cy.origin() oraz pluginy i custom commands, które mogły korzystać ze starego API.

Warto też odnotować drobną, ale praktyczną zmianę bezpieczeństwa: cypress info nie wyświetla już zmiennych proxy ani zmiennych CYPRESS_*. Dzięki temu wynik tej komendy można bezpieczniej wkleić do publicznego zgłoszenia błędu.

Usunięte komendy i zmiany w konfiguracji

Kolejne konkretne punkty do sprawdzenia to:

• cy.exec() zostało usunięte – kod wykonywany po stronie Node przenosimy do cy.task() i rejestrujemy w setupNodeEvents;
• cy.end() zostało usunięte – w większości przypadków wystarczy je skasować;
• experimentalMemoryManagement zastępuje manageBrowserMemory, domyślnie ustawione na true w przeglądarkach Chromium;
• nie można już podczas wykonywania testu zmieniać viewportWidth, viewportHeight ani blockHosts przez Cypress.config() – użyjmy cy.viewport() lub konfiguracji danego describe/it;
• experimentalSourceRewriting zostało usunięte – dla części projektów korzystających z tej opcji pojedynczy cy.visit() mógł być przez nią od pięciu do dziesięciu razy wolniejszy;
• znika wbudowana obsługa CoffeeScript;
• Electron został oznaczony jako przestarzała przeglądarka testowa, więc warto już teraz planować przejście na Chrome, Edge, Firefox lub WebKit.

Jest też wymaganie środowiskowe: Cypress 16 nie obsługuje Node.js 20 ani 25. Potrzebujemy Node.js 22.x, 24.x lub 26+. W przypadku Component Testing podniesione zostały również minimalne wersje Angulara (21), Vite (8) i Next.js (15.0.4).

Warto pamiętać, że manageBrowserMemory nie jest automatycznym przyspieszeniem każdego zestawu. Przy długich specach i w kontenerach CI z ograniczoną pamięcią powinno ograniczyć degradację wydajności oraz crashe renderera. W lekkim zestawie czyszczenie pamięci może jednak oznaczać dodatkowy narzut, dlatego warto mierzyć czas wykonania przed i po zmianie.

Moja pierwsza migracja do Cypressa 16

Jestem już po migracji jednego małego projektu do Cypressa 16. Było to repozytorium typowo migracyjne, ale nie minimalistyczne – zawierało sporo pluginów rozszerzających możliwości Cypressa i wspierających różne rodzaje testów.

Właśnie dlatego, poza samą aktualizacją Cypressa, trzeba było też zweryfikować kompatybilność dodatków. W moim przypadku, aby projekt działał po migracji, musiałem usunąć dwa pluginy:

• cypress-axe
• cypress-real-events

To dobry przykład, że nawet w niewielkim projekcie aktualizacja majorowa nie powinna oznaczać wyłącznie zmiany wersji w package.json. Im więcej pluginów, custom commands, testów API i konfiguracji CI/CD, tym bardziej migracja powinna być świadomym zadaniem technicznym, a nie szybkim npm update.

Przy takich działaniach zawsze warto najpierw przeanalizować wpływ zmiany, a następnie aktualizować pojedyncze elementy i po każdej zmianie uruchamiać testy. Dzięki temu łatwiej zidentyfikować źródło problemu – czy wynika ono z samego Cypressa, konfiguracji, pluginu czy konkretnego testu.

Praktyczna checklista migracji

Przed podniesieniem wersji do 16 proponuję przejść przez krótką checklistę:

1. Zweryfikuj wersję Node.js w lokalnym środowisku oraz w CI.
2. Zaktualizuj Cypress z wersji 15.x – majorowe wersje najlepiej podnosić kolejno.
3. Wyszukaj w projekcie: Cypress.env, cy.exec, cy.end, experimentalMemoryManagement, experimentalFastVisibility, experimentalSourceRewriting, execTimeout oraz Cypress.config(.
4. Przejrzyj testy z cy.intercept(), szczególnie te sprawdzające wersję HTTP, nagłówki kompresji, status 304 i res.statusMessage.
5. Zweryfikuj pluginy oraz ich kompatybilność z Cypress 16.
6. Sprawdź testy z cy.type(), asercjami widoczności, cookies i storage.
7. Uruchom npx cypress verify, a następnie pełny zestaw testów lokalnie i w CI.
8. Wykorzystaj gotowy prompt migracyjny przygotowany przez Cypress w swoim asystencie AI, ale przed zastosowaniem zmian zawsze przejrzyj proponowany diff.
9. Nie zostawiaj na stałe forceHttp1: true ani visibilityStrategy: 'legacy' – potraktuj je wyłącznie jako czasowe wsparcie diagnostyczne.

Podsumowanie tematu update do v. 16

Cypress 16 to wydanie, które realnie rozwija narzędzie w kierunku szybszych i bardziej zbliżonych do produkcji testów. HTTP/2 i natywna obsługa sieci, szybsze wpisywanie tekstu, nowa obsługa widoczności, retry dla cookies i storage oraz zarządzanie pamięcią powinny pomóc zarówno w czasie wykonania, jak i w ograniczaniu flakiness.

Jednocześnie aktualizacja wymaga porządku w projekcie. Najwięcej uwagi warto poświęcić Cypress.env(), cy.exec(), konfiguracji wykonywanej w runtime, detalom cy.intercept() oraz używanym pluginom. Jeśli podejdziemy do tego jak do normalnej migracji majorowej – z analizą, checklistą i pełnym uruchomieniem testów – Cypress 16 może dać bardzo konkretną wartość bez niepotrzebnego ryzyka.

Oficjalne materiały: changelog Cypress 16, migration guide do Cypress 16, gotowy prompt do migracji z pomocą AI oraz artykuł Cypress o wersji 16.

Cypress Cloud – Ile można realnie zaoszczędzić?

Cypress udostępnił również Savings Calculator, który pozwala oszacować potencjalne oszczędności na podstawie wielkości zespołu, liczby uruchomień tygodniowo i rozmiaru zestawu testów. Kalkulator uwzględnia krótsze runy dzięki Smart Orchestration, szybsze debugowanie przez Test Replay, ograniczanie kosztów flaky testów, Test Generation oraz Cloud MCP. Warto potraktować go jako punkt wyjścia do rozmowy o efektywności, a nie uniwersalną obietnicę – wynik opiera się na założeniach, które można sprawdzić i edytować. Co istotne, kalkulator nie wycenia korzyści takich jak uniknięte incydenty produkcyjne, lepsze pokrycie UI czy automatyczne sprawdzanie dostępności, mimo że w praktyce to właśnie one mogą mieć dla organizacji największą wartość.

Nowości video

W ramach swojej działalności przedstawiam Wam też ciekawe video – w celu inspiracji i rozwoju.

Obrazy dockerowe

Na dockerhub udostępnione są różne obrazy dockerowe dla Cypressa. Skorzystaj już dzisiaj:

Image Name	Description	Monthly pulls
cypress/factory	A base image template which can be used with ARGs to create a custom docker image.
cypress/base	All operating system dependencies, no Cypress, and no browsers.
cypress/browsers	All operating system dependencies, no Cypress, and some browsers.
cypress/included	All operating system dependencies, Cypress, and some browsers installed globally.

Dołącz do społeczności

Jesteście zainteresowani byciem na bieżąco z nowinkami związanymi z Cypressem. Chcesz pogadać z Ambasadorami, twórcami lub innymi fanami Cypressa – dołącz do naszej społeczności na Discordzie już teraz. Jest nas blisko 25000 i społeczność systematycznie rośnie.

Znalazłeś buga?

Masz problem z działaniem frameworka, chcesz zgłosić nam błąd? Dołącz do Githuba i zgłoś błąd lub zaproponuj nam zmiany jako Feature.

Skorzystaj z rozwiązania cloudowego

Cypress posiada rozwiązanie cloudowe które możecie wykorzystywać w swoich projektach – sprawdź już teraz. 

Szkolenie z Cypressa dla Twojej firmy?

Napisz na szkolenia@dlatesterow.pl i skorzystaj z wiedzy Ambassadora Cypressa aby wdrożyć automatyzację testów w swojej organizacji.

1 dniowe szkolenie – dedykowane Waszej aplikacji, aby uczestnicy mogli pracować na realnych przykładach.

2 dniowe szkolenie – z poszerzonymi informacjami i ćwiczeniami, również może być oparte na Waszej aplikacji.

Oczywiście możemy pracować z materiałami z jakimi pracuje na co dzień. 
To nie jest szkolenie jakich na rynku jest wiele – nieaktualizowane informacje, wersje czy standardy, oraz przykłady na randomowych stronach. Tylko dlaTesterów.PL prowadzi szkolenia dedykowane organizacji – dodatkowo w cenach wysoko-konkurencyjnych. 

Opis standardowego szkolenia – na naszym portalu szkoleniowym. 

Podsumowanie

Cypress News 2026 – wydanie v. 16 – to kolejny wpis mający zachęcić Was do instalacji i sprawdzenia narzędzia. Z racji popularyzacji narzędzia i dużego wsparcia które otrzymał Cypress na rozwój, będziemy poszerzać wpisy na ten temat. Wszelkie artykuły związane z Cypress IO znajdziecie w dedykowanym dziale.