skills.rest
Hakkadaikon
HakkadaikonCOMMUNITY
Explore all skills by this author →
𝕏@hakkadaikonGitHub

good-test-principles

Defines unit testing principles based on Khorikov's four pillars and verification styles.

Updated Jun 24, 2026
Search Tags:#vitest#tdd#unit testing#test quality#mocking#test design#refactoring resistance
One-click install
npx skills add https://github.com/Hakkadaikon/hymme --skill good-test-principles-hakkadaikon
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: good-test-principles
Source: https://github.com/Hakkadaikon/hymme/tree/main/skills/good-test-principles
Command: npx skills add https://github.com/Hakkadaikon/hymme --skill good-test-principles-hakkadaikon

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? It provides concrete criteria for judging whether unit tests are good or brittle, resolving confusion about mocking scope, what to verify, and how to balance test quality trade-offs. ## Core Features & Use Cases - Classical vs London School Guidance: Explains when to use real collaborators versus mocks, limiting mocks to out-of-process dependencies. - Four Pillars Evaluation: Measures tests against regression protection, refactoring resistance, fast feedback, and maintainability, treating refactoring resistance as non-negotiable. - Verification Style Prioritization: Ranks output-based, state-based, and communication-based verification, with TypeScript/vitest examples and inspection checklists for each. - Use Case: When reviewing a test suite full of mocks that break on every refactor, apply the inspection procedures to reclassify collaborators as in-process or out-of-process and rewrite tests against observable behavior. ## Quick Start Ask the AI to review your unit tests against the four pillars of good tests and identify which mocks should be replaced with real collaborators.

Frequently Asked Questions about good-test-principles

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

FAQPage Schema
How do I decide between classical and London school unit testing?▼

Use the classical school by default: test behavior units with real collaborators and reserve mocks for out-of-process dependencies like databases or external APIs. London-style mocking of in-process collaborators couples tests to implementation and breaks them on refactoring.

What are the four pillars of a good unit test?▼

The four pillars are protection against regressions, resistance to refactoring, fast feedback, and maintainability. The first three trade off against each other, so refactoring resistance is held fixed while balancing regression protection and speed.

When should I use mocks in unit tests?▼

Use mocks only for out-of-process dependencies not under your control, such as email senders or external APIs. Mocking in-process domain objects makes tests brittle because they become coupled to internal coordination steps rather than observable behavior.

What is the difference between output-based and state-based testing?▼

Output-based testing verifies only the return value of a pure function, while state-based testing checks the system's state after an operation. Output-based is preferred because it is the least brittle and offers the highest refactoring resistance.

Why do my tests break every time I refactor code?▼

Tests break on refactoring when they verify implementation details like private methods, internal state, or mock call sequences instead of observable behavior. Rewrite assertions against public return values and outcomes, and remove mocks of in-process collaborators.

Related Skills

Explore More Software Engineering Skills→
xiaolaixiaolai
10

lane-policy

Assigns test behaviors to unit, integration, e2e, or contract lanes with trigger and coverage rules.

Community
Intermediate
zenobi-uszenobi-us
68

test-driven-development

Enforce Test-Driven Development with failing tests before implementation.

Official
Intermediate
lucolucuslucolucus

seam-in-process

Implements in-process boundaries as code interfaces with consumer-driven contract tests.

Community
Intermediate
copyleftdevcopyleftdev

lipton-mutation-testing

Inject faults into source code and calculate mutation scores for test suites.

Community
Advanced