unit-test-design

Designs behavior-focused unit tests with Arrange-Act-Assert structure and red-check verification.

1|Updated Jul 3, 2026
One-click install
npx skills add https://github.com/Nandansai08/skillz --skill unit-test-design-nandansai08
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: unit-test-design
Source: https://github.com/Nandansai08/skillz/tree/main/skills/testing-qa/unit-test-design
Command: npx skills add https://github.com/Nandansai08/skillz --skill unit-test-design-nandansai08

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Writing unit tests often produces suites that break on every refactor, pass on real bugs, or assert nothing meaningful. This Skill provides a disciplined workflow for deciding what to test, structuring tests, and verifying they actually catch failures. ## Core Features & Use Cases - Behavior-first test planning: Enumerate observable behaviors rather than methods, producing one test per behavior with names that read as bug reports. - Structured test authoring: Enforces Arrange-Act-Assert layout, outcome-based assertions, builder/factory patterns, and boundary-case parameterization. - Red-check verification: Requires each test to be seen failing with a readable message, and flags anti-patterns like sleeps, real time, and shared mutable fixtures. - Use Case: When writing tests for a billing function like split_bill, the Skill guides you to derive a behavior list (even split, remainder distribution, zero-people error, rounding), producing six targeted tests that caught a real cent-rounding bug. ## Quick Start Ask the AI to write unit tests for your function using behavior-based design with Arrange-Act-Assert structure and red-check verification.

Frequently Asked Questions about unit-test-design

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

FAQPage Schema
How do I decide what to write unit tests for?▼

List observable behaviors of the unit under test, not its methods. Write one test per behavior, such as rejecting expired input or rounding correctly, and skip trivial getters, framework behavior, and private helpers tested through the public surface.

How should I structure and name unit tests?▼

Structure every test as Arrange-Act-Assert with visual separation and one act per test. Name tests as behavior statements like test_expired_coupon_is_rejected so failures read as bug reports without opening the file.

Should unit tests assert on mock calls or return values?▼

Assert on outcomes such as return values, state changes, and emitted events rather than internal call sequences. Interaction assertions are only justified when the call itself is the contract, like sending exactly one email.

Why are my unit tests flaky and order-dependent?▼

Flakiness usually comes from real time, sleeps, or shared mutable fixtures across tests. Inject the clock with tools like freezegun or fake timers, share builders instead of instances, and grep for sleep and now() calls.

When should I not write a unit test?▼

Skip trivial pass-throughs, framework behavior like ORM saves, private helpers, and generated code. For choosing test doubles use a dedicated doubles skill, and for integration-level scope decisions use an integration test strategy skill.