60-validate-tests-150

name	60-validate-tests-150
description	[60] VALIDATE. Ensure new (staged and unstaged) changes are covered by tests at >70% and the full test suite is green. Use when asked to validate coverage for recent changes, add tests for modified code, or verify nothing else broke.

Validate-Tests 150 Protocol

Goal

Cover current uncommitted changes with meaningful tests at >70% coverage (including the changed lines) and confirm the entire test suite is green.

Workflow

1. Identify current changes

   • Check staged and unstaged changes (git status).
   • List changed files (git diff --name-only and git diff --name-only --staged).
   • Focus testing on these files and their direct dependencies.

2. Find the coverage command

   • Check package.json scripts for test, coverage, or ci.
   • If unclear, search for Jest/Vitest config files and default coverage options.

3. Run coverage

   • Execute the project’s coverage command.
   • Save the exact overall percentage and per‑file coverage for changed files (lines/branches).
   • Passing tests ≠ coverage: verify that the changed lines are executed (use coverage reports to confirm).

4. Prioritize targets

   • Start with changed files that are <70% covered.
   • Prefer pure functions, utilities, and deterministic logic.

5. Add tests

   • Write tests that directly exercise the changed logic/markup and assert behavior, edge cases, and failure paths.
   • Prefer behavior- or structure-level assertions that map to the changed lines (e.g., DOM structure/classes for UI changes).
   • Avoid snapshot‑only tests unless behavior is visual and stable.

6. Re‑run coverage

   • Confirm each changed file is > 70% covered (lines/branches where available).
   • Confirm the specific changed lines are covered (use coverage reports or direct evidence in tests).
   • If coverage tooling only provides overall numbers, explain the limitation and justify how tests exercise the changed code.
   • If not met, repeat steps 4–6.

7. Run full test suite

   • Execute the standard full test command for the repo (not just a subset).
   • Ensure all tests are green.

8. Run lint

   • Execute the standard lint command for the repo.
   • Ensure lint is green and fix lint errors introduced or surfaced in the process.
   • Do not leave lint in a failing state.

9. Run compile

   • Execute the standard compile command for the repo npm run compile or tsc --noEmit, best way is from root directory npm run test && npm run lint:full
   • Ensure compile is green and fix compile errors introduced or surfaced in the process.
   • Do not leave compile in a failing state.

10. Report

• Summarize added tests, coverage changes, and full test results.
• Note any files intentionally excluded or skipped and why.

Validation checklist

• Staged and unstaged changes identified.
• Coverage command found and recorded.
• Baseline coverage captured.
• Tests added for changed files and direct dependencies.
• Changed files are >70% covered (lines/branches where available).
• Full test suite executed.
• All tests are green.
• Lint executed and green.
• Compile executed and green.

Output expectations

• Provide the command used to measure coverage, to run the full test suite, and to run lint.
• Provide before/after coverage numbers and per‑file coverage for changed files.
• Explicitly state how the changed lines are exercised by the tests.
• List which files were targeted and why.
• Confirm the final threshold is met for changed files, or report remaining gaps.
• Confirm all tests and lint are green.
• Confirm compile is green.