xunit-test-patterns

Applies Meszaros's xUnit test patterns to write, diagnose, and refactor automated test code.

1|Updated May 21, 2026
One-click install
npx skills add https://github.com/vnovakovits/claude-skills --skill xunit-test-patterns-vnovakovits
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: xunit-test-patterns
Source: https://github.com/vnovakovits/claude-skills/tree/main/plugins/engineering-practices/skills/xunit-test-patterns
Command: npx skills add https://github.com/vnovakovits/claude-skills --skill xunit-test-patterns-vnovakovits

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Test suites often become brittle, slow, flaky, or unreadable over time, turning a safety net into a maintenance burden. This Skill provides the canonical catalogue of test-automation patterns and smells from Gerard Meszaros's "xUnit Test Patterns" so tests stay maintainable, trustworthy, and clearly communicative. ## Core Features & Use Cases - Test Double Taxonomy: Choose and name the right double — Dummy, Stub, Spy, Mock, or Fake — based on the role it plays in the test, including the stub-vs-mock distinction. - Fixture & Verification Patterns: Structure the four-phase test, design fresh vs shared fixtures, and apply Object Mother, Test Data Builder, Custom Assertions, and Expected Object comparisons. - Smell Diagnosis: Identify and fix code smells (Mystery Guest, Eager Test, Conditional Test Logic), behaviour smells (Erratic Test, Fragile Test, Assertion Roulette, Slow Tests), and project-level smells. - Use Case: When a test suite starts failing intermittently in CI, use this Skill to trace the flakiness to a shared mutable fixture or uncontrolled clock, then refactor to Fresh Fixtures and isolated test data. ## Quick Start Ask Claude to review your test file for xUnit test smells and suggest the right test doubles and fixture strategy for each test.

Frequently Asked Questions about xunit-test-patterns

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

FAQPage Schema
What is the difference between a mock and a stub in unit testing?▼

A stub feeds the system under test indirect inputs by returning canned values, while a mock verifies indirect outputs by checking that the SUT sent the expected calls. Stubs answer queries; mocks confirm commands, and over-using mocks causes fragile tests.

How do I fix flaky or erratic tests in my test suite?▼

Flaky tests usually come from shared mutable fixtures, inter-test dependencies, or uncontrolled time and randomness. Switch to fresh fixtures per test, isolate each run with a database sandbox or rollback teardown, and control the clock and random number generation.

When should I use a fake object instead of a mock?▼

Use a fake when the real dependency is slow or awkward, such as replacing a database with an in-memory implementation, and you assert on its resulting state. Fakes suit collaborators reused across many tests; configurable mocks fit one-off interaction checks.

How do I choose between fresh and shared test fixtures?▼

Prefer fresh fixtures built per test because they maximize independence and repeatability. Share fixtures only when they are immutable and never let one test's writes be visible to another, since shared mutable state causes interacting tests and test run wars.

What are the most common xUnit test smells to look for?▼

Common smells include Mystery Guest (hidden external data), Eager Test (verifying many behaviours at once), Assertion Roulette (unidentifiable failing asserts), Conditional Test Logic, and Fragile Tests from over-mocking internals. Each has a documented fix such as creation methods or expected-object assertions.