Selenium WebDriver vs Cypress: ten sam test w obu narzędziach i kiedy które wybrać

Cypress i Selenium WebDriver to dwa otwarte narzędzia do automatyzacji testów aplikacji webowych: Selenium steruje przeglądarką z zewnątrz przez standard W3C WebDriver i obsługuje wiele języków, a Cypress uruchamia testy wewnątrz przeglądarki, w JavaScripcie albo TypeScripcie. Poniżej znajdziecie aktualne wersje sprawdzone 10 października 2026 roku, ten sam test napisany w obu narzędziach i uruchomiony, listę mitów, które krążą w starszych porównaniach, oraz tabelę wyboru.

Ten tekst to pojedynek dwóch narzędzi, napisany dla Was, jeśli wybór dotyczy właśnie tej pary. Jeśli szukacie pełnego porównania trzech frameworków, z Playwrightem jako równorzędnym kandydatem, przeczytajcie najpierw nasz przewodnik Selenium, Cypress czy Playwright: porównanie narzędzi do automatyzacji testów. Playwright pojawia się tu jako punkt odniesienia, bo w 2026 roku trudno uczciwie porównać Selenium z Cypressem bez niego.

Czym różni się Cypress od Selenium WebDriver w 2026 roku?

Różnią się miejscem, w którym działa kod testu, a z tego wynika prawie wszystko inne: języki, przeglądarki, obsługa wielu kart, sposób czekania na elementy i raporty. Oba narzędzia są aktywnie rozwijane. Według changelogu Cypress wersja 16.0.0 wyszła 1 września 2026 roku i wymaga Node.js 22, 24 albo co najmniej 26, a Selenium wypuszcza nowe wersje co kilka tygodni. Starsze porównania, które piszą o „Selenium 3” albo „Cypressie tylko dla Chrome”, opisują więc narzędzia, których już nie ma.

Jak działa architektura obu narzędzi i co z niej wynika?

Selenium WebDriver wysyła polecenia do sterownika przeglądarki (chromedriver, geckodriver, msedgedriver) według standardu W3C WebDriver, a coraz częściej także przez nowszy protokół WebDriver BiDi. Test jest osobnym programem, który może być napisany w Javie, Pythonie, C#, JavaScripcie, Ruby albo Kotlinie. Według dokumentacji Selenium od wersji 4.6 każde wydanie zawiera Selenium Manager, narzędzie dołączone do każdego wydania, które samo pobiera właściwy sterownik, a w razie potrzeby także przeglądarkę. Więcej o podstawach znajdziecie w tekście Selenium: co to jest i od czego zacząć.

Cypress działa inaczej: kod testu wykonuje się w tej samej przeglądarce co aplikacja, a obok pracuje proces Node.js do zadań poza przeglądarką. Dzięki temu Cypress ma bezpośredni dostęp do DOM, ruchu sieciowego i obiektów aplikacji, automatycznie ponawia asercje i daje podgląd każdego kroku. Ta sama architektura stawia trwałe granice, które dokumentacja Cypress opisuje w sekcji o kompromisach: jednym testem nie sterujecie dwiema przeglądarkami naraz, test jest związany z jedną domeną nadrzędną, a przejście na inną domenę wymaga polecenia cy.origin().

Co jest nieaktualne w popularnych porównaniach Selenium i Cypress?

Kilka zdań powtarzanych od lat w artykułach i na rozmowach rekrutacyjnych jest dziś po prostu nieprawdą. Nasz własny tekst miał ich kilka, dlatego poniżej zestawiamy je uczciwie, z tym, co mówi aktualna dokumentacja.

Prawdziwe ograniczenia Cypress są inne niż te z mitów: brak sterowania dwiema przeglądarkami naraz, brak natywnej obsługi wielu kart i ograniczona obsługa ramek iframe, które dokumentacja Cypress sama nazywa „nieco ograniczoną, ale działającą”. Prawdziwe koszty Selenium to więcej kodu infrastruktury, jawne oczekiwania i osobna warstwa raportowa. O tym, jak dobrze pisać oczekiwania, piszemy w tekście explicit wait i implicit wait w Selenium.

Jak wygląda ten sam test w Selenium, Cypress i Playwright?

Wybraliśmy prosty scenariusz na oficjalnej stronie ćwiczeniowej projektu Selenium: wpisanie tekstu w pole formularza, wysłanie go i sprawdzenie komunikatu „Received!”. Każdy z trzech testów uruchomiliśmy 10 października 2026 roku na macOS w Chrome 154 w trybie bez okna, na wersjach podanych w komentarzach. Wszystkie trzy przeszły, ale po drodze każde narzędzie pokazało swój charakter.

Selenium WebDriver w Javie

// Java 21, Selenium 4.51.0, JUnit 5.13.4
package pl.qi;

import static org.junit.jupiter.api.Assertions.assertEquals;

import java.time.Duration;
import org.junit.jupiter.api.AfterEach;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;
import org.openqa.selenium.By;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.chrome.ChromeDriver;
import org.openqa.selenium.chrome.ChromeOptions;
import org.openqa.selenium.support.ui.ExpectedConditions;
import org.openqa.selenium.support.ui.WebDriverWait;

class FormularzTest {

    private WebDriver driver;

    @BeforeEach
    void start() {
        ChromeOptions opcje = new ChromeOptions();
        opcje.addArguments("--headless=new", "--window-size=1280,1000");
        driver = new ChromeDriver(opcje); // Selenium Manager sam dobiera sterownik
    }

    @Test
    void wyslanieFormularzaPokazujePotwierdzenie() {
        driver.get("https://www.selenium.dev/selenium/web/web-form.html");
        driver.findElement(By.name("my-text")).sendKeys("Quality Island");
        driver.findElement(By.cssSelector("button[type='submit']")).click();

        String komunikat = new WebDriverWait(driver, Duration.ofSeconds(5))
                .until(ExpectedConditions.visibilityOfElementLocated(By.id("message")))
                .getText();
        assertEquals("Received!", komunikat);
    }

    @AfterEach
    void stop() {
        driver.quit();
    }
}

Cypress w TypeScripcie

// TypeScript, Cypress 16.1.1, plik cypress/e2e/formularz.cy.ts
describe('Formularz', () => {
  it('wysłanie formularza pokazuje potwierdzenie', () => {
    cy.visit('https://www.selenium.dev/selenium/web/web-form.html');
    cy.get('[name="my-text"]').type('Quality Island');
    cy.contains('button', 'Submit').click();
    cy.get('#message').should('have.text', 'Received!');
  });
});

Cypress 16.1.1 przeszedł test w 541 ms. Zanim do tego doszło, pierwsze uruchomienie zatrzymało się na błędzie TsConfigNotFoundError, bo bez pliku tsconfig.json Cypress nie kompiluje testów w TypeScripcie. Wystarczył minimalny plik konfiguracyjny. Dodatkowo npm ostrzegł nas, że Node.js 25 nie jest wspieraną wersją, co zgadza się z wymaganiami Cypress 16; w CI używajcie Node.js 22 albo 24.

{
  "compilerOptions": { "target": "es2022", "lib": ["es2022", "dom"], "types": ["cypress"] },
  "include": ["**/*.ts"]
}

Playwright w TypeScripcie

// TypeScript, @playwright/test 1.64.0, plik tests/formularz.spec.ts
import { test, expect } from '@playwright/test';

test('wysłanie formularza pokazuje potwierdzenie', async ({ page }) => {
  await page.goto('https://www.selenium.dev/selenium/web/web-form.html');
  await page.locator('[name="my-text"]').fill('Quality Island');
  await page.getByRole('button', { name: 'Submit' }).click();
  await expect(page.locator('#message')).toHaveText('Received!');
});

Według rejestru npm wersja 1.64.0 wyszła 7 października 2026 roku, a w naszym uruchomieniu przeszła test w 1,2 s razem ze startem przeglądarki. Użyliśmy zainstalowanego Chrome (opcja channel: 'chrome' w konfiguracji), więc nie trzeba było pobierać osobnych przeglądarek. Czasy podajemy jako opis przebiegu, nie jako benchmark: jeden test na jednej maszynie nie mówi nic o szybkości dużego zestawu. Kto wybiera framework na podstawie jednego testu z formularzem, ten wybiera też samochód po tym, jak szybko otwierają się drzwi.

Czy Cypress nadaje się do testów API?

Tak, do prostych sprawdzeń i do przygotowania danych dla testów interfejsu. Polecenie cy.request() wysyła żądanie HTTP bez otwierania strony, więc w jednym zestawie możecie założyć użytkownika przez API, a potem sprawdzić jego panel w przeglądarce. Poniższy test uruchomiliśmy tego samego dnia na publicznym API JSONPlaceholder; przeszedł w 128 ms.

// TypeScript, Cypress 16.1.1: test API bez otwierania strony
describe('API bez przeglądarki', () => {
  it('zwraca wpis o id 1', () => {
    cy.request('https://jsonplaceholder.typicode.com/posts/1').then((odp) => {
      expect(odp.status).to.eq(200);
      expect(odp.body).to.have.property('id', 1);
    });
  });
});

Do rozbudowanych zestawów testów API, z kontraktami, wieloma środowiskami i setkami przypadków, nadal lepiej sprawdzają się narzędzia stworzone do tego celu, na przykład REST Assured w Javie albo Postman z kolekcjami w CI, które opisujemy w tekście Postman: co to jest i jak zacząć. Jeśli chcecie takie testy zbudować z zespołem, zajmujemy się tym w ramach automatyzacji testów API.

Gdzie w tym porównaniu jest Playwright?

Playwright łączy cechy obu narzędzi: jak Selenium obsługuje kilka języków (JavaScript i TypeScript, Python, Java, .NET) i kilka kart czy kontekstów przeglądarki w jednym teście, a jak Cypress automatycznie czeka na elementy. Według dokumentacji Playwright uruchamia testy w Chromium, Firefoksie i WebKit oraz w markowych Chrome i Edge. Skalę zainteresowania pokazują statystyki npm: według nich od 9 września do 8 października 2026 roku pakiet @playwright/test pobrano około 305,6 mln razy, cypress 29,5 mln, a selenium-webdriver 9,3 mln. Te liczby obejmują tylko ekosystem JavaScriptu i każdą instalację w CI, więc nie mówią, ile zespołów pisze w Selenium w Javie czy Pythonie.

W naszej praktyce szkoleniowej widać ten sam kierunek: w 2026 roku zamknięte szkolenia z Playwrighta prowadziliśmy między innymi dla zespołów BNP Paribas Bank Polska, Benefit Systems i ORLEN, a jednocześnie szkolimy z Selenium WebDriver, na przykład w czerwcu 2026 roku z automatyzacji testów aplikacji webowych dwie osoby z Centralnego Ośrodka Informatyki. Zespoły z dużym, działającym zestawem testów w Javie rzadko mają powód, żeby go przepisywać. Dlaczego Selenium nie zniknęło mimo zapowiedzi, ciekawie analizuje Strefa QA w tekście o Selenium w 2026 roku. Pełną tabelę trzech narzędzi w dwunastu kryteriach znajdziecie w porównaniu Selenium, Cypress czy Playwright.

Kiedy wybrać Selenium WebDriver, a kiedy Cypress?

Wybierzcie narzędzie do Waszego zespołu i Waszego produktu, nie do mody. Wasze kryteria to język, w którym piszą Wasi testerzy, przeglądarki Waszych użytkowników i to, ile kart otwiera typowy scenariusz. Poniższa tabela zbiera sytuacje, które u naszych klientów najczęściej rozstrzygają wybór między Selenium WebDriver a Cypress.

Niezależnie od wyboru najwięcej kosztuje Was utrzymanie, nie start. Jak podaje case study Argos, w projekcie dla tego klienta automatyzacja testów i uporządkowanie procesów QA skróciły regresję przed wydaniem z 5 dni do 10 godzin, a napisaliśmy już ponad 450 000 testów automatycznych, więc wiemy, że o sukcesie decyduje architektura testów, a nie logo na pakiecie. Jeśli potrzebujecie pomocy przy wyborze albo budowie frameworka, robimy to w ramach automatyzacji testów UI. Zespół, który chce pisać testy sam, przeszkolimy na kursie automatyzacja testów Selenium WebDriver, automatyzacja testów w Cypress albo automatyzacja testów z Playwright.

Powiązane na blogu Quality Island

• Selenium, Cypress czy Playwright: porównanie narzędzi do automatyzacji testów
• Selenium: co to jest, jak działa i od czego zacząć
• Explicit wait i implicit wait w Selenium WebDriver
• Testy end to end (E2E): co to jest i kiedy je uruchamiać
• Zalety i wady automatyzacji testów

Pełna lista źródeł

• Selenium, Selenium Manager, dokumentacja 2026. Stąd automatyczne zarządzanie sterownikami od wersji 4.6.
• Selenium, WebDriver BiDi, dokumentacja 2026.
• W3C, WebDriver, Working Draft, 2026.
• Maven Central, org.seleniumhq.selenium:selenium-java, odczyt 10.10.2026, wersja 4.51.0.
• Cypress, Changelog, 2026. Stąd daty wydań 16.0.0 i 16.1.1 oraz wymagane wersje Node.js.
• Cypress, Trade-offs, 2026. Stąd ograniczenia: dwie przeglądarki, karty, iframe, jedna domena.
• Cypress, Launching browsers, 2026. Stąd lista przeglądarek i WebKit eksperymentalnie.
• Cypress, cy.origin i cy.request, dokumentacja 2026.
• Cypress, TypeScript Support, dokumentacja 2026.
• Playwright, Supported languages, Browsers i Release notes, 2026.
• npm, rejestr pakietu cypress oraz statystyki pobrań npm, odczyt 10.10.2026 (okres 9.09 do 8.10.2026).
• Quality Island, uruchomienie trzech testów 10.10.2026 (macOS, Chrome 154), case study Argos i dane własne, 2026.