dotnet-flaky-test-diagnosis

Diagnose .NET tests that fail in the full suite but pass in isolation.

2|Updated Jul 18, 2026
One-click install
npx skills add https://github.com/Arasz/ai-badger --skill dotnet-flaky-test-diagnosis-arasz
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: dotnet-flaky-test-diagnosis
Source: https://github.com/Arasz/ai-badger/tree/main/features/dotnet/skills/dotnet-workload/references/dotnet-flaky-test-diagnosis
Command: npx skills add https://github.com/Arasz/ai-badger --skill dotnet-flaky-test-diagnosis-arasz

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? A .NET test that fails in the full suite but passes alone is usually a parallelism flake, not a regression — but without a systematic process, developers waste time blaming their branch or chasing the wrong root cause. This Skill provides a classification ladder that separates real bugs from intra-test races, inter-test contention, and environmental flakes before any fix is attempted. ## Core Features & Use Cases - Classification ladder: Reproduce in the full suite, re-run in isolation, then run a clean-main baseline in a throwaway git worktree to determine whether the flake pre-exists your branch. - Root-cause classes with fixes: Class A intra-test races (lock-guard fake collections instead of serializing production concurrency), Class B inter-test contention (xunit v3 DisableParallelization collections for wall-clock I/O tests), and Class C environmental flakes (hermetic child PATH/env, cold-worktree asset provisioning). - Gate discipline: Rules for per-PR gates with known-flake tolerance, one-PR-per-flake-fix scope, and handling concurrent-session half-fixes that break origin/main. - Use Case: A watch-integration test fails once in three full-suite runs but passes every isolated re-run; the ladder identifies it as Class B inter-test contention, and the fix serializes the test class with a documented xunit collection definition. ## Quick Start Diagnose why my .NET test passes alone but fails in the full test suite and tell me how to fix it.

Frequently Asked Questions about dotnet-flaky-test-diagnosis

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

FAQPage Schema
How do I fix a .NET test that fails in the full suite but passes alone?

A test failing only in the full suite is a parallelism flake. Re-run it isolated to confirm, check a clean-main baseline, then classify the cause: lock-guard shared fake collections for intra-test races, or serialize the test class with an xunit collection for inter-test contention.

How to disable parallelization for a test class in xunit v3?

Define a collection with [CollectionDefinition(Name, DisableParallelization = true)] and apply [Collection(Name)] to the test class. Note the attribute is DisableParallelization, not DisableParallelism, which is the per-test variant.

Why does my test fail on a fresh git worktree but pass on re-run?

Cold-worktree asset provisioning causes this: gitignored native assets are copied into bin on the first run, and a transient copy failure fails asset-using tests. The second run passes because assets persist, so the warm re-run is itself the evidence.

How do I know if a flaky test is caused by my branch?

Run the failing test on pristine origin/main in a throwaway worktree created with git worktree add at the base commit. If it fails there too, the flake pre-exists your branch and is not your regression.

Should I fix flaky tests in the same PR as my feature?

No. A flake fix is a separate unit of work with its own evidence and should ship as its own PR. Per-PR gates can tolerate recorded known flakes after an isolated re-run, but any other failure counts as red.