A test can pass and still fail to protect the product. Weak assertions, shared fixtures, hidden time dependence, and accidental network calls make green results hard to trust.
Why this Skill is needed
The Test Code Review Skill identifies assertion, isolation, fixture, determinism, and maintainability risks from supplied test code and evidence. It produces TCR-## findings; it does not execute tests or call candidate counts coverage.
What the Skill does
The review asks whether the test would fail for the defect it claims to protect against.
Use this Skill during test-code changes, flaky-test investigations, fixture refactors, or CI review when the team needs evidence-backed quality candidates and a smallest validation action.
A good TCR finding names the test subject, precondition, concern, source evidence, validation, impact, priority, owner, close condition, and evidence state.
Use it when a test suite changes and its reliability, isolation, or maintenance cost needs review before trusting a new green run.
What it does not do
The Test Code Review Skill can organize material, evidence, and next actions for Assertion finding. It does not replace:
- Confirmation of rules, scope, and risk by the accountable domain owner.
- A real environment, account, dataset, log, or run record; static analysis does not become runtime evidence by itself.
- Authorization for release, compliance, production actions, or residual-risk acceptance.
- A Human decision when supplied sources conflict.
What it checks
The value of this Skill is not another keyword list. It connects each focus area to an observable input, a judgment, and a way to close the loop. Start with a small matrix based on the source Skill’s output contract:
| Focus | Question before analysis | Handoff output |
|---|---|---|
| Assertion finding | Whether the assertion detects the intended defect | TCR ID and source |
| Isolation finding | Shared state, network, time, or order dependence | Evidence state |
| Determinism finding | Fixture, randomness, clock, or retry instability | Reproduction need |
| Validation action | Smallest safe check before trusting the test | Owner and method |
If a row has only a conventional expectation and no source or validation method, keep it open instead of turning it into a pass.
Audit inputs before you start
Before analyzing Assertion finding, classify the input into six evidence states. A gap is not automatically a failure, but it must not disappear inside the conclusion.
| State | Meaning | How this Skill should handle it |
|---|---|---|
| known | Directly supported by the supplied material | Keep the source, version, and time with the judgment |
| missing | Needed for this pass but not supplied | Name the smallest evidence action and limit the conclusion |
| conflicting | Sources disagree | Show both sources and route the conflict to an owner |
| stale | Present but outside the relevant version or time window | Mark freshness; old evidence is not current proof |
| out_of_scope | Related but excluded from this pass | Keep the boundary explicit |
| assumptions | Temporarily adopted to continue analysis | State how and when the assumption will be checked |
Keep the input version, scope, environment, evidence locations, and accountable owner together. Without a run record, deliver analysis, design, or a validation plan—not an execution pass.
From problem to structured Finding
Connect the source, scope, evidence state, analysis, owner, action, close condition, and validation before writing the conclusion. The case below keeps this Skill’s identifier and domain context.
Keep the decision layers separate
For Assertion finding, do not compress four different kinds of language into “recommended to pass”:
| Layer | How to write it | Application here |
|---|---|---|
| Fact | What the supplied material directly shows | Cite the source, version, input, or run record for the focus |
| Evidence-backed Inference | What several facts support together | Show the inference chain and retain uncertainty |
| Recommendation | The smallest next action | Name the evidence, review, execution, or regression path |
| Human Decision | What an accountable person must decide | Leave scope, risk acceptance, resources, and release meaning to the owner |
A complete case
This case follows Input, Analysis, Finding, Decision, and Validation. When material is incomplete, keep missing, conflicting, or assumptions visible instead of turning them into a pass.
Input
| Material | What to provide | What to do when it is missing |
|---|---|---|
| Test code and diff | Assertions, fixtures, setup, mocks, dependencies, and changed lines | Mark unsupplied code out of scope |
| Behavior contract | Requirement, expected outcome, error rule, and data boundary | Do not infer missing expectations |
| Run evidence | Failure logs, reruns, duration, environment, and CI config | Keep static review separate from runtime |
| Maintenance context | Owners, duplication, helper APIs, and historical failures | Record unknown history |
Use a request like this:
Use the test-code-review Skill.
Task: Review a new checkout API test that uses a shared database fixture and asserts only HTTP 200.
Inputs: [diff, requirement, fixture code, mock config, CI run log, failure history]
Scope: [API tests in the pre-merge suite]
Constraints: [do not execute tests or edit code]
Produce TCR-## findings with concern, source evidence, impact, owner, close condition, validation, and evidence state. Do not turn candidate findings into coverage or pass claims.Analysis
Use the input, matrix, and evidence state to form the judgment before writing the Finding; keep missing material as a gap.
Finding
Focused example: Question a green API test that asserts only 200
The endpoint returns 200 even when the response body contains an error code, and the shared fixture leaves records between tests. The Skill should identify weak assertion and isolation risks, ask for the contract’s expected error semantics, and propose a controlled fixture cleanup check. It should not run or claim the test suite failed.
The review produces test-engineering candidates from supplied material. It cannot prove a defect exists, a test passes, or coverage is complete without execution evidence.
Example finding: turn one problem into a handoff
The field example below shows the recording pattern; it is not an execution result.
If the supplied material cannot prove that Assertion finding meets its contract, write the finding like this. It does not invent the missing rule or turn missing evidence into a failure.
| Field | Example wording |
|---|---|
| Source and scope | Record the requirement, version, environment, and the concrete object for Assertion finding |
| Finding | The condition or result for Assertion finding is not yet traceable to evidence |
| Evidence state | missing / assumptions; use conflicting when sources disagree |
| Impact and priority | Name the affected user, journey, or delivery decision without inflating severity |
| Owner and Human decision | Ask the product, engineering, security, or test owner to confirm the rule and trade-off |
| Action and close condition | Add the smallest missing evidence; close only when source, judgment, and owner can be reviewed |
| Validation | Name one repeatable check, query, or run and retain the raw artifact |
The point is to let the next person walk from the finding back to the source and run an action that can change the decision.
Decision
The accountable owner confirms the decision question and risk trade-off; the Skill does not make that choice.
Validation
Before closing the finding, run the stated validation and retain the raw artifact. Without an execution record, the status remains unverified.
How a Finding enters the next stage
Handoff output
| Output field | Why it exists | Example status |
|---|---|---|
| Assertion finding | Whether the assertion detects the intended defect | TCR ID and source |
| Isolation finding | Shared state, network, time, or order dependence | Evidence state |
| Determinism finding | Fixture, randomness, clock, or retry instability | Reproduction need |
| Validation action | Smallest safe check before trusting the test | Owner and method |
Every conclusion should point to a source, evidence state, and next action. If evidence is missing, use pending, blocked, unassessed, or NOT_SCORED instead of filling the gap with confidence.
Next-stage route
At minimum, hand off the source, evidence state, owner, close condition, and validation action; the next-stage conclusion remains bounded by the evidence state.
How to prepare better input
Provide the changed test, fixture and helper code, behavior contract, CI configuration, relevant run records, and failure history. If execution evidence is missing, mark runtime conclusions NOT_RUN.
A useful handoff includes input versions, scope, time window, evidence index, assumptions, Human decision boundary, and the smallest validation action.
Working with other Skills
- Test Suite Health Analysis:examines suite-level flakiness and maintenance.
- Mock Quality Review:checks whether mocks preserve the contract.
- Test Effectiveness Analysis:relates test signals to defects and risks.
Common traps
- Treating a method name or test count as proof that the intended behavior is checked.
- Reviewing assertions without the requirement or API contract.
- Assuming a shared fixture is isolated because each test creates a different label.
Install and invoke
npx skills add https://github.com/naodeng/awesome-qa-skills/tree/main/skills/en/testing-types/test-code-review -gUse the test-code-review Skill.
Include objective, scope, versions, evidence paths, constraints, and decision boundary.
Audit inputs first, preserve evidence states, and finish with owner, close condition, and validation method.FAQ
Can the Skill fix the test code?
No. It identifies traceable review findings and validation actions; code changes need a separate implementation request.
Can a static assertion review prove the test catches a defect?
No. It can identify a weak assertion and propose a check; execution with a meaningful failing condition is separate evidence.
The Skill is most useful when attached to one real project artifact and kept with its source evidence. Start narrow, validate the uncertain part, and expand only when evidence supports it.
References
Source Skill and execution contract
The complete execution contract lives in Test Code Review prompt. The source directory may also contain evaluation cases and supporting material.
Static plans, file presence, and dry runs keep their evidence state. They do not become runtime proof, an all-passed claim, or release approval.
Reference links
- Test Code Review prompt:https://github.com/naodeng/awesome-qa-skills/tree/main/skills/en/testing-types/test-code-review/prompts/test-code-review.md
- Test Code Review Skill source:https://github.com/naodeng/awesome-qa-skills/tree/main/skills/en/testing-types/test-code-review
- Test Code Review details:https://inaodeng.com/en/qaskills/test-code-review/
- Awesome QA Skills on GitHub:https://github.com/naodeng/awesome-qa-skills