/test-anti-patterns

name: test-anti-patterns
description: >
  Audits an existing test file or suite in any language for anti-patterns
  and quality issues — produces a severity-ranked report
  (Critical/Warning/Info). INVOKE whenever asked to audit or review tests,
  find what's wrong with a suite, judge whether tests are any good, or
  check for: tests that pass but verify nothing, missing assertions,
  swallowed exceptions, self-comparing / tautological assertions,
  coverage-touching tests, broad exceptions, flaky or order-dependent tests
  (Thread.Sleep, DateTime.Now, shared state), duplicated tests, or magic
  values — in .NET, Python/pytest, TS/Jest, Java, Go, Ruby or C++. DO NOT
  USE FOR: writing new tests (use code-testing-agent, or writing-mstest-tests
  for MSTest); running tests (use
  run-tests); migration; assertion-diversity metrics (use assertion-quality);
  coverage/CRAP metrics (use coverage-analysis); the testsmells.org academic
  catalog (use test-smell-detection); fixing or modernizing MSTest tests,
  assertions, attributes, or lifecycle (use writing-mstest-tests).
license: MIT

Test Anti-Pattern Detection

Quick, pragmatic analysis of test code in any supported language for anti-patterns and quality issues that undermine test reliability, maintainability, and diagnostic value.

> **Language-specific guidance**: Call the `test-analysis-extensions` skill to discover available extension files, then read the file matching the target codebase (e.g., `extensions/dotnet.md`, `extensions/python.md`, `extensions/typescript.md`, `extensions/go.md`). The extension file tells you which sleep / time / random / skip / setup-teardown / mystery-guest APIs to look for in that language.

When to Use

• User asks to review test quality or find test smells
• User wants to know why tests are flaky or unreliable
• User asks "are my tests good?" or "what's wrong with my tests?"
• User requests a test audit or test code review
• User wants to improve existing test code

When Not to Use

• User wants to write new tests from scratch (use `code-testing-agent` for any language, or `writing-mstest-tests` for MSTest specifically)
• User wants direct implementation fixes rather than a diagnostic review (use the relevant write/edit skill)
• User asks to fix swapped `Assert.AreEqual` argument order in MSTest (use `writing-mstest-tests`)
• User asks to convert MSTest `DynamicData` from `IEnumerable<object[]>` to `ValueTuple` (use `writing-mstest-tests`)
• User wants to run or execute tests (use `run-tests` for .NET)
• User wants to migrate between test frameworks or versions (use migration skills)
• User wants to measure code coverage (out of scope)
• User wants a deep formal test smell audit with academic taxonomy and extended catalog (use `test-smell-detection`)

Inputs

| Input | Required | Description | |-------|----------|-------------| | Test code | Yes | One or more test files or classes to analyze | | Production code | No | The code under test, for context on what tests should verify | | Specific concern | No | A focused area like "flakiness" or "naming" to narrow the review |

Workflow

Step 1: Detect language and load extension

Identify the target codebase's language and test framework. Call the `test-analysis-extensions` skill and read the matching extension file. The extension file documents framework-specific anti-pattern markers — what counts as a sleep/wait, a test marker, a skip, a setup/teardown, a shared-state hot spot, and an integration boundary — so this skill stays language-neutral.

Step 2: Gather the test code

Read the test files the user wants reviewed. If the user points to a directory or project, scan for all test files using the discovery markers in the loaded language extension file (e.g., `[TestClass]`/`[Fact]`/`[Test]` for .NET, `test_*.py` / `def test_*` for pytest, `*.test.ts` / `it()` for Jest, `*Test.java` / `@Test` for JUnit, `*_test.go` / `func TestXxx` for Go, `*_spec.rb` for RSpec, `#[test]` for Rust, `*.Tests.ps1` / `Describe` for Pester, `TEST(...)` for GoogleTest, `TEST_CASE(...)` for Catch2/doctest).

If production code is available, read it too -- this is critical for detecting tests that are coupled to implementation details rather than behavior.

Step 3: Scan for anti-patterns

Check each test file against the anti-pattern catalog below. Report findings grouped by severity. The examples are .NET-centric but the patterns generalize — use the loaded language extension file to map each pattern to the framework you are auditing.

Critical -- Tests that give false confidence

| Anti-Pattern | What to Look For | |---|---| | **No assertions** | Test methods that execute code but never assert anything. A passing test without assertions proves nothing. In .NET look for missing `Assert.*`; in pytest a function with no `assert` and no `pytest.raises`; in Jest no `expect(...)`; in JUnit no `assert*`/`assertThat`; in Go a test that never calls `t.Error*`, `t.Fatal*`, or testify; in RSpec a block with no `expect`; in Pester no `Should`. Mock-call verifications (`verify(mock)`, `expect(mock).toHaveBeenCalled`, `Should -Invoke`) are real assertions. | | **Missing await on async assertions (JS/TS, .NET, Python, Kotlin, Swift)** | `expect(promise).resolves.toBe(x)` without `await`/`return`, `pytest-asyncio` test with un-awaited coroutine, `async Task` xUnit test calling `Assert.ThrowsAsync` without `await`, Kotest suspending test without `runTest`, Swift Testing async test without `await`. These tests silently pass even when the underlying assertion would have failed. | | **Coverage touching** | Test class that methodically calls every public member on a type — often in alphabetical or declaration order — without asserting meaningful outcomes. Each test typically does `var result = sut.MethodName(...)` (or `result = sut.method_name(...)`, `sut.methodName()`, `sut.MethodName(t)`) with no assertion, or only a trivial null/None/nil check. The intent is t