O kursie

Przycisk przesunął się o cztery piksele. Niemiecka wersja językowa rozbiła nagłówek na dwie linijki. Tryb ciemny zjadł kontrast na cenie produktu.

Testy funkcjonalne świecą na zielono, bo DOM się zgadza: element istnieje, tekst jest w kodzie, kliknięcie działa, asercja przechodzi. Tylko że użytkownik nie czyta DOM-u — użytkownik patrzy.

Przez najbliższy tydzień nauczysz testy robić to samo. Zbudujemy od zera framework testów regresji wizualnej (VRT) w Playwright i TypeScript.

Pracować będziemy na Pixelarium, aplikacji przygotowanej specjalnie na potrzeby tego kursu. To galeria sztuki cyfrowej, w której nic nie stoi w miejscu: licznik odwiedzin bije na żywo, odliczanie leci do końca aukcji, karuzela sama przewija slajdy, ceny są w trzech walutach, a interfejs w trzech językach — angielskim, polskim i niemieckim. Czyli wszystko, co potrafi zepsuć zrzut ekranu.

Zamiast opisywać wygląd kolejnymi asercjami, robisz zdjęcie i porównujesz je ze wzorcem.

Baseline to wzorcowy stan wizualny aplikacji, zaakceptowany raz i zamrożony w pliku. Każdy kolejny przebieg testu robi nowe zdjęcie i zestawia je z tym wzorcem, a diff pokazuje obie klatki nałożone na siebie. Cała sztuka polega na tym, żeby między jednym a drugim zdjęciem zmieniło się wyłącznie to, co sprawdzasz, a reszta pozostała identyczna: to samo światło, ten sam kadr, ta sama godzina na zegarze. Bo kiedy zegar tyka, animacja leci, a dane przychodzą z żywego API, każde zdjęcie wychodzi trochę inne i test, zamiast pilnować regresji, zaczyna migotać.

Najważniejsze: o tym, który stan wizualny staje się nowym wzorcem, dalej decydujesz Ty.

Pracujemy blisko kodu, bez ogólników. Poznasz toHaveScreenshot() i trzy obrazki, na które patrzysz po każdym czerwonym przebiegu: baseline, actual i diff. Zajmiemy się stabilizacją: page.clock ustawiony przed page.goto(), maskowanie zamiast ukrywania elementów CSS-em, jawna asercja zamiast czekania na ciszę w sieci. Tolerancję ustawimy świadomie, parametrem maxDiffPixels, a nie podkręcaniem progu tak długo, aż zrobi się zielono.

Potem dochodzą kolejne warstwy: responsywność i tryb ciemny rozpisane na projekty Playwright, toMatchAriaSnapshot() obok pikseli jako drugie zabezpieczenie, mockowanie odpowiedzi API na page.route() z deterministycznymi factory functions, a na koniec Page Object i fixtures, żeby to wszystko dało się utrzymać jeszcze po trzech miesiącach.

Kiedy testy stoją już stabilnie, baseline’y wyprowadzimy z repozytorium do Visual Regression Trackera, dashboardu, który uruchomisz u siebie w Dockerze. Akceptacja zmiany wizualnej przestaje wtedy być commitem, a staje się decyzją zespołu.

Przez cały tydzień LLM jest naszym partnerem w pracy, a nie generatorem kodu na zawołanie. W tej roli występuje u nas Claude Code.

Zobaczysz, jak agent wyposażony w serwer Playwright MCP otwiera aplikację i czyta prawdziwe data-testid oraz role, zamiast je zgadywać. Jak robi triage diffa i rozstrzyga, czy to błąd, czy zmiana zamierzona. I jak Twoje powtarzane prompty zamieniają się w bibliotekę skilli oraz plugin, którym podzielisz się z zespołem.

Wszystko pod Twoim nadzorem, bo aparat robi zdjęcie, ale kadr wybiera człowiek.

Nawet jeśli Playwright znasz od podszewki, zobaczysz go tutaj w roli, w której zwykle nie występuje: pilnuje wyglądu aplikacji, a nie jej zachowania. VRT poznasz od podstaw, a przy okazji dorzucisz do swojego warsztatu kilka rzeczy, po które w testach funkcjonalnych nie było powodu sięgać.

W kursie wykorzystamy:

• ✅ Playwright: toHaveScreenshot() i toMatchAriaSnapshot()
• ✅ TypeScript: factory functions, Page Object, fixtures
• ✅ Serwer Playwright MCP: agent pracuje na żywej aplikacji
• ✅ Agent Claude Code
• ✅ Skille Claude Code: zbudujemy własną bibliotekę skilli VRT
• ✅ Plugin Claude Code: dystrybucja skilli w zespole
• ✅ Pliki CLAUDE.md i AGENTS.md jako pamięć agenta
• ✅ Visual Regression Tracker: self-hosted dashboard w Dockerze

Czego się nauczysz?

• ✅ Jak zbudować utrzymywalny framework VRT, a nie zbiór zrzutów ekranu akceptowanych przy każdym przebiegu
• ✅ Jak sprawić, żeby test wizualny był deterministyczny: zamrożony czas, maski, jawne asercje, mock API
• ✅ Jak dobierać tolerancję dla każdego komponentu osobno i uzasadnić każdą decyzję
• ✅ Jak pilnować responsywności, trybu ciemnego i trzech wersji językowych, rozpisując je na projekty Playwright
• ✅ Jak połączyć warstwę pikselową z semantyczną, żeby wiedzieć nie tylko, że coś się zmieniło, ale i co
• ✅ Jak prowadzić baseline’y zespołowo na dashboardzie zamiast w repozytorium
• ✅ Jak zbudować własną bibliotekę skilli: generowanie danych, pisanie testów wizualnych, triage diffów, code review
• ✅ Jak używać CLAUDE.md, żeby agent znał konwencje Twojego zespołu i nie zjadał kontekstu na starcie

TIP: Ten kurs jest częścią Programu AI_Testers 2.0. O innych kursach i materiałach wchodzących w skład tego Programu poczytasz tutaj: pełny Program AI_Testers i ściezka rozwoju z AI

Informacje o kursie

Trudność: Średnio-zaawansowany

Ścieżki kursu:AI_Testers vol. 2

Kategorie kursu:AI Testers vol. 2

Tagi:agents, AI, API, CLI, Codex, openAPI, playwright, Playwright CLI, Playwright MCP, rest api, Swagger

Kurs Instructor

Michal Slezak Autor