W obszarze automatyzacji testów, do tej pory opanowanym przez Selenium, w ciągu ostatnich kilku lat pojawiło się dwóch mocnych graczy, którzy przynoszą nową jakość i podejście do testowania aplikacji webowych – mowa oczywiście o Cypress i Playwright. Oba narzędzia stopniowo zdobywają coraz większą popularność wśród społeczności QA dzięki swoim zaletom, takim jak łatwość użytkowania, wydajność, czy automatyczne czekanie na elementy na testowanej stronie. W tym artykule porównamy oba z tych frameworków i pomożemy Ci zrozumieć, które z nich może być najlepsze dla Twoich potrzeb.

Playwright to framework open-source rozwijany przez Microsoft, przeznaczony do testów automatycznych aplikacji webowych. Został napisany w TypeScript, bazuje na Chrome DevTools Protocol. Wspiera kilka języków programowania i jest w pełni darmowy. Co ciekawe, za powstanie Playwright odpowiada zespół programistów, który wcześniej, jeszcze w Google, stworzył znany i lubiany w świecie testów framework Puppeteer.

Cypress również jest frameworkiem do automatyzacji testów na licencji open source, z tą różnicą że wspiera jedynie JavaScript/TypeScript i operuje w modelu freemium. W skrócie – możesz korzystać z niego za darmo, ale wykupienie subskrypcji daje dostęp do Cypress Cloud, czyli narzędzia dającego możliwość równoległego uruchamiania testów i usprawniającego ich raportowanie.

Oba te frameworki są często ze sobą porównywane z powodu posiadania podobnych funkcjonalności wspierających pisanie i uruchamianie testów. Są to między innymi automatyczne czekanie na elementy na stronach webowych, rozbudowane możliwości raportowania i debugowania testów.

Jak obecnie kształtuje się popularność obu tych narzędzi? Według npm trends, na dzień 10.11.2023 pobrania Cypressa kształtują się na poziomie około 5mln dziennie przy starcie produkcyjnym tego frameworka w 2017 roku. Playwright, który został wydany w 2020 roku, ściga swojego konkurenta z wynikiem około 2,5 mln pobrań dziennie i liczba ta stale rośnie.

Argumenty za Cypress

Wsparcie społeczności

Cypress został wydany w 2015 roku (private beta, potem w 2017 roku public beta) i przez te kilka lat od powstania, wokół tego narzędzia zdążyła zbudować się spora społeczność specjalistów korzystających z tego narzędzia, ale też dzielących się wiedzą na jego temat. Nietrudno jest znaleźć kurs pisania testów w Cypressie (również po polsku). W sieci pełno jest dyskusji na temat poszczególnych funkcjonalności. Cypress regularnie przewija się na konferencjach branżowych, warsztatach, zakorzenił się już w świadomości inżynierów QA.

Sytuacja trochę inaczej wygląda, jeśli chodzi o Playwrighta. Jest to narzędzie relatywnie nowsze, wciąż mocno rozwijane i zalicza się do nowinek w branży. Ten kombajn od Microsoftu nie zdążył jeszcze zbudować wokół siebie dużej społeczności i w sieci na razie nie istnieje tyle zasobów wiedzy, co u konkurenta – choć patrząć na stale zwiększającą się popularność tego frameworka, pewnie szybko się to zmieni.

Prostota składni

Przyjrzymy się jak wygląda prosty test napisany w Cypressie:

describe('fake shop', () => {  
    it('cypress can search products', () => {

      const newItem = 'Shirt'
  
      cy.visit('https://playground.quality-frontiers.pl/')
      cy.get('.wc-block-product-search__field').type(`${newItem}{enter}`) 
  
      cy.get('.products li')
        .should('have.length', 3)
        .last()
        .should('contain.text', newItem)
    })
})

Cypress bazuje na składni języka JavaScript, jednak posiada swój własny DSL (Domain-specific language), przez co testy piszemy za pomocą funkcji, najczęściej łączonych jedna za drugą. Test kończy się funkcją should, czyli cypressową asercją. Całość nie wygląda skomplikowanie i każdy jest w stanie zrozumieć logikę i kroki tego testu. Opisując tę składnię, można śmiało powiedzieć, że „piszemy w cypressie”, a nie w JavaScript.

Dla porównania, zobaczmy jak podobny test wygląda w Playwright:

import { test, expect } from '@playwright/test';

test('playwright can search products', async ({ page }) => {
  await page.goto('https://playground.quality-frontiers.pl/');

  await page.getByPlaceholder('Search product...').click();
  await page.getByPlaceholder('Search product...').fill('Shirt');
  await page.getByPlaceholder('Search product...').press('Enter');

  await expect(page.locator(".products li")).toHaveCount(3);
});

Składnia jest prosta, choć nie tak prosta jak w przypadku Cypress. Każda metoda użyta w teście zaczyna się od await i nie możemy tutaj łączyć ze sobą metod jak w konkurencyjnym frameworku.

Osobiście bardziej przemawia do mnie podejście, które wybrali twórcy Playwrighta. Do składni trzeba się przyzwyczaić i napisanie pierwszych testów ma wyższy próg wejścia niż w Cypress, jednak wiem co dzieje się pod spodem – w Cypress jest to lekko ukryte. Mimo to, zaletą Cypressa jest tutaj ogromna prostota składni, co jest szczególnie ważne dla osób początkujących.

Argumenty za Playwright

Testy równoległe

Playwright domyślnie uruchamia pliki testowe równolegle, za pomocą tzw workerów. Możemy także sterować równoległością wykonywania testów w jednym pliku (domyślnie jest to wyłączone). Użytkownik jest także w stanie całkowicie zablokować parallelism w testach, ręcznie ustawiając liczbę workerów na 1.

Najprostszy sposób na kontrolę liczby workerów w testach, to dodanie parametru w komendzie uruchamiającej testy:

npx playwright test --workers 4

Jak wygląda to w przypadku Cypressa? Ten nie wspiera testów równoległych, chyba że zapłaci się za Cypress Cloud. W użyciu są także alternatywne, open-sourcowe pluginy, takie jak Sorry Cypress.

EDIT: Od wersji 13 Cypress zablokował obsługę wtyczek Sorry Cypress i Currents.dev - tym samym usuwając alternatywy dla swojej płatnej usługi.

Wsparcie języków programowania

Ta część wypada zdecydowanie na korzyść Playwrighta, który wspiera zarówno JavaScript / TypeScript, Javę i C#. Cypress wspiera jedynie JavaScript / TypeScript.

Przeglądarki

Oba frameworki oferują szeroki zakres wsparcia dla przeglądarek. W Cypress możemy uruchamiać testy na Chrome, Electron, MS Edge i na Firefox – zarówno w trybie headless, jak i headed. Playwright daje nam podobną listę, czyli Chrome, Chromium, Firefox, Edge, Safari, również uruchamiane w trybach headless / headed.

Test Runnery

Tutaj na korzyść Playwrighta – ten wspiera Mochę, Jest, Jasmine, podczas gdy Cypress wspiera jedynie Mochę.

Wydajność

Playwright wykorzystuje architekturę opartą na WebSocketach do komunikacji między komponentami przeglądarki a kodem testu, co w dużym uproszczeniu oznacza, że Playwright łączy się z instancją przeglądarki, a następnie przesyła do niej polecenia z testu za pomocą tego kanału komunikacyjnego. To połączenie jest utrzymywane przez cały czas trwania testu, co umożliwia asynchroniczną komunikację między testem a przeglądarką. Kiedy test wykonuje konkretne polecenie, takie jak kliknięcie na elemencie strony czy wprowadzenie danych, Playwright przesyła te polecenia do przeglądarki przez istniejące połączenie WebSocket.

Dzięki tej architekturze Playwright jest w stanie zapewnić rewelacyjną wydajność testom.

Projekty

W pliku konfiguracyjnym znajduje się sekcja projects – w tym miejscu Playwright umożliwia grupowanie testów i przypisywania im wspólnej konfiguracji podczas ich uruchamiania – czyli ustawienia konkretnej przeglądarki, urządzenia, URL, itd.

Przykładowo, jeśli chcielibyśmy mieć jedną grupę testów np. „dev” uruchamianą na środowisku deweloperskim, i drugą np. „production” uruchamianą na środowisku produkcyjnym, nasz fragment kodu w sekcji projects w playwright.config.ts mógłby wyglądać tak:

export default defineConfig({
  timeout: 60000, 
  projects: [
    {
      name: 'dev',
      use: {
        baseURL: 'dev.fake-client.com',
        use: { ...devices['Desktop Chrome'] }
      },
      retries: 2,
    },
    {
      name: 'production',
      use: {
        baseURL: 'production.fake-client.com',
        use: { ...devices['Desktop Chrome'] }
      },
      retries: 0,
    },
  ],
});

Dodatkowo, w każdym z tych środowisk wybraliśmy także liczbę powtórzeń nieudanych testów i przypisaliśmy przeglądarki.

Ten sposób konfiguracji zbiorów testów jest bardzo czytelny i wygodny w obsłudze.

Wsparcie

Playwright ma wsparcie dużego gracza – Microsoft. Można założyć, że gigant z Redmont zapewni Playwrightowi wsparcie techniczne i finansowe, przy dotrzymaniu obietnicy dotyczącej tego, że narzędzie na zawsze pozostanie darmowe.

Wtyczka do VS Code

Powstała wtyczka do Visual Studio Code dedykowana pisaniu testów w Playwright. Z poziomu edytora, możemy uruchamiać i śledzić przebieg testów, generować selektory, debugować a nawet nagrywać testy.

Artykuł został podzielony na dwie części. Dalsza część znajduje się pod tym adresem.