BugHuntFest Vol.2

Nowe paradygmaty automatyzacji – jak Playwright zmienił krajobraz testów?

Prezentacja

Prezentacje znajdziesz pod tym linkiem:

Nowe paradygmaty automatyzacji – jak Playwright zmienił krajobraz testów? 🎭

Repozytorium z kodem

Nasze repozytorium z całym prezentowanym na wystąpieniu kodem, znajdziesz pod tym adresem https://github.com/jaktestowac/bughuntfest-playwright-patterns 🎭

Do uruchomienia tych testów potrzebujesz uruchomić wczesniej nasza aplikację 🦎GAD – https://github.com/jaktestowac/gad-gui-api-demo

Kim jesteśmy i jakie mamy doświadczenie?

Przemek Barański Senior Software Quality Engineer, Principal Engineer profil na LinkedIn

O doświadczeniu... Rozwija frameworki w Playwright do testów GUI oraz API zintegrowane z procesami CI/CD Komercyjnym testowaniem oprogramowania zajmuje się od ponad 10 lat! Specjalizuje się w tematach performance i automation, które praktycznie wykorzystuje przy zapewnieniu jakości dla globalnych systemów informatycznych. Trenuje testerów od 2015, nie tylko online, ale też bezpośrednio na warsztacie, meetupie, konferencji czy uczelni. Twórca bezpłatnych treści wspomagających testerów w całej Polsce ze stawianiem swoich pierwszych kroków w różnych obszarach testowania (vlog, Git dla Testerów, Podstawy Automatyzacji). Zafascynowany technicznym rozwojem oraz upraszczaniem poznanych konceptów do łatwych i przyjemnych treści 😀 Tester nie tylko aplikacji ale i praktyk związanych z życiem, rozwojem i szeroko rozumianą jakością.

Krzysiek Kijas Senior Software Quality Engineer, Tech Lead, Mentor profil na LinkedIn

O doświadczeniu... Jako Tech Lead odpowiada za architekturę automatów z Playwright. Z testowaniem i dbaniem o jakość oprogramowania jestem profesjonalnie związany od 2011. Nabywałem doświadczenie w wielu projektach IT z różnych domen biznesowych (transport, finanse, administracja, zarządzanie systemami). Posiadam doświadczenie praktyczne w pracy z różnymi narzędziami CI/CD (Jenkins, GitLab CI, Azure DevOps). W codziennej pracy dbam o szeroko pojętą jakość w projekcie – poczynając od projektowania testów i strategii testowania, definiowanie i usprawnianie procesów, konsultacje rozwiązań, aż po tworzenie i projektowanie architektury frameworków do testów automatycznych. Od 2014 zdobywam doświadczenie jako trener poprzez prowadzenie warsztatów dotyczących jakości, pisania testów i narzędzi wspomagających testowanie. Współtworzę inicjatywę jaktestowac.pl, gdzie od początku przygotowuje kursy i materiały dla Nowoczesnych Testerów.

Paradygmaty, Wzorce i Praktyki

• Paradygmat to szeroki model, sposób myślenia lub podejście do rozwiązywania problemów w danej dziedzinie.
  • Charakterystyka:
    • Dotyczy ogólnej filozofii i podejścia.
    • Bardziej abstrakcyjny niż wzorce czy praktyki.
  • Przykłady:
    • Paradygmat niezależnych testów, czyli testy powinny być od siebie izolowane.
    • Paradygmat shift-left, czyli testowanie zaczyna się jak najwcześniej w cyklu życia aplikacji.
    • W programowaniu paradygmatami są programowanie obiektowe, funkcyjne czy proceduralne.
• Wzorce (Patterns) to sprawdzone rozwiązania konkretnych problemów, które można wielokrotnie stosować w podobnych sytuacjach. Wzorce są bardziej szczegółowe niż paradygmaty.
  • Charakterystyka:
    • Proponują gotowe techniki do konkretnych problemów.
    • Nie narzucają filozofii, ale rozwiązują konkretne problemy.
  • Przykłady:
    • Wzorzec Page Object, czyli reprezentowanie elementów strony jako obiektów w celu łatwiejszego zarządzania testami.
    • Wzorzec Retry (ponawianie), czyli automatyczne ponawianie testu w przypadku chwilowych błędów.
    • W programowaniu są wzorce projektowe (np. Singleton, Observer, Builder, Factory)
• Praktyki (Practices) to konkretne działania, metody lub nawyki stosowane w codziennej pracy. Praktyki są najbardziej szczegółowe i często wynikają z paradygmatów lub wzorców.
  • Charakterystyka:
    • Bardziej pragmatyczne i elastyczne niż wzorce.
    • Optymalizują codzienne działania.
  • Przykłady:
    • Regularne przeglądy kodu testowego (Code Reviews).
    • Tworzenie testów regresyjnych w oparciu o analizę ryzyka.
    • Praktyki zwinne (Agile), takie jak codzienne spotkania stand-up.

Porównanie

• Paradygmat – wysoki poziom abstrakcji, wyznaczenie ogólnego podejścia.
• Wzorce – średni poziom abstrakcji, rozwiązanie typowych problemów.
• Praktyki – niski poziom abstrakcji, optymalizacja codziennych działań.

Tło i kontekst – ewolucja narzędzi do automatyzacji

Automatyzacja testów przeszła długą drogę – od prostych skryptów do zaawansowanych narzędzi.

W miarę jak aplikacje stawały się coraz bardziej złożone, rosły również wymagania dotyczące narzędzi do ich testowania.

Poniżej przedstawiamy krótki przegląd ewolucji narzędzi do automatyzacji testów.

Krótka historia narzędzi testowych

Wczesne narzędzia do automatyzacji testów były często ograniczone w swoich możliwościach i wymagały dużego nakładu pracy, aby utrzymać testy w dobrym stanie.

Pierwsze narzędzia, takie jak Selenium, pojawiły się na początku XXI wieku i szybko stały się standardem w branży. Selenium pozwalało na automatyzację testów w różnych przeglądarkach, ale miało swoje ograniczenia, takie jak brak wsparcia dla nowoczesnych frameworków JavaScript, problemy z stabilnością testów, brak wspólnego interfejsu konfiguracyjnego czy brak uspójnionego podejścia do pisania testów.

Selenium i WebDriver jako klasyczna baza

Selenium WebDriver stał się podstawą dla wielu narzędzi do automatyzacji testów.

Jego elastyczność i możliwość integracji z różnymi językami programowania sprawiły, że był szeroko stosowany. Jednak wraz z rozwojem aplikacji webowych, które stały się bardziej dynamiczne i złożone, Selenium zaczęło wykazywać pewne ograniczenia.

Testy były często niestabilne, wymagały ręcznego czekania na elementy strony i były trudne w utrzymaniu…

Wzrost popularności Cypressa

W odpowiedzi na te ograniczenia, pojawił się Cypress, który zyskał popularność dzięki swojej prostocie i wydajności.

Cypress oferował wbudowane narzędzia do debugowania, automatyczne czekanie na elementy strony oraz łatwą integrację z nowoczesnymi frameworkami JavaScript. Jednak Cypress również miał swoje ograniczenia, takie jak brak wsparcia dla wielu tabów i okien, iframes, czy cross domain.

Również twórcy Cypressa stworzyli nową filozofię podejścia do asynchronicznej natury JavaScript (Cypress pojawił się przed async/await). Ta filozofia sprawiła, że pomimo prostego i szybkiego początku pracy z Cypressem, trudność w tworzeniu bardziej zaawansowanych testów gwałtownie rosła.

Pojawienie się Playwrighta

W 2020 roku Microsoft wprowadził na rynek Playwright, który szybko stał się przełomowym narzędziem w dziedzinie automatyzacji testów.

Playwright został zaprojektowany z myślą o nowoczesnych aplikacjach webowych, oferując większą stabilność, szybsze testy i łatwiejsze utrzymanie. Jego pojawienie się było odpowiedzią na rosnące potrzeby branży, które obejmowały:

• Większą stabilność – playwright automatycznie czeka na elementy strony, co zmniejsza ryzyko błędów związanych z wolno ładującymi się elementami i stronami.
• Szybsze testy – dzięki testom równoległym, inteligentnemu czekaniu, łatwemu zarządzaniu sesją, znacznie skraca się czas wykonania testów.
• Łatwiejsze utrzymanie – Playwright oferuje wsparcie dla wielu języków programowania, co ułatwia integrację z istniejącymi projektami.

Wiele strategii było znanych przed Playwrightem.

Playwright je spopularyzował i sprawił, że są bardziej dostępne.

Playwright spopularyzował te rozwiązania, czyniąc je łatwo dostępnymi i łatwymi w utrzymaniu. Dzięki temu, narzędzie to stało się preferowanym wyborem dla wielu zespołów.

Playwright zmienił krajobraz automatyzacji testów, wprowadzając nowe standardy w zakresie stabilności, szybkości i łatwości utrzymania. Jego innowacyjne funkcje (zintegrowany test runner i zrównoleglenie testów, trace, łatwy sharding czy visual testing), sprawiają, że jest to narzędzie przyszłości w dziedzinie automatyzacji testów.

W miarę jak aplikacje webowe będą stawały się coraz bardziej złożone, narzędzia takie jak Playwright będą odgrywały kluczową rolę w zapewnieniu ich jakości i niezawodności.

Paradygmaty

Budowanie zaufania do testów

Co niszczy zaufanie do testów?

• Niestabilne testy (tzw. flaky tests) to takie, które czasem przechodzą, a czasem nie – niezależnie od faktycznej zmiany w aplikacji. Jeśli zespół widzi „czerwone” wyniki bez wyraźnej przyczyny, szybko traci wiarę w to, że testy w ogóle są przydatne.

  Kluczowe skutki:
  marnowanie czasu na analizę fałszywych alarmów, spadek pewności co do wyników.

• Wolne testy, często są pomijane w codziennych iteracjach. Jeżeli uruchomienie pełnej regresji to kwestia godzin lub dni, zespół może zdecydować się na rzadsze uruchamianie, co zwiększa ryzyko wykrycia błędów zbyt późno.

  Kluczowe skutki:
  zniechęcenie do regularnego korzystania z testów, brak szybkiego feedbacku.

• Własne implementacje, które wpływają na utrzymanie. Gdy dużo logiki testowej jest napisana od zera (np. niestandardowy framework), wprowadzanie zmian i wsparcie w dłuższej perspektywie staje się trudne. Brak dokumentacji, wiedza „w głowach” pojedynczych osób oraz rosnąca złożoność to przepis na utratę zaufania.

  Kluczowe skutki:
  wysokie koszty utrzymania, ryzyko utraty kluczowych zasobów (osób znających framework).

Co było jedną z przyczyn?
Mało przyjazne narzędzia.

Zamiast skupić się na testowaniu, musieliśmy się skupić na implementacji różnych mechanizmów.

Playwright🎭 rozwiązuje częściowo te problemy na różne sposoby:

• Większa stabilność testów (auto-wait, retry, repeat-each)

  Playwright posiada wbudowane mechanizmy automatycznego czekania na elementy (auto-wait), a także możliwość wielokrotnego uruchamiania testu (retry, repeat-each). Dzięki temu testy są mniej podatne na przypadkowe błędy i budują większe zaufanie w zespole.

• Analiza i oznaczanie flaky tests

  Możliwość oznaczania testów jako niestabilnych (flaky) oraz ponownego ich uruchamiania w celu zebrania dodatkowych informacji diagnostycznych. Ułatwia to identyfikację problemów i poprawia jakość całej bazy testów.

• Zarządzanie stanem aplikacji (logowanie, cookies, localStorage)

  Możliwość zachowania stanu (np. zalogowanej sesji) między testami zapobiega powtarzaniu tych samych czynności (takich jak logowanie), co skraca czas wykonania i zwiększa niezawodność testów.

Wykorzystanie danych (Data-Driven Testing)

• Kiedyś parametryzacja testów daleko od kodu (BDD)
  W podejściu BDD (Behavior-Driven Development) często umieszczano dane w plikach tekstowych (np. Gherkin). Niestety, taka parametryzacja bywała “oderwana” od właściwego kodu testów, co czasem utrudniało szybkie modyfikacje, uruchamianie pojedynczych przypadków czy prezentacje danych w raportach
• Brak dobrej widoczności w raportach
  Przy rozbudowanych zestawach danych raporty nierzadko sprowadzały się do ogólnego wyniku scenariusza, bez szczegółów o konkretnych parametrach, które doprowadziły do błędu. Skutkowało to utrudnioną analizą przyczyn awarii.
• Problem z uruchomieniem pojedynczego testu z puli sparametryzowanych

  Jeśli kilkanaście wariantów danych było powiązanych z jednym scenariuszem, trudno było odpalić wyłącznie test z konkretnym zestawem parametrów. Utrudniało to szybkie debugowanie, analizę i wydłużało cykl testowy.

Playwright🎭 rozwiązuje te problemy poprzez generowanie testów na podstawie danych testowych oraz wykrywanie ich z poziomu wtyczki Playwright Test for VS Code.
Każdy taki wygenerowany test możemy uruchomić a wyniki testów są czytelnie przedstawione w raportach.

Transparentność i efektywność

W przeszłości wyniki z testów automatycznych były znacznie mniej zaawansowane i sprawiały wiele trudności:

• Ograniczone narzędzia diagnostyczne – głównym źródłem informacji o błędach był stack trace, który często nie wystarczał do zrozumienia przyczyny błędu w teście
• Trudne odtwarzanie błędów – reprodukcja scenariusza i analiza danego błędu (np. na środowisku CI) wymagała wielokrotnego uruchomienia testów i często dodawania kolejnych logów, co było czasochłonne
• Dodatkowe artefakty wymagały implementacji własnych rozwiązań – screenshoty robiono tylko w kilku miejscach testu, a nagrywanie i udostępnianie wideo z przebiegu testów było skomplikowane

Brakowało integracji narzędzi, które w jasny i kompleksowy sposób opisywały akcje wykonywane przez test oraz ich wyniki.

Playwright znacznie uprościł i usprawnił proces analizy błędów, rozwiązując historyczne problemy dzięki:

• Różnorodnym raportom, które można wygenerować w różnych formatach (HTML. json, xml), dzięki czemu możemy je wykorzystać w innych narzędziach do CI/CD (Jenkins, GitHub Actions, Azure DevOps) czy prezentacji wyników
• Kompleksowym raportom HTML, które mogą zawierać screeny, logi, nagrania wideo czy pliki trace – wszystko dostępne z poziomu konfiguracji Playwright!
• Pliki trace, które zawierają szczegółowe informacje o poszczególnych akcjach wykonywanych w testach, stanie aplikacji, screenach aplikacji i całych ruchu sieciowym

Dzięki temu debugowanie jest szybsze, a zespoły mają pełny kontekst błędów 😉

Testy atrybutów systemu (niefunkcjonalne)

Testy atrybutów systemu (niefunkcjonalne) koncentrują się na ocenie jakości i właściwości działania oprogramowania, takich jak wydajność, niezawodność, skalowalność, bezpieczeństwo czy użyteczność.

Celem tych testów nie jest sprawdzanie konkretnych funkcji systemu, lecz weryfikacja, czy spełnia on wymogi jakościowe i jest gotowy do pracy w rzeczywistych warunkach eksploatacji.

Playwright pozwala na automatyzację testów różnych atrybutów systemu:

• testy wydajności – Playwright + altillery.io – https://www.artillery.io/docs/reference/engines/playwright
• testy dostępności – Playwright + axe – https://playwright.dev/docs/accessibility-testing
• testy bezpieczeństwa – Playwright + OWASP ZAP – Automate Security Testing with Playwright and ZAP
• testy wizualne – Playwright – https://playwright.dev/docs/test-snapshots

Wielowarstwowe podejście do jakości (GUI, API, komponenty)

Paradygmat Wielowarstwowe podejście do jakości zakłada, że testowanie oprogramowania powinno odbywać się na różnych poziomach, aby zapewnić kompleksową weryfikację jakości systemu.

Oznacza to, że testy są przeprowadzane na wielu warstwach, takich jak testy jednostkowe, komponentowe, integracyjne, API oraz UI. Dzięki temu podejściu możliwe jest izolowanie problemów i szybsze ich naprawianie.

W przeszłości testowanie często ograniczało się do testów UI (interfejsu użytkownika).
Testy były często wykonywane tylko na poziomie scenariuszy end-to-end (E2E) i brakowało kompleksowego spojrzenia na cały system i wszystkie warstwy.

Również brakowało weryfikacji API lub wspomagania testów UI akcjami na API, co utrudniało wykrywanie błędów. Dodatkowo, różne poziomy testów były często realizowane przy użyciu różnych narzędzi, co prowadziło do braku spójności, kosztownym utrzymaniem, potrzeba znajomości różnych narzędzi albo języków.

Playwright znacząco zmienił podejście do testowania, adresując wiele historycznych problemów.

Playwright pozwala tworzyć testy na różnych poziomach (UI, API, modułowe, komponentowe) w ramach jednego frameworku. Dzięki temu zespoły nie muszą używać osobnych narzędzi do testów UI, API czy integracyjnych, co eliminuje problem fragmentacji i skraca czas nauki.

W przeciwieństwie do dawnych narzędzi (np. Selenium), Playwright domyślnie zapewnia izolację kontekstów przeglądarki. Każdy test uruchamia się w osobnej sesji, co redukuje flakiness (niestabilność) i zapobiega interferencji między scenariuszami.

Z Playwright możliwa jest prosta integracja testów API i UI. Playwright umożliwia wykonywanie zapytań do API bezpośrednio w testach UI, co pozwala na:

• weryfikację zachowania aplikacji po API w trakcie testów UI (np. e2e)
• symulację warunków brzegowych (np. błędów serwera) w testach frontendu
• wsparcie i przyśpieszenie testów UI, przez przygotowanie danych albo dodatkowe weryfikacje

Kiedyś zespoły używały np. Selenium do E2E, Postmana do API, JUnit do jednostkowych. Playwright zastępuje wiele narzędzi, oferując:

• automatyzację testów UI (Chromium, Firefox, WebKit)
• mockowanie sieci i przechwytywanie requestów
• wsparcie dla TypeScript, Python, Java, C#

Szybki start i przyspieszona adaptacja

W przeszłości wdrażanie testów automatycznych było żmudne i wymagało dużego nakładu pracy:

• Wolny start, bo konfiguracja frameworków testowych (np. Selenium) wymagała własnej implementacji i integracji różnych narzędzi (test runner, raporty, screenshoty w raportach etc).
• Brak gotowych rozwiązań i brak zintegrowanych mechanizmów do debugowania, raportowania czy wizualizacji.
• Manualne zarządzanie zależnościami – instalacja sterowników przeglądarek, zarządzanie wersjami i kompatybilnością pochłaniały dużo czas

Playwright usprawnił paradygmat poprzez wprowadzenie narzędzi, które przyspieszają pisanie i wdrażanie testów:

• Natychmiastowy start – w JavaScript/TypeSciript jednym poleceniem mamy prosty, ale gotowy do użycia framework z test runnerem i asercjami
• Generator testów, który pozwala nagrać testy bazujące na naszej interakcji z przeglądarką. Tak wygenerowany kod jest słabej jakości (nie zawiera podstawowych wzorców i praktyk), ale pozwala na szybką automatyzację powtarzalnych czynności
• Jednakowe podejście do konfiguracji – w JavaScript/TypeScript test runner bazuje na pliku konfiguracyjnym, który w każdym projekcie będzie miał bardzo podobną strukturę. Tym samym przychodząc do nowego projektu szybko odnajdziemy się w podstawowych elementach frameworka

Podsumowanie

Zewnętrzne linki i materiały

Darmowe kursy i webinary

• Sprawdź nasz wkład w rozwój Playwright oraz społeczności!
• Nasz blog w całości poświęcony Playwright – https://playwright.info 🎭
• Zbiór naszych darmowych materiałów o Playwright –
  • Zacznij z Playwright za darmo!
  • Darmowe materiały z webinaru – Testy zależne w Playwright – Gotowe rozwiązania, które użyjesz w swoim projekcie
  • Darmowy kurs Praktyczne wprowadzenie do testów automatycznych z Playwright na YouTube – Praktyczne wprowadzenie do testów automatycznych z Playwright
  • Darmowy kurs – Playwright Elements – Kluczowe koncepcje automatyzacji testów
  • Darmowa lekcja – Czym jest mockowanie?
  • Darmowa lekcja – Pierwsze testy z mockowaniem w Playwright
• Nasze poprzednie wystapienie na BugHuntFest Vol.1 – Różne smaki Playwright – o Playwright, Playwright Test, różnych językach i podejściach 🎭

Artykuły, przykłady i dokumentacja

• Oficjalna strona Playwright – Playwright.dev 🎭
• Nasz blog w całości poświęcony Playwright – https://playwright.info 🎭
• Dlaczego warto wybrać Playwright + TypeScript?
• W naszym poście na playwright.info bardzo dokładnie rozpisujemy temat TypeScript – Dlaczego tester powinien znać TypeScript?
• Dlaczego Playwright Test (wg. oficjalnej dokumentacji) Playwright Test Super Powers
• Wschodzące Gwiazdy JavaScript, czyli narzędzia zyskują największą popularność – 2023 JavaScript Rising Stars
• Ranking narzędzi do testów automatycznych – Testing Tools – Ranking
• Issues w Playwright posortowane od najpopularniejszych – microsoft / playwright
• Oficjalna dokumentacja wykorzystania artillery z Playwright do testów wydajności – Playwright engine + artillery.io
• Strona konferencji online BugHuntFest