01Review query Testing Library zanim utrwalą kruche testy
Testing Library Query Playground to privacy-first workbench do sprawdzania, jak rodziny i warianty query zachowują się na małym snapshocie DOM. Wklej markup, wybierz getBy, queryBy, getAllBy albo queryAllBy i sprawdź matches, snippets oraz diagnostykę bez wysyłania HTML-a.
02Co wspiera MVP
MVP obejmuje ByRole, ByLabelText, ByText, ByPlaceholderText, ByDisplayValue, ByAltText, ByTitle i ByTestId. Wyjaśnia zachowanie getBy, queryBy i AllBy, oznacza findBy jako async caveat, nie wykonuje RegExp i limituje rozmiar HTML-a, liczbę nodes oraz widoczne wyniki.
03Dlaczego semantyka query wymaga widocznego review
Wybór query Testing Library koduje kontrakt produktu. Test używający getByRole z czytelnym accessible name jest czymś innym niż test oparty o test id albo powtórzony tekst. Review kodu często musi zobaczyć zarówno wybrany element, jak i tryb porażki. Ten playground pokazuje te stany osobno: no match, multiple match, null result, empty array i array result.
Evaluator celowo używa odpiętego dokumentu DOMParser i lokalnego sanitizera. Usuwa scripts, iframes, event handlers, fetch-like attributes oraz javascript links przed matchingiem. Raw snapshot nigdy nie trafia do live Angular DOM, więc narzędzie pomaga w review bez tworzenia powierzchni wykonywania HTML-a.
Trasa jest edukacyjnym subsetem, a nie pełnym runtime DOM Testing Library. Dzięki temu bundle pozostaje mały, a zachowanie łatwe do wyjaśnienia. Limity są jawne: brak free-form RegExp, custom normalizer, async DOM mutation simulation i konfigurowalnego test id attribute w MVP.
Najwazniejszy przypadek uzycia Testing Library Query Playground to szybki review pytania: "czy ten test opisuje zachowanie użytkownika, czy tylko aktualny DOM?". Przy duzych komponentach latwo napisac selektor, który przechodzi dzisiaj, ale psuje się po zmianie wrappera, klasy CSS albo kolejnego refaktoru design systemu. Strona porzadkuje role, accessible names, widoczny tekst, labelki i wyniki kilku typow query, dzięki czemu reviewer widzi, czy lepszy bedzie query po roli i nazwie, po labelu, po placeholderze, czy w ostatecznosci po test id. To ogranicza dyskusje do semantyki interfejsu, a nie do zgadywania jak Testing Library zinterpretuje fixture.
Granica narzędzia jest celowo jasno postawiona. Playground analizuje statyczny, oczyszczony HTML i nie probuje udawac runnera aplikacji, lifecycle frameworka, retry loopow ani asynchronicznych zmian stanu. Taka decyzja zmniejsza ryzyko prywatności i pozwala wkleic zredukowany fragment DOM bez wykonywania skryptow, handlerow zdarzen albo linkow javascript. W praktyce dobrze sprawdza się to jako etap przed poprawka testu: najpierw minimalny fixture potwierdza role i nazwy dostepnosci, potem docelowy test nadal musi zostac uruchomiony w repo z realnym komponentem, mockami i stanem aplikacji.
04Praktyczny workflow review query
Zacznij od ByRole i name, gdy UI wystawia sensowną rolę. Przejdź do ByLabelText dla kontrolek formularzy, potem do widocznego tekstu, placeholdera albo display value, jeśli opisują kontrakt użytkownika. ByTestId traktuj jako stabilny fallback, gdy UI nie ma trwałego semantycznego uchwytu.
Zmieniaj wariant zgodnie z asercją, którą chcesz napisać. getBy jest głośne i dobre dla oczekiwanej obecności. queryBy pasuje do absence checks, ale nadal failuje przy wielu dopasowaniach. getAllBy i queryAllBy pokazują powtórzone UI wprost. findBy należy do realnych testów, gdy element pojawia się po async update; tutaj jest oznaczone jako educational-only, bo snapshot DOM jest statyczny.
Dla wrażliwego markup-u wklej zredukowaną fixture zamiast produkcyjnego HTML-a. Zachowaj strukturę, labels, roles i reprezentatywny tekst, ale usuń dane klientów, tokeny oraz wewnętrzne identyfikatory.
Dla review testow szczegolnie przydatne jest porownanie kilku wariantow fixture: wersji z pelnym tekstem, wersji z samym aria-label oraz wersji z ukrytym elementem pomocniczym. Jezeli wynik query zmienia się tylko dlatego, ze zniknal dekoracyjny wrapper, test prawdopodobnie byl zbyt powiazany z implementacja. Jezeli zmienia się po utracie labela albo roli, problem dotyczy juz dostepnosci interfejsu i powinien wrocic do komponentu, a nie tylko do samego testu.