art-of-unit-testing

Write trustworthy, maintainable, readable unit tests using Osherove's naming and stub-versus-mock conventions.

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

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Unit tests often fail the team by being untrustworthy, brittle, or unreadable — poorly named, over-mocked, full of logic, or coupled to private implementation. This Skill applies Roy Osherove's "The Art of Unit Testing" methodology so every test you write has a clear name, a single verified exit point, and correctly chosen test doubles. ## Core Features & Use Cases - Three-Part Naming Convention: Enforces the UnitOfWork_StateUnderTest_ExpectedBehavior naming standard so a failing test name alone tells you what broke, under what condition, and what was expected. - Stub vs Mock Discipline: Distinguishes doubles by whether the test asserts against them, enforces the one-mock-per-test rule, and maps the three exit points (return value, state change, third-party call) to assertion strategy. - Testability and Legacy Code: Guides seam design via constructor/property/factory injection and Extract-and-Override, plus a strategy for getting untested legacy code under test. - Use Case: When asked to "write a unit test for this withdrawal method" or "review this test suite for over-mocking", the Skill produces properly named AAA-structured tests with exactly one mock and stubs for incoming dependencies. ## Quick Start Ask Claude to write or review a unit test for a specific method, and it will apply the three-part naming convention, Arrange-Act-Assert structure, and the stub-versus-mock rules automatically.

Frequently Asked Questions about art-of-unit-testing

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

FAQPage Schema
How do I name unit tests so failures are self-explanatory?▼

Use Osherove's three-part convention: UnitOfWork_StateUnderTest_ExpectedBehavior, separated by underscores. The name reads as a micro-specification, so when it fails you know what broke, under what condition, and what was expected without opening the test.

What is the difference between a stub and a mock?▼

A stub is a fake the test does not assert against; it feeds indirect input to the unit under test. A mock is a fake the test does assert against, verifying an outgoing call to a third party. Use at most one mock per test; all other fakes are stubs.

How many mocks should a unit test have?▼

At most one mock per test. A test verifies a single end result, and only the third exit point — a call to an external dependency — requires a mock. Asserting against multiple mocks means the test covers multiple units of work and becomes over-specified and fragile.

How do I test legacy code with no seams or dependency injection?▼

Use Extract-and-Override: pull the awkward dependency call into a virtual method and override it in a test-only subclass. This creates a seam with minimal risk. Characterize current behavior with tests first, then break dependencies just enough to get the unit under test.

Should unit tests contain if statements or loops?▼

No. Logic in tests (if, for, switch, try/catch) means the test exercises multiple cases or can itself be buggy, undermining trust. Split branching cases into separate tests or use parameterized tests, and use assertion libraries instead of hand-rolled try/catch for exceptions.

When should I use a mocking framework versus hand-rolled fakes?▼

Use a mocking framework for the single outgoing interaction you verify, and hand-rolled or simple fakes for incoming dependencies reused across tests. Prefer constrained frameworks that force real seams, since unconstrained ones that fake statics hide design feedback.