testing-philosophy

Guides behavior-based integration testing for TypeScript applications using the Two Users principle.

Updated Apr 28, 2026
One-click install
npx skills add https://github.com/GregM1991/skills --skill testing-philosophy-gregm1991
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: testing-philosophy
Source: https://github.com/GregM1991/skills/tree/main/skills/testing-philosophy
Command: npx skills add https://github.com/GregM1991/skills --skill testing-philosophy-gregm1991

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Teams waste effort writing brittle tests that assert implementation details, over-mock internal components, and chase coverage numbers instead of real confidence. This Skill provides a clear testing philosophy so every test verifies user-visible behavior. ## Core Features & Use Cases - Two Users Principle: Ensures tests only observe what end users see or what developer consumers receive, eliminating third-user test-only code. - Testing Trophy Guidance: Prioritizes static analysis and integration tests over excessive unit or E2E tests, targeting roughly 70% meaningful coverage. - Mocking Boundaries: Defines exactly when mocking is acceptable (external APIs, network via MSW, file system, time) and when it destroys confidence. - Use Case: When reviewing a React test suite, apply the included good-vs-bad examples to rewrite tests that assert CSS classes or internal hook state into workflow-based integration tests. ## Quick Start Review my TypeScript test file and rewrite any tests that check implementation details into behavior-based integration tests.

Frequently Asked Questions about testing-philosophy

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

FAQPage Schema
How do I write behavior-based tests in TypeScript?▼

Behavior-based tests assert only what users see or developers receive: rendered content, interactions, return values, and meaningful side effects. Drive tests through real mechanisms like userEvent and MSW rather than inspecting internal state, hooks, or CSS classes.

What is the Testing Trophy vs Testing Pyramid?▼

The Testing Trophy prioritizes static analysis first, then integration tests as the bulk, with some unit tests and few E2E tests. Unlike the pyramid's unit-heavy base, it favors integration tests because they provide the best confidence-to-cost ratio.

When should I mock in integration tests?▼

Mock only at external boundaries: third-party APIs, network requests via MSW, file system operations, and time-dependent code. Never mock components, hooks, or modules you control, since that removes the integration confidence the test exists to provide.

Should I aim for 100% code coverage?▼

No. Coverage beyond roughly 70% yields diminishing returns, and testing trivial code slows refactoring. Write tests for confidence in business logic and user workflows, letting TypeScript and ESLint catch entire bug categories statically.

Why do my tests break when I refactor implementation?▼

Tests break on refactoring when they assert implementation details like internal state, helper calls, or component structure. Rewrite them to assert user-observable outcomes so they survive any internal rewrite that preserves behavior.