testing

Test through the subject's public interface at the layer your claim names, asserting on outcomes rather than spying on internal collaborators. For example, call processPayment() and assert the whole Result value instead of checking that an internal validator was called.

Write factory functions that accept Partial<T> overrides and return complete, scenario-valid objects, reusing the production schema via parse when one exists. Compose factories for nested objects and use Partial<Pick<T, ...>> to constrain which fields callers can override.

Use an exact file or name selector only to prove RED or debug. For GREEN/REFACTOR, prefer a proven repository-owned watcher, then runner-derived affected scopes like vitest --changed or jest --changedSince, never hand-picked test files.

Coverage theater is executing code without proving behavior, such as mocking the function under test or asserting only that a spy was called. Avoid it by asserting on observable outcomes, covering edge cases and branches, and checking that tests would fail against realistic mutants.

No. Organize tests around stable behaviors or contracts rather than mirroring implementation files one-to-one. A 1:1 file is acceptable only when that file itself is the public unit under test.

Do not use it for UI-specific testing, which is explicitly out of scope per the skill description. For mutation analysis depth, load the separate mutation-testing skill, and for the RED-GREEN-REFACTOR workflow itself, load the TDD skill.