Ui test rubric
Personal Claude Code setup for TDD
npx -y skills add volodymyrkoval/tdd-claude --skill ui-test-rubricAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Apply when writing a UI integration test at a component seam, when reasoning about test scope at component boundaries, when deciding what to mock in a UI test, or when an integration test is hard to write — re-check scope. Reusable by both ui-integration-tester (writer) and future ui-integration-auditor (auditor).
SKILL.md
2.4 KB, as published. Nobody here has run it
1. Scope — test one component seam
The test exercises the contract between two components at their boundary. It renders the parent with real child components (no mocks of children). It does not test internals of either side — only the observable output that crosses the seam. One seam per test file.
2. What to mock — only things that leave the process
Mock: network calls, browser APIs (localStorage, fetch, navigator), timers, third-party SDKs that hit the network.
Do NOT mock: child components, sibling components, internal hooks, internal modules, shared utilities.
Explicit prohibition: do NOT add vi.mock(...) calls for child components anywhere in the test file. Do NOT inherit a mock of a child component from a setup/global file — if such a mock exists, override it to use the real implementation in this test.
3. Test anatomy — render → interact → assert user-visible output
- Render the parent component with realistic (not minimal) props.
- Interact via user events (fireEvent / userEvent) — not by calling component methods directly.
- Assert on user-visible output: text, ARIA roles, DOM attributes visible to the user. Do not assert on implementation details (state variables, internal callbacks, prop forwarding).
4. Red criterion — behavioral, not structural
The test must fail because of a missing behavior, not because of a missing file or missing import. module-not-found is acceptable red only before scaffolding files exist; once the surface exists, red must be a behavioral assertion failure. A passing test that "asserts nothing" (no expect()) is not a valid green — add at least one behavioral assertion before calling it green.
5. Mutation check (self-discipline)
After writing the test, mentally delete the implementation of the behavior under test. The test must still fail (red) when the behavior is absent. If the test would pass with the behavior deleted, the assertion is testing structure, not behavior — rewrite it. (This is a self-check discipline. No tooling enforced here — the auditor sibling validates later.)