Kuloodporna konfiguracja testów w Playwright

Wyobraźmy sobie takie sytuacje:

• Mamy testy automatyczne, które chcielibyśmy uruchamiać na więcej niż jednym środowisku.
• Chcemy uruchamiać część testów automatycznych na środowisku produkcyjnym. W tym celu wybraliśmy kilka scenariuszy jako takie, które wykonują jedynie operacje odczytu danych i nie ingerują w zasoby środowiska. Musimy mieć możliwość wybrania wyłącznie tej grupy podczas startu testów.
• Nasze testy automatyczne są podzielone na testy kilku różnych funkcjonalności – np. logowania, ścieżki zakupowej, panelu admina. Chcemy mieć możliwość odpalania testów jednej z tych grup, zamiast wszystkich testów na raz.

Czy powyższe wymagania są Ci znajome? Poniżej rozpisałem, jak w Playwright (na Node.js) przygotować konfigurację, która umożliwia parametryzację uruchamiania testów automatycznych w zależności od środowiska i wybranej grupy testów.

Środowiska vs testy

Na początek, przygotujmy konfigurację, która będzie obsługiwać uruchamianie testów na więcej niż jednym środowisku. Przyjmijmy, że pracujemy na dwóch środowiskach: stage i prod.

W pliku playwright.config.ts, w sekcji projects dodajmy dwa projekty:

projects: [
    {
      name: 'stage',
      use: {
        baseURL: 'staging.example.com',
      },
      retries: 2,
    },
    {
      name: 'prod',
      use: {
        baseURL: 'production.example.com',
      },
      retries: 0,
    },
  ],

Dla każdego z tych dwóch środowisk przypisaliśmy unikalny adres URL, a także liczbę powtórzeń nieudanych testów (czyli retries).

Teraz, chcąc uruchomić testy z konfiguracją pod środowisko np. stage, możemy użyć do tego standardowej komendy z flagą nazwy tego środowiska:

npx playwright test --project=stage

Tym sposobem otrzymujemy elastyczny mechanizm, który umożliwia nam dynamiczne przełączanie adresów testowanej aplikacji. Zauważ, że do każdego środowiska możesz przypisać nie tylko jego URL, ale także inną konfigurację, np liczbę powtórzeń nieudanych testów (jak wyżej) lub przeglądarkę.

Tagi

Mamy już gotowe rozwiązanie, które obsłuży nam parametryzację uruchamiania testów pod kątem środowisk. To jednak nie koniec. Co w przypadku, gdy chcielibyśmy uruchamiać tylko niektóre grupy testów? Na przykład – po deploy na środowisko produkcyjne, mamy zamiar odpalać jedynie testy oznaczone jako „read”, czyli odczytujące dane. Albo – chcemy zobaczyć wynik testów tylko jednej funkcjonalności i zignorować pozostałe. Jak to osiągnąć? Można wykorzystać do tego tagi.

Przyjmijmy, że część naszych testów chcemy oznaczyć np. jako smoke testy. W tym celu musimy dodać { tag: ['@Smoke'] } do sygnatury testu. Całość powinna wyglądać jak poniżej:

test('Dummy test to show tags', { tag: ['@Smoke'] }, async ({ page }) => {
  await page.goto('/');
  await expect(page).toHaveTitle("Quality Frontiers - Blog ekspercki QA");
});

Teraz spróbujmy uruchomić wyłącznie test oznaczony tym tagiem. Dodajmy do tego jedno ze środowisk i uzyskamy taką komendę:

npx playwright test --project=stage --grep "@Smoke"

Playwright odpali jedynie test oznaczony tagiem Smoke na środowisku oznaczonym jako stage.

Po zakończeniu testu, zostanie wygenerowany raport i znajdziemy tam oznaczenie zarówno użytego środowiska (a właściwie projektu) jak i taga.

Możemy uruchamiać testy z pomocą więcej niż jednego taga:

npx playwright test --project=stage --grep "@Smoke|@HappyPath"

Powyższa komenda uruchomi wszystkie testy oznaczone tagiem @Smoke i tagiem @HappyPath.

Wsparcie UI Mode

UI Mode (czyli playwrightowy runner testów, z którego pomocą możemy uruchamiać i debugować testy) także wspiera uruchamianie testów za pomocą tagów. Aby otworzyć to narzędzie, w konsoli należy wpisać komendę:

npx playwright test --ui

Na ekranie ukaże się lista naszych testów. Zwróć uwagę na fakt, że każdy test zawiera nazwę i tag, którym jest opisany.

Teraz możemy filtrować testy po konkretnym tagu:

Jak oznaczać testy?

Jest to mocno zależne od samej aplikacji, ale proponuję dwa rodzaje oznaczeń:

Ze względu na rodzaj testów:

• Smoke testy
• Testy regresyjne
• Testy e2e
• Testy API
• Testy UI

Ze względu na testowaną funkcjonalność, np.:

• login
• payment
• shopping path
• admin

Dodatkowo przydatną praktyką jest oznaczanie testów niestabilnych, np jako flaky.