Jest Matcher Playground

How to use matcher output in a code review

Start with the preset closest to the assertion under review. Identity versus equality is the most common trap: two object literals can look identical and still fail toBe because they are not the same reference. If the test is checking shape, toEqual or toStrictEqual communicates that intent more clearly. Array containment is another frequent source of confusion. toContain is useful for primitive-like membership or substring checks, while toContainEqual is usually what reviewers expect when the array contains objects. Partial object matching is a contract decision: toMatchObject says that the listed keys matter and unrelated fields may vary. That is useful for API responses, release metadata and UI state snapshots where the test should not freeze the entire object. The diff is intentionally compact. It reports missing, extra, changed or type-mismatched paths and caps the output at a review-friendly size. This makes the result pasteable into a task note or pull request discussion without pretending to replace the repository test runner. For larger fixtures, paste the smallest value that demonstrates the matcher question first, then add more context only if the result still needs explanation. That keeps private data out of examples and keeps the reviewer focused on matcher intent. The JSON-only boundary is deliberate. A public browser playground should not run arbitrary JavaScript, evaluate custom asymmetric matchers, execute regular expressions from untrusted input or load a repository test environment. toMatch therefore uses plain substring matching here, not regex execution. That safety decision is visible in the UI and FAQ so teams do not mistake the page for a complete Jest runtime. The final proof of behavior remains the repository test suite. Sentinels make edge cases teachable without turning the input into JavaScript. Undefined and NaN are important for Jest matchers, but they are not JSON values. The explicit {"$pfType":"undefined"} and {"$pfType":"NaN"} markers let reviewers discuss toBeUndefined, toBeDefined and toBeNaN while keeping the parser predictable. Prototype-pollution keys are rejected before evaluation because public examples should reinforce safe data handling habits. The publisher content answers the search intent before interaction. A visitor can learn when to use toBe versus toEqual, why toContainEqual matters for object arrays, how partial matching changes the assertion contract, why .not can hide a positive matcher pass, and where the playground intentionally stops. The page also connects naturally to the rest of Playground Forge: ESLint Rule Tester for rule behavior, typescript-eslint Parser for AST context, tsconfig Validator for configuration review, JSON Schema Validator for contract validation and YAML Parser Converter for configuration shape inspection. A practical workflow is to treat the playground result as a small decision log. Record the matcher, whether .not was used, the received type, the expected type, and the first relevant diff path. That is enough for a team to decide whether the assertion communicates product behavior, implementation detail or an accidental snapshot. Once the assertion intent is clear, copy the improved expectation back into the repository and run the real test command. The browser tool makes the decision visible; the repository remains the release gate. The route is also useful for documentation and onboarding. A team can paste a small received value from a failing test, compare two matcher choices, then turn the result into a short explanation for a README, QA note or pull request template. That is different from copying a stack trace. The playground asks the reviewer to name the matcher contract: identity, structural equality, subset, containment, length, truthiness or numeric comparison. Naming the contract reduces accidental assertions and makes future failures easier to understand. It also gives search visitors useful publisher content before they interact with the tool, which is important for a public commercial page that should not be a thin wrapper around a textarea.