test-smell-detection
Deep-dive audit using the full testsmells.org 19-smell academic catalog for tests in any language. Every finding maps to a named, citable smell from the research literature (Assertion Roulette, Duplicate Assert, Mystery Guest, Eager Test, Sensitive Equality, Conditional Test Logic, Sleepy Test, Magic Number Test, etc.) with research-backed severity. TS/JS (Jest/Vitest/Mocha/node:test), Java (JUnit/TestNG), Go, Ruby (RSpec/Minitest), Rust, Swift, Kotlin (JUnit/Kotest), PowerShell (Pester), C++ (GoogleTest/Catch2). INVOKE ONLY when explicitly asked for the testsmells.org 19-smell academic catalo
npx skills add dotnet/skills --skill test-smell-detection --agent claude-code
Same command for any agent — swap --agent for codex, cursor, copilot.
Weekly change comes from our own snapshots, not the repository page — it measures attention, not adoption.
What it does
Deep formal audit of test code in any supported language using an academic test smell taxonomy. Detects symptoms of bad design or implementation decisions that make tests harder to understand, more fragile, less effective at catching bugs, or more expensive to maintain. Produces a severity-ranked report with specific locations and actionable fixes.
How it works
- Detect language and load extension by identifying the target codebase's language. Call the
test-analysis-extensionsskill and read the matching extension file. The extension file lists framework-specific test markers, sleep / wait APIs, skip / ignore attributes, mystery-guest indicators, and integration-test markers. - Gather the test code by reading all provided test files or scanning a project for test files using markers in the language extension file. For thoroughness, consult the extended smell catalog referenced by the skill.
- Scan for test smells across methods and classes, using the patterns defined for each smell: Conditional Test Logic, Mystery Guest, Sleepy Test, Assertion-Free Test, Eager Test, Magic Number Test, Sensitive Equality, Exception Handling in Tests, General Fixture, and Ignored/Skipped Tests. Each smell has detection rules and language-agnostic descriptions mapped to framework idioms.
- Apply calibration rules to adjust severity or downgrade findings when appropriate (e.g., integration context; long-running sleeps not to be downgraded for sleeps; simple loop-asserts may be acceptable).
When to use it
- When a user asks for a comprehensive or formal test smell audit
- When a user asks "are my tests well-written?" and desires rigorous analysis
- When a user wants a test quality health check with academic rigor
- When a user wants a review of test design or structure using standard smell categories
What it can touch
This skill relies on the available tools declared in the skill metadata to perform the analysis. It uses the connected extension files to interpret language-specific markers, sleep APIs, and integration indicators.
Caveats
Facts about sensitivity and limitations are drawn from the described smell taxonomy, including language-specific exceptions and calibration notes. The audit emphasizes literature-backed smells and may downgrade certain findings in integration contexts or when idiomatic patterns are explicitly allowed by the language extension. No promises about remediation or outcomes are made beyond reporting detected smells and suggested factual calibrations.
# Test Smell Detection Deep formal audit of test code in any supported language using an academic test smell taxonomy. Detects symptoms of bad design or implementation decisions that make tests harder to understand, more fragile, less effective at catching bugs, or more expensive to maintain. Produces a severity-ranked report with specific locations and actionable fixes. > **Language-specific guidance**: Call the `test-analysis-extensions` skill to discover available extension files, then read the file matching the target codebase. The extension file documents test markers, sleep / time / random APIs, skip annotations, setup/teardown, mystery-guest indicators (file/database/network/env), integration markers, and language-specific calibration notes that drive the smell detectors below. ## Why Test Smells Matter Test smells erode confidence in a test suite and inflate maintenance costs: | Problem | Consequence | |---------|-------------| | Tests with conditional logic | Some paths never execute — hidden testing gaps | | Tests that depend on external resources | Flaky failures, slow execution, environment coupling | | Tests that sleep to wait for results | Non-deterministic timing, sl
- Why Test Smells Matter
- When to Use
- When Not to Use
- Inputs
- Workflow
- Step 1: Detect language and load extension
- Step 2: Gather the test code
- Step 3: Scan for test smells
- Step 4: Apply calibration rules
- Step 5: Report findings
- Validation
- Common Pitfalls
What does the test-smell-detection skill do?
Deep-dive audit using the full testsmells.org 19-smell academic catalog for tests in any language. Every finding maps to a named, citable smell from the research literature (Assertion Roulette, Duplicate Assert, Mystery Guest, Eager Test, Sensitive Equality, Conditional Test Logic, Sleepy Test, Magic Number Test, etc.) with research-backed severity. TS/JS (Jest/Vitest/Mocha/node:test), Java (JUnit/TestNG), Go, Ruby (RSpec/Minitest), Rust, Swift, Kotlin (JUnit/Kotest), PowerShell (Pester), C++ (GoogleTest/Catch2). INVOKE ONLY when explicitly asked for the testsmells.org 19-smell academic catalo
How do I install it?
Run `npx skills add dotnet/skills --skill test-smell-detection --agent claude-code` — it drops the skill into your project so the agent can pick it up. Swap the --agent value for codex, cursor or copilot if you use one of those.
Where does this skill come from?
From dotnet/skills, a repository with 4,927 stars. We read it straight from the repository tree rather than a submitted listing, so what you see here is what is actually published.
Is a popular skill a good skill?
Not necessarily. Stars measure attention, not adoption — a repository can trend for a week and be abandoned. That is why we show the weekly change from our own snapshots next to the total, instead of a single flattering number.