01Sprawdz intencje matchera zanim asercja stanie się kruchym testem
Jest Matcher Playground jest dla momentu review, gdy pull request zawiera asercje i zespol chce zrozumiec, czy matcher faktycznie mowi to, co autor testu mial na mysli. Developer może wkleic received i expected jako JSON, przelaczac toBe, toEqual, toContainEqual, toMatchObject, truthiness i matchery liczbowe, a potem zobaczyc PASS albo FAIL z kompaktowym diffem expected versus received. Playground jest privacy-first: wartości są oceniane w przeglądarce, przyklady nie trafiaja na backend, a strona nie wykonuje dowolnego JavaScript.
02Co sprawdza MVP
MVP skupia się na semantyce matcherow, która realnie powoduje tarcie w review testow. Pokazuje, dlaczego toBe jest identity-like, a toEqual i toStrictEqual są strukturalne dla wartości JSON, kiedy toContainEqual jest lepsze niz toContain dla tablic obiektow, jak zachowuje się toMatchObject dla czesciowych kontraktow odpowiedzi oraz jak .not odwraca finalny wynik asercji. JSON-only input utrzymuje publiczne narzędzie przewidywalne. Wartosc specjalne, których JSON nie reprezentuje bezposrednio, są modelowane jawnie: {"$pfType":"undefined"} i {"$pfType":"NaN"}. Route odrzuca też niebezpieczne klucze prototype-pollution, limituje wielkosc inputu, głębokość zagniezdzenia i liczbe wierszy diff.
03Jak używać wyniku matchera w code review
Zacznij od presetu najblizszego asercji z review. Identity versus equality to najczestsza pulapka: dwa obiekty literalne mogą wyglądać identycznie i nadal failowac toBe, bo nie są ta sama referencja. Jesli test sprawdza ksztalt danych, toEqual albo toStrictEqual komunikuje intencje czytelniej. Array containment to kolejny czesty punkt pomylek. toContain jest przydatne dla primitive-like membership albo substring, a toContainEqual zwykle odpowiada temu, czego reviewer oczekuje dla tablicy obiektow. Partial object matching jest decyzja kontraktowa: toMatchObject mowi, ze wymienione klucze maja znaczenie, a pozostale pola mogą się zmieniac. To pasuje do API response, metadanych release i snapshotow stanu UI, gdzie test nie powinien zamrazac calego obiektu.
Diff jest celowo kompaktowy. Pokazuje missing, extra, changed albo type-mismatched paths i ucina output do rozmiaru wygodnego w review. Dzięki temu wynik da się wkleic do notatki taska albo dyskusji pull request bez udawania, ze zastepuje repozytoryjny test runner. Przy wiekszych fixture wklej najpierw najmniejsza wartość, która pokazuje pytanie o matcher, a dopiero potem dodaj kontekst, jesli wynik nadal wymaga wyjasnienia. To ogranicza ryzyko wklejenia prywatnych danych i utrzymuje uwage reviewera na intencji asercji.
Granica JSON-only jest celowa. Publiczny browser playground nie powinien uruchamiac dowolnego JavaScript, oceniac custom asymmetric matchers, wykonywac regular expressions z niezaufanego inputu ani ladowac srodowiska testowego repozytorium. Dlatego toMatch używa tutaj plain substring matching, a nie regex execution. Ta decyzja bezpieczenstwa jest widoczna w UI i FAQ, żeby zespol nie traktowal strony jako pelnego runtime Jest. Ostateczny dowod zachowania pozostaje w repozytoryjnym test suite.
Sentinele pozwalaja omawiac edge case bez zamiany inputu w JavaScript. Undefined i NaN są ważne dla matcherow Jest, ale nie są wartosciami JSON. Jawne markery {"$pfType":"undefined"} i {"$pfType":"NaN"} pozwalaja rozmawiac o toBeUndefined, toBeDefined i toBeNaN przy zachowaniu przewidywalnego parsera. Klucze prototype-pollution są odrzucane przed ewaluacja, bo publiczne przyklady powinny wzmacniac bezpieczne obchodzenie się z danymi.
Publisher content odpowiada na intencje wyszukiwania przed interakcja. Odwiedzajacy może zrozumiec, kiedy uzyc toBe zamiast toEqual, dlaczego toContainEqual ma znaczenie dla tablic obiektow, jak partial matching zmienia kontrakt asercji, dlaczego .not potrafi ukryc pozytywny wynik matchera i gdzie playground celowo się zatrzymuje. Strona laczy się też naturalnie z reszta Playground Forge: ESLint Rule Tester dla zachowania rules, typescript-eslint Parser dla kontekstu AST, tsconfig Validator dla review konfiguracji, JSON Schema Validator dla walidacji kontraktow i YAML Parser Converter dla inspekcji ksztaltu konfiguracji.
Praktyczny workflow to traktowanie wyniku jako malego decision logu. Zapisz matcher, czy uzyto .not, typ received, typ expected i pierwszy istotny path diff. To wystarcza, żeby zespol zdecydowal, czy asercja komunikuje zachowanie produktu, detal implementacyjny czy przypadkowy snapshot. Gdy intencja asercji jest jasna, przenies poprawione oczekiwanie do repozytorium i uruchom prawdziwa komende testowa. Browser tool uwidacznia decyzje; repozytorium pozostaje release gate.
Route jest też przydatny w dokumentacji i onboardingu. Zespol może wkleic maly received value z padajacego testu, porownac dwa wybory matchera, a potem zamienic wynik na krótkie wyjasnienie do README, notatki QA albo szablonu pull request. To cos innego niz kopiowanie stack trace. Playground zmusza reviewera do nazwania kontraktu matchera: identity, structural equality, subset, containment, length, truthiness albo numeric comparison. Nazwanie kontraktu ogranicza przypadkowe asercje i sprawia, ze przyszle porazki testow są łatwiejsze do zrozumienia. Daje też odwiedzajacym z wyszukiwarki realny publisher content przed interakcja, co jest ważne dla publicznej strony komercyjnej, która nie może byc cienka nakladka na textarea.
Dodatkowo strona podpowiada, żeby nie traktowac zielonego wyniku jako automatycznego release approval. Matcher może byc poprawny technicznie, ale nadal sprawdzac zbyt szczegolowy detal implementacji zamiast zachowania użytkownika.