agentleFS
lgtm-hqlgtm-hq/ai-skills/skills/analyze-tests/SKILL.md

analyze-tests

Skill1 starsChanged 10 days agoMITView on GitHub

Test suite analysis. Use when asked to analyze, review, or evaluate a project's tests for quality, coverage gaps, and best practices.

The file

We split this skill into the rules it gives an agent

8 rules. About 0 are common, 6 are distinctive, and 2 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈6

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    When asked to analyze test quality:

    line 13
  2. Very specific:

    If lintro is unavailable, use the project's native test command with coverage (uv run pytest --cov, bun test --coverage, cargo llvm-cov, …

    line 23
  3. Distinctive:

    Search for tests that assert little or trivially pass:

    line 30
  4. Very specific:

    When multiple tests differ only by input values, recommend @pytest.mark.parametrize or table-driven equivalents.

    line 59
  5. Distinctive:

    Verify tests are independent and deterministic.

    line 76
  6. Distinctive:

    Look for repeated boilerplate across tests in the same file.

    line 87
  7. Distinctive:

    Test isolation—do tests have side effects or depend on execution order?

    line 117
  8. Distinctive:

    Test naming—do names clearly describe the scenario and expected outcome?

    line 120

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Test Suite Analysis

Perform a focused analysis of this project's test suite. Follow the procedural workflow below; use the rubric sections as reference when interpreting findings.

Usage

When asked to analyze test quality:

1. Run coverage

Establish baseline coverage (prefer lintro when available):

uv run lintro tst    # runs tests with coverage when configured

If lintro is unavailable, use the project's native test command with coverage (uv run pytest --cov, bun test --coverage, cargo llvm-cov, etc.).

Note overall coverage percentage and files below threshold.

2. Find "nothing burger" tests

Search for tests that assert little or trivially pass:

# Empty or minimal assertions
rg -U 'def test_\w+.*\n(\s+pass|\s+assert True|\s+assert 1 == 1)' --type py

# Tests with no expect/assert (JS/TS)
rg -n 'it\(|test\(' --type ts --type js -A 5 | rg -B2 '^\s*\}\);?\s*$'

# Placeholder / TODO tests
rg -n '(test_|it\(|describe\().*(skip|todo|pending|\.only)' -i
rg -n '@pytest\.mark\.skip|pytest\.skip\(' --type py

Flag tests that don't validate real behavior.

3. Find missing parametrization

Detect copy-paste test patterns with similar names:

# Similar test function names (Python)
rg -n 'def test_\w+_\w+_\d+' --type py
rg -n 'def test_(create|update|delete|get)_' --type py | sort

# Repeated it() blocks with numeric suffixes (JS/TS)
rg -n "it\('.*\d+'" --type ts --type js

When multiple tests differ only by input values, recommend @pytest.mark.parametrize or table-driven equivalents.

4. Check isolation

Find shared mutable state and order-dependent tests:

# Module-level mutable state in test files
rg -n '^[A-Z_]+\s*=\s*\[\]|^[a-z_]+\s*=\s*\{\}' tests/ --type py
rg -n 'global |beforeAll|afterAll' tests/ -i

# Tests that modify shared fixtures or class state
rg -n 'self\.\w+\s*=' tests/ --type py
rg -n '@pytest\.fixture.*scope\s*=\s*["\x27]session' --type py

Verify tests are independent and deterministic.

5. Fixture reuse

Identify duplicated setup that should be shared:

rg -n '@pytest\.fixture|def setUp|beforeEach' tests/ --type py
rg -n 'def test_' -A 15 tests/ --type py | rg -c 'client\s*=|db\s*=|setup\s*='

Look for repeated boilerplate across tests in the same file.

6. Report gaps with specifics

For each finding, include:

  • File path and test function name (e.g., tests/test_auth.py::test_login_invalid)
  • Severity: Critical | Should Fix | Nice to Have
  • Concrete improvement (add parametrization, assert on behavior, extract fixture, etc.)

Summarize coverage gaps: untested modules, missing edge cases, and integration points without tests.


Reference — Test Design & Quality

  • Overall test structure and organization
  • Adherence to testing best practices for the framework used
  • Alignment with SOLID and DRY principles

Reference — Problem Areas

  • "Nothing burger" tests—tests that pass trivially or don't validate real behavior
  • Missing parametrization where similar cases are tested with copy-paste
  • Overly complex test code that's hard to maintain
  • Large test files that should be split into logical groupings

Reference — Test Hygiene

  • Test isolation—do tests have side effects or depend on execution order?
  • Flaky tests—tests that pass/fail inconsistently
  • Mocking practices—appropriate use vs. over-mocking that hides real bugs
  • Test naming—do names clearly describe the scenario and expected outcome?
  • Setup/teardown—duplicated fixtures that should be shared
  • Execution time—slow tests that could be optimized or parallelized

Reference — Coverage Gaps

  • Edge cases and failure modes not adequately tested
  • Integration points lacking coverage

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.