test-code-review

Test Code Review

Based on test code, execution evidence, and change scope, identify risks in assertions, isolation, fixtures, determinism, and maintainability, and output TCR-## findings. It only organizes traceable test engineering quality candidates; it does not execute tests, nor does it write design checklists as coverage, pass, or release evidence.

When to Use

• Need to extract Test Code Review candidates from test code, test fixtures, assertions, dependency injection, run history, failure logs, change diffs, and CI configuration.
• Need to explain the rationale for selection, applicable constraints, evidence gaps, and minimal verification actions.
• Materials are incomplete but a limited initial version must still be delivered, and blocked or unassessed boundaries must be made explicit.

Not applicable to directly executing tests, generating behavior conclusions without sources, replacing a complete test strategy, or accepting risk on behalf of a Human.

Output Format Options

• Default output is Markdown; tables, JSON, or CSV are used only when the user explicitly needs them or the existing delivery format requires them.
• Keep static analysis, unexecuted items, evidence status, and Human decisions separate; when there is no execution evidence, keep them as unassessed, blocked, or NOT_RUN.

How to Use

1. Read prompts/test-code-review.md, and provide the objective, scope, materials, environment, and existing evidence.
2. First complete the six-category input audit: known, missing, conflicting, stale, out_of_scope, and assumptions.
3. Use TCR-## to record the object, preconditions, concerns, source evidence, and verification method, and retain impact/priority, responsible role, closure conditions, and evidence status.
4. When materials conflict, constraints are missing, or there is no execution evidence, retain both sides and the open questions.

Domain Execution Key Points

• First mark the behavior under test and how the test should fail when it fails, trace assertion by assertion whether actual values come from the object under test, and check for tautologies, type-only assertions, or swallowed exceptions with no failure exit.
• Deliver line numbers/snippets, protected obligations, missed counterexamples, and fix verification; allow comparisons with correctly isolated tests that have a failure exit.
• When forming domain candidates, you must read and follow prompts/test-code-review.md domain operations and decision process, retaining legitimate comparisons, evidence gaps, and verification actions item by item.

Core Constraints

• Do not execute tests, do not assume rules, versions, thresholds, data, or results that were not provided, and do not treat the number of candidates as proof of coverage.
• File existence, name matching, design claims, or Eval configuration do not equal real execution evidence.
• Mark unknowns as unassessed, blocked, or to be confirmed; do not fill them in with common sense.
• Do not modify requirements, code, test assets, or the target system.

Pre-Delivery Self-Check

• The six-category input audit has been recorded: known, missing, conflicting, stale, out_of_scope, and assumptions.
• Each TCR-## has a source, evidence status, impact/priority, responsible role, closure conditions, and verification method.
• Facts, inferences, recommendations, unexecuted items, and Human decisions have been distinguished.
• Design candidates have not been written as execution results, coverage proof, or release conclusions.

Reference Files

• During regression, read evals/eval.yaml and matching test cases; configuration does not prove real project results.
• Trigger validation uses evals/trigger-prompts.csv and evals/local-rules.json; when skill.selection evidence is missing, report BLOCKED.

Common Pitfalls

• When the scope or evidence is incomplete, do not write method names, file existence, or candidate counts as test executed, covered, passed, or release evidence.
• Do not use common sense to fill in rules, thresholds, data, environments, or results that were not provided; retain unassessed, blocked, and to-be-confirmed items.
• Do not expand this Skill's specialized candidates into a complete strategy, complete test cases, actual execution, or release decisions.

Best Practices

• Complete the six-category input audit first, then choose the smallest, traceable, and verifiable discovery scope.
• For each finding, retain the source, evidence status, impact/priority, responsible role, closure conditions, and verification method, and clearly state the residual risk.
• Write verification recommendations as next-step actions, and do not upgrade the Skill package structure, candidate counts, or local Eval configuration into real quality conclusions.