SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsreview-tests

review-tests

Testing & quality

View repository

Updated 10-16 01:30

About this skill

Test Review (Review Tests)

Positioning

A pure diagnostic tool. It reads an existing test, identifies blind spots, lists suggestions,produces an HTML report。

This skill does not write tests, does not modify tests, and does not touch source or config. It is only responsible for "pointing out problems" and presenting the results as a report. Whether to fill the gaps and how to fill them is up to the user.

Three hard rules (highest priority)

  1. Diagnose only, do not modify existing files: Do not modify any source, test file, or config file. The only permitted write isgenerating a new HTML report fileto .review-tests/。
  2. Filling tests goes to tdd: For the gaps listed in the report, ask the user to use the tdd skill to fill them one red-green at a time. Do not batch-fill them here.
  3. List only behavior-level blind spots: Suggested tests must always be described in terms of "what behavior should be verified." It is strictly forbidden to suggest tests that cling to implementation details just to chase coverage — such tests will produce false alarms during refactoring, violating the tdd principle of "test behavior, not implementation."

Language and Output Conventions

  • The report content uses Traditional Chinese (Taiwan usage).
  • Technical terms remain in English, such as Vitest, TypeScript, mock, coverage.
  • Code blocks, file names, and identifiers must never be modified or translated.
  • Express things in logically fluent Chinese, do not translate English word-for-word: Keep proper nouns such as function names, API fields, and enum values in their original English, but make the sentences natural so the user understands at a glance. Focus on "why it is a problem"; do not pile on jargon or stiff literal translations.

Input

  • No arguments: Ask the user for the target file path.
  • Specified file：review-tests <path>. You can provide a test file, or provide a source file and this tool will find the corresponding test file.

Process

  1. Locate the test and source: Read the target. If a source file is given, find the corresponding test file; if a test file is given, find the source file it imports. If no test file is found, report "no tests yet" and suggest switching to tdd to build from scratch, and the process ends.
  2. Check: Against the five categories of dimensions below, examine the test content item by item, produce findings, and mark each one with a severity level (high= would produce a false green light or mask a real bug,med= insufficient verification power,low= readability and conventions).
  3. Locate the key source snippet: Foreach finding , find the source function being tested (not the test in the spec; language is not limited to TS), and note down: the function name, the source file path, andthe key line range truly relevant to this finding(usually 3–8 lines, not the entire function — showing the whole function drowns out the key points and makes them hard to find).
  4. Generate the HTML report: Following the spec below, write a single-file HTML to .review-tests/, and open it automatically.
  5. End. Do not add tests, do not modify any existing files.

Five categories of review dimensions

Every finding must be tagged to aspecific test file line number or test description, and mapped to a source function.

1. Assertion Validity

  • Meaningless assertions, for example expect(true).toBe(true)。
  • tests that exist only to increase coverage and have no substantive verification.
  • Assertions that only use toBeDefined() to get by, without checking specific content.
  • The comment has already computed the exact expected value, yet the assertion only uses toBeGreaterThan(0) , a weak assertion like this.
  • error assertions are not strong enough:toThrow() does not verify the error type or message, or try/catch swallows the failure.
  • Huge snapshot (toMatchSnapshot()) that no one can finish reading = effectively no assertion.

2. Behavior Gaps

List omissions from a "behavior" perspective, described as "should verify X behavior",notlisting coverage numbers:

  • Missing happy path / edge case / boundary conditions.
  • Missing error handling, exception paths, null / undefined handling.
  • Important logic branches (if/else, switch) have no corresponding behavior verification.
  • Parameter combinations (such as different enum values, different modes) are not fully covered.

3. Mock Health

  • Over-mocking, mocking away the real paths that should be tested.
  • Mock data does not conform to the actual TypeScript interface definition.
  • Assertions cling to the implementation: verifying how many times a spy was called, the order of internal calls, rather than verifying the final behavior—this kind of test produces false alarms as soon as a refactor touches it.

4. Test Structure

  • Whether AAA (Arrange, Act, Assert) is followed.
  • Whether the test description clearly expresses the expected behavior.
  • Whether test side effects are cleaned up correctly.
  • Isolation between tests: is module-level mutable state reset in beforeEach , and will it contaminate each other due to execution order.

5. Determinism & Async

This kind of problem producesfalse green lights—the test passed but verified nothing, the highest value and also the easiest to miss:

  • Missing await assertions: the async assertion ends before it is awaited, so it always passes.
  • A promise with no return / no await, so the rejection is swallowed.
  • fake timers are not restored after use, contaminating later tests.
  • Depends on Date.now()、Math.random(), time zone, execution order, and other non-deterministic sources.
  • The test actually hits the network or touches real external services.

HTML Report Specification

The report is produced by the fixed generator render.cjs under the skill directory. The agent is only responsible for producing the findings data, do not hand-write HTML—escaping, syntax highlighting, layout, and backlink toggle are all built into the generator; hand-writing is prone to errors on the source snippet's < > & .

Execution Steps

  1. Write the analysis results as a findings JSON (schema see below), save it to a temporary path, for example /tmp/<name>-findings.json。
  2. in theproject rootexecute:node "<本 skill 目錄>/render.cjs" /tmp/<name>-findings.json
    • cwd must be the project root; the source/test paths in the JSON are based on this.
    • The generator prints the absolute path of the generated HTML.
  3. Auto-open: macOS open <路徑>、Linux xdg-open <路徑>、Windows cmd /c start "" <路徑>。
  4. The terminal prints only one line: the HTML path + a one-sentence health summary. The full content is in the HTML; do not reprint the entire report in the terminal. (.review-tests/ of .gitignore is placed automatically by the generator; the report will not be committed, so no separate reminder is needed.)

findings JSON schema

{
  "testFile":   "src/.../x.spec.ts",
  "sourceFile": "src/.../x.ts",
  "health":     { "level": "良好｜及格｜待補強", "summary": "一句話總評" },
  "sections":   [
    { "title": "斷言有效性", "findings": [
      { "desc": "通順中文，保留專有名詞",
        "loc": "spec 行 …",
        "level": "high｜med｜low（選填，預設 med）",
        "src": { "fn": "fnName", "file": "(選填，預設 sourceFile)", "from": 297, "to": 300, "lang": "(選填，預設依副檔名)" } } ] },
    { "title": "Mock 健康度", "clean": "無問題……" }
  ],
  "suggestions": [ "應該驗證 …" ]
}
  • level: severity.high= false green light / masking a real bug,med= insufficient verification power,low= readability and conventions. The generator sorts and colors by severity so the user knows which to fix first.
  • src: the backlink location of that finding.fn is the function name (used for the toggle title);from–to is thekey line range。file to expand, optional, filled in only when crossing files (for example, .vue the composable used is in another .ts）。lang optional: by default determined by file extension; the TS family (ts/tsx/js/jsx/vue) gets syntax highlighting, other languages are displayed as plain monospaced text.
  • Include only the key few lines, not the entire function: extract the piece of logic truly related to this finding (usually 3–8 lines). Expanding an entire function makes the user have to find the key point inside it. What is expanded is thebusiness code under test, not the spec.
  • Use fluent Chinese for the text, do not translate word for word：desc／suggestion／summary should read naturally and clearly explain "why it is a problem", keeping proper nouns in their original English. Only `code` and **bold** markup is supported; do not write raw HTML (the generator will escape it).
  • clean and findings choose one: if a category has no issues, give the clean string, do not force findings.
  • suggestions if there is nothing, give an empty array; the generator will skip the whole card and will not render an empty card.

Built into the generator (no need for the agent to worry about it, aligned with html-effectiveness)

  • Single-file HTML, all CSS/JS inline, zero external dependencies.
  • Light neutral refined style, health badge (good green / passing yellow / needs improvement red).
  • Backlink <details> toggle for each finding, lightweight syntax highlighting (DOM construction, no innerHTML), source snippets automatically escaped.

Notes

  1. Do not modify existing code: the only write is adding the HTML report file. No source/test/config is touched.
  2. Do not give numeric scores: only provide a qualitative health indicator. Numeric self-assessment is unreliable and should not be used as a threshold.
  3. Test framework: mainly targets Vue 3 + TypeScript + Vitest; the five dimensions are framework-agnostic principles and apply equally to Jest/Playwright/pytest, etc. Source snippets get syntax highlighting only for the TS family; other languages are displayed as plain text.

Execution

Please provide the target file path, and I will begin the checkup, generate the HTML report, and open it automatically.