Powrót do: Praktyczne wprowadzenie do testów automatycznych z Playwright

Nowe podejście – tagi w Playwright

TIP: Ta lekcja jest częścią rozwijanego Programu Testy Automatyczne z Playwright 🎭

Prezentacja

Nowe podejście do tagów w testach automatycznych

Nowe podejście do tagów w testach automatycznych

Nowe podejście do tagów w testach automatycznych

Dodatkowe materiały

TIP: W tej lekcji bazujemy na kodzie jaki otrzymaliśmy w lekcji Tagi w testach automatycznych.

Cały kod potrzeby do realizacji tematów z tej lekcji znajdziesz też w naszym repozytorium: playwright_automatyzacja_wprowadzenie.

A dokładniej bazujemy na projekcie, który znajdziesz w katalogu S04 / L02_tagi.

Obecnie twórcy Playwright zalecają dodawać tagi za pomocą specjalnej konfiguracji (TestDetails).
Jest to specjalny obiekt, który zawiera tag lub listę tagów, która zostanie przypisana do testu.

Dlaczego ten sposób jest lepszy od dodawania tagów do nazw testów?

Sposób z konfiguracją nie wydłuża dodatkowo nazwy testów, która jest prezentowana w raportach.

Jeden tag

Wcześniejsza forma:

test('quick payment with correct data @integration @pulpit', async ({ page }) => {

Nowsza wersja:

test('unsuccessful login with too short username', { tag: '@login' }, async ({ page }) => {

Wiele tagów

Wcześniejsza forma:

test('quick payment with correct data @integration @pulpit', async ({ page }) => {

Nowsza wersja:

test('quick payment with correct data', { tag: ['@integration', '@pulpit'] }, async ({ page }) => {

Sposób uruchamiania testów

Uruchamianie testów z nowymi tagami jest kompatybilne ze wcześniejszym sposobem. Aby uruchomić testy, które są oznaczone tagiem @login wystarczy, że wykonamy polecenie:

npx playwright test --grep "@login"

Linki

18 komentarzy

    1. Jeśli dodamy tagi do describe, to aktualnie zostaną one automatycznie w raporcie dodane do testów, które znajduj się w tym describe.
      Więc możesz do tego podejść tak, że do describe dodasz ogolny tag, który opisuje wysokopoziomowo cały flow (np. @user, @customer-journey, @api itp), a w poszczególnych testach skupisz się w tagach na opisaniu czego dane testy/kroki dotyczą 😉

      Krzysiek Kijas Krzysiek Kijas
      Odpowiedz

      1. dzięki za szybką odpowiedź! potrzebuję otagować testy, które nie mogą być uruchamiane na produkcji i możliwość dodania tagów w test.describe bardzo mi się przyda w tym przypadku

        Avatar Olga Brzozowska
        Odpowiedz

        1. To otagowanie describe powinno zdać egzamin – możesz też przetestowac na niewielkiej próbce (taki pusty POC jak poniższy) czy dane zachowanie spełni wasze oczekiwania 😉

          np:

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

test.describe('User full flow', { tag: ['@non-prod'] }, () => {
  test.describe.configure({ mode: 'serial' });

  test('User Registration', async ({ page }) => {
    // Arrange:
    // Act:
    // Assert:
  });
  test('User Login', async ({ page }) => {
    // Arrange:
    // Act:
    // Assert:
  });
});
          Krzysiek Kijas Krzysiek Kijas
          Odpowiedz

          1. dzięki! przetestuję 🙂
            przy okazji zapytam, bo przez wyszukiwarkę nie mogę znaleźć. czy w kursie jest konfiguracja środowiska testowego i produkcyjnego, tzn. ustawienie BASE_URL dla poszczególnych środowisk?
            I w jaki sposób powinnam ustawić warunek, jeśli ENV=prod pomiń @non-prod? czy to powinno się znaleźć w ustawieniu projektów w playwright.config?

            Avatar Olga Brzozowska
            Odpowiedz

              1. Tak, to jest to czego potrzebowałam żeby zrozumieć temat zmiennych środowiskowych. Dzięki wielkie! Zastosowałam rozwiązanie z dotenv, ale teraz nie wiem jak i gdzie wykluczyć testy z tagiem @no_prod, skoro nie tworzę projektu w configu. a nie chcę tam dodawać projektu produkcyjnego, bo nie chcę żeby testy zawsze leciały na prodzie jeśli nie ustawimy –project=

                Avatar Olga Brzozowska
                Odpowiedz

                1. Możlie ze najprostszym rozwiązaniem były własnie drugi projekt w configu.
                  Ale są też inne opcje 😉
                  Możesz skorzystać z test.skip:
                  https://playwright.dev/docs/api/class-test#test-skip

                  I tam jest przykład warunkowego skipowania testów:

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

test('Safari-only test', async ({ page, browserName }) => {
  test.skip(browserName !== 'webkit', 'This feature is Safari-only');
  // ...
});

                  gdzie w test.skip podajemy warunek kiedy test ma być uruchomiony, a kiedy oznaczony jako skipped 😉
                  Jeśli bazujesz na env, to zamiast browser możesz użyć wartości ze zmiennych środowiskowych.
                  Więc mozę takie rozwiązanie lepiej pełni Twoje potrzeby 😉

                  Krzysiek Kijas Krzysiek Kijas
                  Odpowiedz

                  1. Dziękuję! Co ja bym bez Was zrobiła?! Nie dość, że dzięki waszemu kursowi weszłam w automaty w nowej technologii, to jeszcze dostaję tak duże wsparcie w realnych wyzwaniach! Dzięki serdeczne! <3

                    Avatar Olga Brzozowska
                    Odpowiedz

  2. Hej! Czy trzeba jakoś zrobić update ESlint do używania tagów w nowszej wersji?
    Ciągle hintuje mi te tagi jako błąd składni -> nie pasuje mu przecinek, choć testy działają dobrze.

    Avatar Michal Bandyszak
    Odpowiedz

      1. “@eslint/js”: “^9.10.0”,
        “@playwright/test”: “^1.49.1”,
        “eslint”: “^9.10.0”,
        “eslint-config-prettier”: “^9.1.0”,
        “eslint-plugin-playwright”: “^1.5.3”,
        “eslint-plugin-prettier”: “^5.1.3”,
        “prettier”: “^3.4.2”,
        “typescript-eslint”: “^8.5.0”

        VSC Version: 1.96.2
        Node.js: 20.18.1

        Korzystam jeszcze z Cursora v. 0.44.9 bazującego na wersji VSC 1.93.1

        Avatar Michal Bandyszak
        Odpowiedz

      2. A błąd to zwykł syntax error..

        SyntaxError: tests\api\article.delete.api.spec.ts: Unexpected token (57:12)

        test(
        ‘should not delete an article with non logged-in user’,
        { tag: ‘@GAD-R09-05’ },
        async ({ request }) => {

        Avatar Michal Bandyszak
        Odpowiedz

        1. Byłem w stanie zreprodukować problem 😉
          Ważny punkt – korzystasz z ustawień z lekcji o ESlint https://jaktestowac.pl/lesson/pw2s01l04-2-1/ 😉

          Tag jest polem, które moze przyjąć typy tag?: string | string[] | undefined.

          Wiec składniowo jest poprawnie i całość działa poprawnie, natomiast prawdopodobnie ESlint ma jakiś problem aby poprawnie zinterpretować ten kod.
          Spróbuj przeładować / zrestartowac VS Code i zobacz czy problem nadal występuje (u mnie restart VS Code pomógł i błąd zniknął)

          PS. Inne szybkie rozwiązanie – zrobic jednoelementowa listę tagów, czyli:

          { tag: [‘@GAD-R09-05’] },
          Krzysiek Kijas Krzysiek Kijas
          Odpowiedz

          1. Wiesz co, restart prettier I eslint pomaga, ale… Jednorazowo 😅
            Po dopisaniu kolejnych tagów w innych miejscach musiałem każdorazowo zrobić restart, żeby eslint/prettier to łyknęły.

            Sprawdzę Twoją propozycje z typem dla tagu j zerkne ponownie na tamtą lekcję!

            Avatar Michal
            Odpowiedz

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *