01Sprawdź locatory Playwright, zanim staną się flaky testami
Playwright Locator Playground powstał dla praktycznego momentu review, w którym developer widzi selector w szkicu testu i musi ustalić, czy opisuje kontrakt użytkownika, czy tylko aktualny kształt DOM. Narzędzie przyjmuje mały snapshot HTML, sanitizuje go w odpiętym dokumencie przeglądarkowym, ocenia locatory w stylu Playwright i tłumaczy strictness, zanim click albo fill stanie się kruche. Route jest privacy-first: wklejony markup zostaje w przeglądarce, backend nie zapisuje DOM-u, a publiczna strona nie importuje Playwright w runtime.
02Co sprawdza MVP
MVP skupia się na wyborach locatorów najczęściej widocznych w review testów end-to-end: getByRole z accessible names, getByLabel dla kontrolek formularzy, getByText dla widocznej treści, getByPlaceholder, getByAltText, getByTitle, getByTestId oraz CSS jako fallback porównawczy. Pokazuje też filter({ hasText }) i nth(index), bo te dwa narzędzia bywają przydatne, ale potrafią ukrywać niestabilne założenia UI. Model accessible-name jest celowo subsetem review, a nie pełnym silnikiem przeglądarki: obejmuje aria-labelledby, aria-label, explicit labels, wrapping labels, alt, title, widoczny tekst i input-hint fallback.
03Jak używać wyniku locatora
Zacznij od presetu najbliższego UI, które oceniasz. Formularz logowania pokazuje normalną ścieżkę: button z widocznym tekstem, textbox z labelem i fallback input hint. Tabela produktów pokazuje dopasowanie row przez filter({ hasText }), aby locator nazywał biznesowy wiersz zamiast polegać na pozycji w tabeli. Preset todo pokazuje powtórzone data-testid i dlaczego nth może przepchnąć test, ale nadal zostawia zależność od kolejności. Preset modalny pokazuje aria-labelledby, a preset accessibility edge-case sprawdza label, title, alt text i zachowanie sanitizera.
Panel wyniku działa jak mały log decyzji. Raw matches pokazują, jak szeroki jest pierwszy locator. Final matches pokazują, co zostaje po hasText i nth. Strict pass oznacza, że finalny locator rozwiązuje się do jednego widocznego elementu w sanitizowanym snapshocie DOM. Ambiguous oznacza, że strict mode Playwright odrzuciłby bezpośrednią akcję, bo pasuje więcej niż jeden element. Zero match oznacza, że review powinno sprawdzić pisownię, accessible name, hidden state, wynik sanitizacji albo składnię selectora przed commitem testu.
Generowany snippet jest celowo konserwatywny. Dla role locators zostawia widoczną rolę i accessible name. Dla label, text, input hint, alt, title i test id używa odpowiedniego API Playwright. Dla CSS używa page.locator(...) i oznacza ten wybór jako fallback. Jeśli obecny jest filter({ hasText }), snippet pokazuje ten filter wprost. Jeśli obecny jest nth, diagnostyka mówi o kruchości zamiast udawać, że pozycja jest tym samym co intencja. Dzięki temu strona pomaga w review kodu: wynik można wkleić do komentarza pull requestu razem z caveatem.
Sanitizacja jest częścią kontraktu. Playground usuwa elementy script, style, iframe, object, embed, link i meta, usuwa event handler attributes, usuwa fetch-like source attributes i usuwa javascript: href przed dopasowaniem. To utrzymuje publiczne narzędzie w zgodzie z obietnicą privacy-first i chroni stronę przed rolą generycznego HTML executora. Sanitizer robi też wynik bardziej uczciwy: review locatora nie potrzebuje zewnętrznych fetchy, wykonywania skryptów ani ukrytego runtime state.
Strony nie należy mylić z pełnym runtime Playwright. Nie uruchamia Chromium, nie woła silnika Playwright i nie obiecuje pixel-level actionability. To deterministyczna powierzchnia learning/review dla najczęstszej semantyki locatorów. Finalny test repozytorium nadal powinien żyć w Playwright, gdzie actionability, frames, shadow DOM, timing sieci i realne zachowanie accessibility tree mogą być zweryfikowane. Wartość tego playgroundu pojawia się wcześniej: pomaga zespołom wybrać czytelny locator, zanim test trafi do CI.
Uzywaj diagnostyki jak checklisty review, a nie automatycznej zgody. Stabilny locator powinien nazwac to, co widzi użytkownik, przetrwac niewinne zmiany layoutu i pomoc kolejnemu maintainerowi zrozumiec, dlaczego element jest ważny. Gdy playground pokazuje ambiguity, dobra poprawka zwykle polega na ulepszeniu kontraktu UI, dodaniu czytelniejszego accessible name, ograniczeniu locatora do sensownego regionu albo wprowadzeniu test id opisujacego intencje biznesowa. Taki zapis decyzji jest cenniejszy niz selector, który tylko dziala dzisiaj.
Drugi praktyczny przypadek to onboarding nowych osob do automatyzacji testow. Zamiast tlumaczyc abstrakcyjnie, dlaczego selector po klasie CSS jest slabszy od role locatora, zespol może pokazac ten sam DOM w playgroundzie i porownac wynik. Widac wtedy, który locator opisuje intencje użytkownika, który tylko strukture komponentu, a który wymaga poprawki w samym markup-u. To pomaga laczyc jakosc testow z jakoscia UI: lepszy label, lepsza nazwa buttona albo stabilny test id są decyzjami produktowymi, nie tylko technicznym detalem QA. Dzięki temu rozmowa o flaky testach szybciej przechodzi z gaszenia symptomow do poprawy kontraktu interfejsu. W praktyce taki zapis warto dołączac do review jako mini-protokół decyzji: jaki element chcemy znaleźć, jaka nazwa dostępna go opisuje, czy locator jest jednoznaczny i co stanie się po zmianie kolejności listy. Dzięki temu zespół nie tylko wybiera selektor, ale też dokumentuje intencję testu, ryzyko flakiness oraz ewentualną potrzebę poprawy markup-u przed wdrożeniem automatyzacji.