Różnice między Playwright w TypeScript/JavaScript a Java, Python, C#

Language

date

Jun 19, 2023

slug

playwright-typescript-a-inne-jezyki-java-python

author

status

Public

Tajemniczy playwright test

Pobierając Playwright dla projektu w TypeScript lub JavaScript (dla stosu Node.js) tak na prawdę pobieramy Playwright Test.

Jest to rozszerzona wersja, można powiedzieć: framework lub nakładka, oparta o podstawową bibliotekę/paczkę Playwright.

Playwright Test jest niedostępny w innych językach (po za TypeScript lub JavaScript).

Co się kryje za Playwright Test?

Czemu warto się nim zainteresować nim wybierzemy w jakim stosie technologicznym chcemy się uczyć/używać Playwright?

Dlaczego jest to szczególnie ważne jeśli dopiero zaczynamy swoją pracę z Playwright framework?

Czy Playwright Test można użyć w innych językach niż TS/JS?

Krótko odpowiadając: nie. Ale można zaimplementować samodzielnie jego funkcje.

Niestety nie ma oficjalnej matrycy porównawczej, która wskazywała by jak uzyskać efekty znane z Playwright Test w innych językach (z niezbędnym kodem).

Wiemy jedynie, że w językach takich jak Java, Python i C# jesteśmy uzależnieni od integracji zewnętrznych narzędzi, czy implementacji własnych rozwiązań. 📌Więcej o tym dlaczego warto wybrać Type Script i Playwright przeczytasz tu: 🔗

Przegląd funkcji Playwright Test

Przygotowałem mały przegląd głównych funkcji Playwright Test. Dzięki temu możesz się zastanowić i skonsultować w zespole czy takie funkcje są przydatne i czy wolisz użyć gotowych rozwiązań od twórców Playwright (czy też zdecydować o samodzielnej implementację tych funkcji).

✅ Plusy Playwright Test

Poniżej wymieniam funkcje, które są domyślnie są wspierane w TS/JS w ramach Playwright Tests:

Test Runner - narzędzie, które wykorzystujące i rozszerzające bibliotekę podstawową Playwright. Daje dostęp do pewnych funkcji, które nie są znajdziemy “out of the box” w innych językach korzystając z Playwright. Test Runner to rozwiązanie służące do wytwarzania i uruchamiania testów. Znanymi test runnerami są Jest w świcie JS/TS czy PyTest w Pythonie. Test Runner jest tworzony i rozwijany przez twórców Playwright i jest w pełni zintegrowany z Playwright. Dzięki temu dostajemy gotowe rozwiązanie bez potrzeby integracji zewnętrznych test runnerów.

Parallel run - testy równoległe, konfigurowalne ustawieniem liczby workerów, domyślnie liczba workerów wykonujących niezależnie twoje testy jest równa połowie logicznych procesorów. Na Windows sprawdzisz liczbę tych procesorów w Task Manger w zakładce Performance, klikając CPU. Dla CI (Ciągłej Integracji) możemy łatwo wyłączyć tę funkcję, z tego względu, że powinieneś użyć kolejnej, którą opisujemy:

Sharding - uruchomienie i dystrybucja testów na kilku maszynach jednocześnie, przydatne dla uruchamianiu testów na serwerze Ciągłej Integracji (GH Actions lub GitLab CI)

Raporty - domyślnie otrzymujemy dedykowane raporty, które za pomocą bardzo prostej konfiguracji możemy wzbogacić o: - Trace Viewer: genialne narzędzie do podglądu testu, z akcjami, lokatorami, requestami i graficznym podglądem tych akcji na stronie (możemy nawet podglądnąć akcje w kilku oknach na raz np. jak testujemy otwarcie nowego taba) - Artefakty jak wideo czy screenshot, - Test Retry (flaky test) - funkcja umożliwiająca śledzenie ponowionych testów przydatna na serwerze CI Standardowo zawierają też: - Podsumowanie: Testy zakończone sukcesem, porażką, pominięte, flaky - Informacje o teście jak nazwa, tagi, projekty (np. rodzaj użytej przeglądarki) - w przypadku błędu, log błędu - akcje, hooks i inne elementy dostępne w widoku pojedynczego testu

UI mode - narzędzie do uruchamiania testów i automatycznego uruchamiania zmienionych testów, z Trace, podglądem ruchu sieciowego, wiadomościami na konsoli, kodem testów oraz wyborem danych projektów (profili jak np Chrome, FF lub grup testów etc)

Visual Comparison - porównywanie screenshotów strony lub jej elementów dla różnych urządzeń, dołączane do raportów, z heat mapą zmian i podglądem różnic

Projects - używane domyślnie do definiowania urządzeń na których mają uruchamiać się testy. Możemy też definiować konteksty zależne, np. projekt wymagający sesji jest zależny od projektu z setupem sesji, uruchamiając projekt zależny automatycznie uruchamiane są niezbędne projekty nadrzędne.

Timeouts - ustawienie globalnego/dedykowanego timeout dla testów, asercji, akcji, slow motion

Przechowywanie sesji, stanu przeglądarki - wystarczy zapisać w jednym teście i podłaczyć kolejne testy poprzez projekt zależny (nie trzeba fixtures, wstrzykiwania w testach etc.)

Testy zależne jako: synchronicznie uruchamiane dla grupy (describe) lub jako Test Steps w danym teście

Custom testy jak: test retires, fixme(conditional), slow(conditional) gdzie conditional może być danym projektem (Chromium, FF)

Pluginy - do VSC mamy plugin który pomaga w uruchomianiu testów dla danych projektów

Soft asercje - rodzaj asercji która nie powoduje przerwania testu

Web First Asertions - specjalne asercje będące portem z Testing Library wbudowane w Playwright Test

Debugging - powyższe funkcje można debuggować z poziomu VSC, są brakepointy, podgląd zmiennych, kontrola przeglądarki. Dzięki temu debugowanie można urozmaicić o różne narzędzia dodatkowe z Playwright Test

Global Setup and Teardown - łatwe w konfiguracji i automatycznie integrowane pliki z globalnymi ustawieniami

❌Minusy Playwright Test

Wymienię jeszcze minusy stosu dla stosowanie Playwright Test (odrobinę związany z samym TypeScript i domyślnym ekosystemem VSC i samą biblioteką Playwright):

Debugowanie asynchronicznego kodu TS/JS niestety nie pozwala w locie na wykonywanie akcji gdy debugger jest zatrzymany. Tego typu problemy nie występują synchronicznych językach jak Java czy Python.

Raporty: historia/trend testów nie są natywnie wspierane. Ale możemy to uzyskać za pomocą platformy Currents: https://currents.dev/playwright

Brak named parameters takich jakie znamy w Pythonie

Refaktoryzacja w natywnym środowisku: VSC nie jest tak dobra jak w IntelliJ i pochodnych IDE (ale możemy pisać w TS i używać IntelliJ) jednak sugeruję się tutaj zalecanym rozwiązaniem dla Playwright Test (VSC + wtyczka)

Globalnie wciąż mało testerów pisze w TypeScript co może być wadą Playwright Test (potrzeba przejścia z innego jezyka). Zauważę, że można też pisać w JavaScript ale jeśli idziemy w zalecania to rozpatrujmy Playwright Test z TypeScript.

Obsługa BDD. Oczywiście można użyć Playwrighta jako natywnej biblioteki nawet i w stosie Node.js, ale jednak tutaj się skupiam na Playwright Test. W tym narzędziu nie mamy obsługi BDD. Obecnie trwa ewaluacja takiej funkcji dla Playwright Test jednak nie wiemy kiedy i czy twórcy Playwright zdecydują się na wprowadzenie BDD.

Więcej o tym dlaczego wybrać Playwright + Type Script wspominamy tutaj: 🔗https://playwright.info/dlaczego-playwright-typescript

❓ Czy Playwright Test to dobry wybór w porównaniu do biblioteki Playwright w innych językach?

✅ Zdecydowanie TAK dla:

Chcących szybko stworzyć framework do testów automatycznych z wymienionymi funkcjami

Początkujących z Playwright

Uczących się TypeScript

Chcących wykorzystać wymienione funkcje bez potrzeby ich pisania lub integracji z innymi narzędziami (np. raporty)

Zainteresowanym użyciem dedykowanych funkcji niedostępnych w innych językach (UI Mode, Visual Comparison)

❌ Kiedy zrezygnować z Playwright Test?

Nie są nam potrzebne funkcje z Playwright Test

Samodzielnie je potrafimy zaimplementować w innym języku programowania

Samodzielnie chcemy integrować zewnętrzne narzędzia i utrzymywać własne rozwiązania

Posiadamy wystarczającą wiedzę programistyczną aby uzupełniać braki występujące pomiędzy Playwright Test a Playwright w danym języku