Powrót do: Praktyczne wprowadzenie do testów automatycznych z Playwright
Nowe podejście – tagi w Playwright
Prezentacja
Dodatkowe materiały
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
- Oficjalna dokuemntacja o działaniu polecenia grep w Playwright
- Lekcja o formatowaniu kodu w VS Code za pomocą prettiera – Prettier, czyli formatter kodu
gdzie dodajemy tagi, jeśli testy są w serial mode – do describe czy poszczególnych testów w serii?
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ą 😉
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
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:
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?
Możesz to projektami ogranąc – bo w projekcie łatwo wykluczysz dany tag z uruchomienia 🙂
A jesli chodzi o konfiguracje dla różnych środowisk – rzuć prosze okiem na nasz post – https://playwright.info/playwright-testy-na-roznych-srodowiskach – tam opisujemy takie bazowe konfiguracje 😉 Daj znac czy spełnią Twoje potrzeby 😉
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=
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:
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 😉
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
Cała przyjemność po naszej stronie 😀
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.
Jaki dokładnie błąd otrzymujesz i z jakich wersji (ESLinst, VSCode, Playwright) korzystasz? 🙂
“@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
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 }) => {
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:
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ę!
Ten jeden minus nic nie znaczy przy braku oznaczeń tagów w tytułach testów 🙂
Przy braku tagów nie ma o czym mówić 😀