New: 97,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Official agent skill

Test Anti Patterns

by microsoft in microsoft/testfx

Audits existing test code in any language for anti-patterns and quality issues — produces a severity-ranked report (Critical / Warning / Info) with concrete code-level fixes.

OfficialMITAuto-check passedTesting & QA

Install Test Anti Patterns

skills CLI
$ npx skills add microsoft/testfx --skill test-anti-patterns -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install microsoft/testfx test-anti-patterns --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/microsoft/testfx.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.agents/skills/test-anti-patterns .claude/skills/test-anti-patterns && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
test-anti-patterns
GitHub stars
1k
Token cost
~4.9k tokens
SKILL.md length
2,214 words
Files
1
Skills in repo
44
Repo updated
First seen
Licence
MIT

At a glance

Audits existing test code in any language for anti-patterns and quality issues — produces a severity-ranked report (Critical / Warning / Info) with concrete code-level fixes.

  • Works in 6 steps: Detect language and load extension → Gather the test code → Scan for anti-patterns → …
  • : writing new tests (use code-testing-agent
  • SKILL.md covers When to Use, When Not to Use, Inputs and Workflow, plus 2 more sections
  • Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md

What it does

Test Anti Patterns is an agent skill from microsoft/testfx, published by the product's own GitHub organization. Audits existing test code in any language for anti-patterns and quality issues — produces a severity-ranked report (Critical / Warning / Info) with concrete code-level fixes. Polyglot: .NET (MSTest/xUnit/NUnit/ TUnit), Python (pytest/unittest), 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 when asked to audit, review, rank, or find problems in existing tests — "audit my tests", "test…

Its SKILL.md is about 4.9k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Testing & QA, covering Unit testing. It works with .NET, JUnit, Python and TypeScript. The repository describes itself as: This repository holds the source code of Microsoft.Testing.Platform (MTP), a lightweight alternative to VSTest, as well as MSTest adapter and framework. The licence is MIT.

When your agent uses it

  • : writing new tests (use code-testing-agent
  • Writing-mstest-tests for MSTest)
  • Running tests (use run-tests)
  • Framework migration

Example prompts

  • “audit my tests”
  • “test smell audit”
  • “rank by severity”
  • “/test-anti-patterns”

Requirements

  • Python 3

Workflow steps

6 steps, taken from the step headings in SKILL.md.

  1. Detect language and load extension
  2. Gather the test code
  3. Scan for anti-patterns
  4. Calibrate severity honestly
  5. Report findings
  6. Prioritize recommendations

What it can do on your machine

Read from SKILL.md and the folder at commit 44b9dcc. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    No scripts in the folder and no shell commands in SKILL.md.

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Test Anti Patterns loads about 4.9k tokens when it runs. Until then it costs about 256 tokens; SKILL.md has 2,214 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~256
When it runs · the whole SKILL.md, loaded when a task matches
~4.9k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from microsoft/testfx at commit 44b9dcc, republished under its MIT licence (© microsoft). 2,214 words, ~4,906 tokens.

Download SKILL.mdSave it as .claude/skills/test-anti-patterns/SKILL.md (or your agent's skills folder).
name
test-anti-patterns
description
Audits existing test code in any language for anti-patterns and quality issues — produces a severity-ranked report (Critical / Warning / Info) with concrete code-level fixes. Polyglot: .NET (MSTest/xUnit/NUnit/ TUnit), Python (pytest/unittest), 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 when asked to audit, review, rank, or find problems in existing tests — "audit my tests", "test smell audit", "rank by severity", tests that pass but verify nothing, no/missing assertions, swallowed exceptions, always-true / self-comparing / tautological assertions, broad exception types, flakiness (sleep/Date.now/time.sleep), ordering dependency, shared global state, duplicated tests, magic values, missing await on async assertions. DO NOT USE FOR: writing new tests (use code-testing-agent, or writing-mstest-tests for MSTest); running tests (use run-tests); framework migration.
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

InputRequiredDescription
Test codeYesOne or more test files or classes to analyze
Production codeNoThe code under test, for context on what tests should verify
Specific concernNoA 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-PatternWhat to Look For
No assertionsTest 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 touchingTest 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 to inflate code-coverage metrics rather than verify behavior. Distinct from a single assertion-free test: the pattern is systematic coverage of the surface area with no real verification.
Self-referential assertionAsserts that the output of an operation equals its input when the operation is expected to be an identity or no-op, e.g. Assert.AreEqual(input, Parse(input.ToString())), assert input == parse(str(input)), expect(parse(input.toString())).toBe(input), assert.Equal(t, input, parse(input)). Also flags Assert.AreEqual(dto.Name, dto.Name) / assert dto.name == dto.name / expect(dto.name).toBe(dto.name) (asserting a field against itself). The test is tautological — it can only fail if the round-trip is broken, but never verifies that a transformation actually happened.
Swallowed exceptionstry { ... } catch { }, catch (Exception) without rethrowing or asserting (.NET); bare except: or except Exception: with pass (Python); try { ... } catch (e) {} (JS/TS/Java); defer recover() without re-panic and no assertion (Go); rescue StandardError with no assertion (Ruby); Result::unwrap_or(...) swallowing errors in a test (Rust); empty catch block (Kotlin/Swift).
Assert in catch block onlytry { Act(); } catch (Exception ex) { Assert.Fail(ex.Message); } (and equivalents in other languages) -- use Assert.ThrowsException / pytest.raises / expect(fn).toThrow / assertThrows / assert.Error(t, err) / #[should_panic] / Should -Throw / EXPECT_THROW instead. The test passes when no exception is thrown even if the result is wrong.
Always-true assertionsAssert.IsTrue(true), Assert.AreEqual(x, x), assert True, expect(true).toBe(true), assert.True(t, true), assert!(true), or conditions that can never fail.
Commented-out assertionsAssertions that were disabled but the test still runs, giving the illusion of coverage.
High -- Tests likely to cause pain
Anti-PatternWhat to Look For
Flakiness indicatorsWall-clock sleeps/waits used for synchronization: Thread.Sleep / Task.Delay (.NET), time.sleep (Python), setTimeout / await new Promise(r => setTimeout(...)) (JS/TS), Thread.sleep (Java/Kotlin), time.Sleep (Go), sleep (Ruby/Bash), std::thread::sleep (Rust), Start-Sleep (Pester), std::this_thread::sleep_for (C++). Wall-clock reads without abstraction: DateTime.Now/UtcNow, datetime.now()/datetime.utcnow(), Date.now() / new Date(), System.currentTimeMillis(), time.Now(), Time.now, Instant::now(), Date()/Date.now, Get-Date, std::chrono::system_clock::now. Unseeded randomness: new Random(), random.random()/random.randint(), Math.random(), new Random() (Java/Kotlin), rand.Int() without seed, rand (Ruby), rand::random() (Rust). Environment-dependent paths (hard-coded C:\..., /tmp/..., network hosts).
Test ordering dependencyStatic/global mutable state modified across tests; setup that doesn't fully reset state ([TestInitialize], setUp, beforeEach, before(:each), BeforeEach, t.Cleanup); tests that fail when run individually but pass in suite (or vice versa). Examples per language: static fields (.NET/Java), module-level globals (Python), top-level let/const in test file (JS/TS), var package globals (Go), class variables (Ruby), static mut/lazy_static!/OnceCell (Rust), $script: variables (PowerShell).
Over-mockingMore mock setup lines than actual test logic. Verifying exact call sequences on mocks rather than outcomes. Mocking types the test owns. Per language: Moq/NSubstitute/FakeItEasy (.NET), unittest.mock / pytest-mock (Python), Jest auto-mocks / Sinon (JS/TS), Mockito/PowerMock (Java), gomock/testify mock (Go), RSpec mocks/mocha (Ruby), mockall (Rust), MockK (Kotlin), Mock cmdlet (Pester), gmock (C++). For a deep mock audit in .NET, use exp-mock-usage-analysis.
Implementation couplingTesting private methods via reflection (MethodInfo.Invoke, getattr in Python, (thing as any) in TS, Field.setAccessible(true) in Java, Object#send in Ruby, internal pub(crate) access in Rust). Asserting on internal state instead of observable behavior. Verifying exact method call counts on collaborators instead of business outcomes.
Broad exception assertionsAssert.ThrowsException<Exception>(...) (.NET) / pytest.raises(Exception) / expect(fn).toThrow(Error) without a message matcher / assertThrows(Exception.class, ...) (Java) / assert.Error(t, err) without checking the kind / expect { ... }.to raise_error without class (RSpec) / #[should_panic] without expected = "..." / Should -Throw without -ExpectedMessage / EXPECT_ANY_THROW instead of EXPECT_THROW(stmt, SpecificType).
Medium -- Maintainability and clarity issues
Anti-PatternWhat to Look For
Poor namingTest names like Test1, TestMethod, test, names that don't describe the scenario or expected outcome. Good naming differs by language convention — see the loaded language extension file (e.g., Add_NegativeNumber_ThrowsArgumentException for .NET, test_add_negative_number_raises_value_error for pytest, addNegativeNumber_throwsArgumentException for Java, 'adds negative number throws' for Jest descriptions, TestAdd_NegativeNumber_ReturnsError for Go).
Magic valuesUnexplained numbers or strings in arrange/assert: Assert.AreEqual(42, result) / assert result == 42 / expect(result).toBe(42) -- what does 42 mean?
Duplicate testsThree or more test methods with near-identical bodies that differ only in a single input value. Should be parametrized: [DataRow]/[Theory]/[TestCase] (.NET), @pytest.mark.parametrize (pytest), test.each / it.each (Jest/Vitest), @ParameterizedTest + @ValueSource (JUnit 5), @DataProvider (TestNG), Go table-driven tests, where / shared examples (RSpec), #[rstest] (Rust), @ParameterizedTest + @MethodSource (Kotlin), -ForEach / -TestCases (Pester), INSTANTIATE_TEST_SUITE_P (GoogleTest), SECTION / GENERATE (Catch2), TEST_CASE_TEMPLATE (doctest). For a detailed duplication analysis in .NET, use exp-test-maintainability. Note: Two tests covering distinct boundary conditions (e.g., zero vs. negative) are NOT duplicates -- separate tests for different edge cases provide clearer failure diagnostics and are a valid practice.
Giant testsTest methods exceeding ~30 lines or testing multiple behaviors at once. Hard to diagnose when they fail.
Assertion messages that repeat the assertionAssert.AreEqual(expected, actual, "Expected and actual are not equal") / assert x == y, "x is not equal to y" / assertEquals(x, y, "values not equal") add no information. Messages should describe the business meaning.
Missing AAA / Given-When-Then separationArrange/Act/Assert (or Given/When/Then for BDD frameworks like RSpec, Kotest behavior specs, Pester) phases are interleaved or indistinguishable.
Show full SKILL.md (811 more words)Show less
Low -- Style and hygiene
Anti-PatternWhat to Look For
Unused test infrastructureSetup/teardown hooks that do nothing — [TestInitialize]/[SetUp]/[BeforeEach], setUp/@BeforeEach/@BeforeAll, beforeEach/beforeAll, before(:each)/before(:all), BeforeEach/BeforeAll (Pester), setUpWithError (XCTest) — and test helper methods that are never called.
Unmanaged resourcesTest creates disposable/closeable resources without cleanup: HttpClient/Stream without using (.NET), file/connection without with block or try/finally (Python), FileInputStream without try-with-resources (Java), defer file.Close() missing (Go), connection without ensure (Ruby), Drop not relied on / forgotten close (Rust), missing teardown for temp files / DBs in any language.
Print debuggingLeftover Console.WriteLine / Debug.WriteLine / print() / console.log / System.out.println / fmt.Println / puts / dbg! / Write-Host / std::cout statements used during test development.
Inconsistent naming conventionMix of naming styles in the same test class/module/file (e.g., some use Method_Scenario_Expected, others use ShouldDoSomething).
Step 4: Calibrate severity honestly

Before reporting, re-check each finding against these severity rules:

  • Critical/High: Only for issues that cause tests to give false confidence or be unreliable. A test that always passes regardless of correctness is Critical. Flaky shared state is High. Missing-await on async assertions is Critical (silent pass).
  • Medium: Only for issues that actively harm maintainability -- 5+ nearly-identical tests, truly meaningless names like Test1 / test / it1.
  • Low: Cosmetic naming mismatches, minor style preferences, assertion messages that could be better. When in doubt, rate Low.
  • Not an issue (per-language nuance):
    • Go and Rust table-driven loops with sub-tests (t.Run / for case in cases { ... }) are idiomatic, not "Conditional Test Logic". Do NOT flag.
    • pytest bare assert is the canonical assertion form, not a missing assertion library. Do NOT flag.
    • Go tests use if got != want { t.Errorf(...) } as canonical equality. Do NOT flag as ad-hoc.
    • Separate tests for distinct boundary conditions (zero vs. negative vs. null). Do NOT flag as duplicates.
    • Explicit per-test setup instead of [TestInitialize] / beforeEach (this improves isolation).
    • Tests that are short and clear but could theoretically be consolidated.

IMPORTANT: If the tests are well-written, say so clearly up front. Do not inflate severity to justify the review. A review that finds zero Critical/High issues and only minor Low suggestions is a valid and valuable outcome. Lead with what the tests do well.

Step 5: Report findings

Present findings in this structure:

  1. Summary -- Total issues found, broken down by severity (Critical / High / Medium / Low). If tests are well-written, lead with that assessment.
  2. Critical and High findings -- List each with:
    • The anti-pattern name
    • The specific location (file, method name, line)
    • A brief explanation of why it's a problem
    • A concrete fix (show before/after code when helpful)
  3. Medium and Low findings -- Summarize in a table unless the user wants full detail
  4. Positive observations -- Call out things the tests do well (sealed class, specific exception types, data-driven tests, clear AAA structure, proper use of fakes, good naming). Don't only report negatives.
Step 6: Prioritize recommendations

If there are many findings, recommend which to fix first:

  1. Critical -- Fix immediately, these tests may be giving false confidence
  2. High -- Fix soon, these cause flakiness or maintenance burden
  3. Medium/Low -- Fix opportunistically during related edits

Validation

  • Every finding includes a specific location (not just a general warning)
  • Every Critical/High finding includes a concrete fix
  • Report covers all categories (assertions, isolation, naming, structure)
  • Positive observations are included alongside problems
  • Recommendations are prioritized by severity

Common Pitfalls

PitfallSolution
Reporting style issues as criticalNaming and formatting are Medium/Low, never Critical
Suggesting rewrites instead of targeted fixesShow minimal diffs -- change the assertion, not the whole test
Flagging intentional design choicesIf Thread.Sleep / time.sleep / time.Sleep is in an integration test testing actual timing, that's not an anti-pattern. Consider context.
Inventing false positives on clean codeIf tests follow best practices, say so. A review finding "0 Critical, 0 High, 1 Low" is perfectly valid. Don't inflate findings to justify the review.
Flagging separate boundary tests as duplicatesTwo tests for zero and negative inputs test different edge cases. Only flag as duplicates when 3+ tests have truly identical bodies differing by a single value.
Rating cosmetic issues as MediumNaming mismatches (e.g., method name says ArgumentException but asserts ArgumentOutOfRangeException) are Low, not Medium -- the test still works correctly.
Ignoring the test frameworkUse correct terminology per the loaded language extension: xUnit [Fact]/[Theory], NUnit [Test]/[TestCase], MSTest [TestMethod]/[DataRow], pytest def test_* / @pytest.mark.parametrize, Jest it.each / describe, JUnit @Test / @ParameterizedTest, Go func TestXxx(t *testing.T) + table-driven, RSpec describe/it, Pester Describe/It, Rust #[test] / #[rstest], Catch2 TEST_CASE/SECTION.
Treating idiomatic patterns as smellsGo/Rust table-driven loops are idiomatic. Pytest bare assert is canonical. Go's if got != want { t.Errorf(...) } is canonical. JS/TS expect(mock).toHaveBeenCalledWith(...) is a real assertion, not an over-mock. Do NOT flag these.
Missing async-test pitfallsA Jest test that calls expect(promise).resolves.toBe(x) without returning/awaiting the promise silently passes; a TUnit/xUnit async Task test calling Assert.ThrowsAsync without await silently passes; pytest-asyncio tests with un-awaited coroutines silently pass. Always flag as Critical.
Missing the forest for the treesIf 80% of tests have no assertions, lead with that systemic issue rather than listing every instance

© microsoft, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in .agents/skills/test-anti-patterns of microsoft/testfx.

Open the folder on GitHubat commit 44b9dcc

Compare with similar skills

Test Anti Patterns next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Test Anti Patterns compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Test Anti Patterns this skillmicrosoft/testfx1k—~4.9kAutomated safety check: PassMIT
TDD Guidealirezarezvani/claude-skills28k—~3.4kAutomated safety check: PassMIT
TDD GuideLeoYeAI/openclaw-master-skills2.2k—~1.4kAutomated safety check: PassMIT
TDD GuideaAAaqwq/AGI-Super-Team1052 repos~1.1kAutomated safety check: PassMIT
Testing Unityonatangross/orchestkit288—~2.4kAutomated safety check: PassMIT
Error Explanation GeneratorArabelaTso/Skills-4-SE253—~3.8kAutomated safety check: PassApache-2.0

Similar skills

  • TDD Guide

    alirezarezvani/claude-skills

    Test-driven development skill for writing unit tests, generating test fixtures and mocks, analyzing coverage gaps, and guiding red-green-refactor workflows across Jest, Pytest, JUnit, Vitest, and…

    28k GitHub stars~3.4k tokensUpdated 1 mo ago
    Testing & QAAuto-check passed

  • TDD Guide

    LeoYeAI/openclaw-master-skills

    Test-driven development skill for writing unit tests, generating test fixtures and mocks, analyzing coverage gaps, and guiding red-green-refactor workflows across Jest, Pytest, JUnit, Vitest, and…

    2.2k GitHub stars~1.4k tokensUpdated 2 mo ago
    Testing & QAAuto-check passed

  • TDD Guide

    aAAaqwq/AGI-Super-Team

    Test-driven development workflow with test generation, coverage analysis, and multi-framework support

    105 GitHub starsUsed in 2 repos~1.1k tokens
    Testing & QAAuto-check passed

  • Testing Unit

    yonatangross/orchestkit

    Unit testing patterns for isolated business logic tests — AAA pattern, parametrized tests (test.each, @pytest.mark.parametrize), fixture scoping (function/module/session), mocking with MSW/VCR at…

    288 GitHub stars~2.4k tokensUpdated yesterday
    Testing & QAAuto-check passed

  • Error Explanation Generator

    ArabelaTso/Skills-4-SE

    Explains test failures and provides actionable debugging guidance.

    253 GitHub stars~3.8k tokensUpdated 1 mo ago
    Testing & QAAuto-check passed

  • Assertion Synthesizer

    ArabelaTso/Skills-4-SE

    Generate test assertions from existing code implementation. An agent skill from ArabelaTso/Skills-4-SE.

    253 GitHub stars~2.9k tokensUpdated 1 mo ago
    Testing & QAAuto-check passed

More from microsoft/testfx

All 44 skills in this repo

  • Directory Build Organization

    microsoft/testfx

    Official

    Guide for organizing MSBuild infrastructure with Directory.Build.props, Directory.Build.targets, Directory.Packages.props, and Directory.Build.rsp.

    1k GitHub starsUsed in 1 repo~2.5k tokens
    Auto-check passed

  • Binlog Failure Analysis

    microsoft/testfx

    Official

    Analyze MSBuild binary logs to diagnose build failures. An agent skill from microsoft/testfx.

    1k GitHub starsUsed in 3 repos~730 tokens
    Auto-check passed

  • Coverage Analysis

    microsoft/testfx

    Official

    Project-wide code coverage and CRAP (Change Risk Anti-Patterns) score analysis for .NET projects.

    1k GitHub stars~7.3k tokensUpdated today
    Auto-check passed

  • Incremental Build

    microsoft/testfx

    Official

    Guide for optimizing MSBuild incremental builds. An agent skill from microsoft/testfx.

    1k GitHub starsUsed in 3 repos~3.7k tokens
    Auto-check passed

  • Msbuild Modernization

    microsoft/testfx

    Official

    Guide for modernizing and migrating MSBuild project files to SDK-style format.

    1k GitHub starsUsed in 3 repos~4.3k tokens
    Auto-check passed

  • Msbuild Antipatterns

    microsoft/testfx

    Official

    Catalog of MSBuild anti-patterns with detection rules and fix recipes.

    1k GitHub stars~4.5k tokensUpdated today
    Auto-check passed

Works with

Categories

Questions about Test Anti Patterns

What does Test Anti Patterns do?

Audits existing test code in any language for anti-patterns and quality issues — produces a severity-ranked report (Critical / Warning / Info) with concrete code-level fixes. Test Anti Patterns is an agent skill from microsoft/testfx, published by the product's own GitHub organization. Audits existing test code in any language for anti-patterns and quality issues — produces a severity-ranked report (Critical / Warning / Info) with concrete code-level fixes.

When should I use Test Anti Patterns?

Test Anti Patterns fits situations like: : writing new tests (use code-testing-agent; writing-mstest-tests for MSTest); running tests (use run-tests); framework migration.

How do I install Test Anti Patterns in Claude Code?

Run `npx skills add microsoft/testfx --skill test-anti-patterns -a claude-code`. Or copy the skill folder (.agents/skills/test-anti-patterns in microsoft/testfx) into .claude/skills/test-anti-patterns in your project. Claude Code loads it when a task matches its description.

How do I install Test Anti Patterns in Codex?

Run `npx skills add microsoft/testfx --skill test-anti-patterns -a codex`. Or copy the skill folder (.agents/skills/test-anti-patterns in microsoft/testfx) into .agents/skills/test-anti-patterns in your project. Codex loads it when a task matches its description.

Can I use Test Anti Patterns in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add microsoft/testfx --skill test-anti-patterns -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/test-anti-patterns, .gemini/skills/test-anti-patterns, .github/skills/test-anti-patterns and .opencode/skills/test-anti-patterns in your project.

What does Test Anti Patterns need to run?

SKILL.md names no scripts, command-line tools or credentials: Test Anti Patterns is instructions for the agent only. Our summary lists: Python 3.

Does Test Anti Patterns access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Test Anti Patterns safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Test Anti Patterns use?

Test Anti Patterns is published under the MIT licence (declared in SKILL.md). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Test Anti Patterns use?

About 4.9k tokens (SKILL.md is roughly 20k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Test Anti Patterns?

Skills that share tags, products or a category with Test Anti Patterns: TDD Guide (alirezarezvani/claude-skills, 28k stars), TDD Guide (LeoYeAI/openclaw-master-skills, 2.2k stars), TDD Guide (aAAaqwq/AGI-Super-Team, 105 stars) and Testing Unit (yonatangross/orchestkit, 288 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Test Anti Patterns?

microsoft (a GitHub organization, an official publisher) maintains it in microsoft/testfx, which has 1,047 GitHub stars. The repository holds 44 skills in this directory. The repository was last updated on October 7, 2026.

Source: microsoft/testfx on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.