testing-scan

Analyzes a codebase's test suites to map coverage, quality, and gaps against Sokrates analysis data.

3|1|Updated Aug 26, 2026
One-click install
npx skills add https://github.com/zeljkoobrenovic/sokrates-skills --skill testing-scan-zeljkoobrenovic
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: testing-scan
Source: https://github.com/zeljkoobrenovic/sokrates-skills/tree/main/skills/scanners/testing-scan
Command: npx skills add https://github.com/zeljkoobrenovic/sokrates-skills --skill testing-scan-zeljkoobrenovic

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes scripts (resource) components.

What problem does it solve? Teams often cannot answer how well their code is actually tested: which components have real tests, which tests assert anything meaningful, which are flaky or skipped, and which load-bearing paths have no test at all. This Skill reads a project's tests as a system and produces verifiable, evidence-backed findings about test coverage, quality, and risk. ## Core Features & Use Cases - Test model inventory: Classifies unit, integration, end-to-end, snapshot, property, fuzz, and doc tests with frameworks, runners, and test-to-main LOC ratios per component, including inline tests like Rust #[cfg(test)] modules that path-based tools miss. - Reference-inferred coverage map: Grades each component as well, adequate, thin, or untested based on which tests reference its files, without running a coverage tool or the test suite. - Quality and gap analysis: Detects weak assertions, over-mocking, nondeterminism (sleeps, wall-clock, randomness, network), flaky and skipped tests, and untested hotspots, main loops, persistence, and error paths, synthesized into a testing posture. - Use Case: After running a Sokrates analysis on a large repository, ask how well the payment module is tested; the Skill counts test sites with its script, cross-references hotspot and architecture findings, and reports that the payment writer has no referencing test at any layer. ## Quick Start Ask the AI to run the testing scan on this repository using the existing _sokrates analysis and report which components are thinly tested or untested.

Frequently Asked Questions about testing-scan

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I find untested code without a coverage tool?▼

Infer coverage from what tests reference: which test files import or mention each component's files, at which layer, and how deeply. This Skill's script counts test references per load-bearing main file, grading components well, adequate, thin, or untested without running the suite.

How to measure test-to-code ratio including Rust inline tests?▼

Path-based classifiers miss tests inside main files like Rust #[cfg(test)] modules. The count_test_sites.py script measures both path-based test files and inline test modules per crate, reporting separate and combined test-to-main LOC ratios per component.

Does this work without a Sokrates analysis?▼

Yes, it degrades gracefully. A Sokrates _sokrates folder provides the test file inventory, per-component file lists, and churn history as a starting point, but the script can scan any source root directly and still produce the test model and quality findings.

Can it detect flaky or skipped tests automatically?▼

Yes. The script pattern-matches flakiness markers (retry, flaky, xfail), skip annotations (#[ignore], @Disabled, it.skip, pytest.mark.skip), and nondeterminism sources like sleeps, wall-clock reads, unseeded randomness, and real network calls, with file and line evidence.

What are the limitations of reference-based test coverage analysis?▼

It never runs the test suite and never claims a coverage percentage; it reports statements like no test imports X. Grades come from references and inventory, so deep behavioral coverage of individual functions still requires a real coverage tool such as JaCoCo or cargo-llvm-cov.