void-testing

Guides writing behavior-focused tests with real code, factories, and minimal mocking.

Updated May 29, 2026
One-click install
npx skills add https://github.com/voidcorp-core/void-harness --skill void-testing-voidcorp-core
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: void-testing
Source: https://github.com/voidcorp-core/void-harness/tree/main/packages/core/skills/void-testing
Command: npx skills add https://github.com/voidcorp-core/void-harness --skill void-testing-voidcorp-core

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Tests often assert implementation details, over-mock collaborators, leak shared state through beforeEach blocks, and accumulate snapshot creep, making suites brittle and untrustworthy. This Skill defines the technique for writing good tests: behavior over implementation, real code over mocks, factories over shared fixtures, and pristine output as a passing condition. ## Core Features & Use Cases - Behavior-first assertions: Assert observable outcomes with accessible queries and imperative test names instead of spying on internals. - Sociable tests with boundary mocking: Run real collaborators by default and mock only at infrastructure boundaries using MSW, pglite, memfs, fake timers, or seeded RNG. - Fixture and pyramid discipline: Use factory functions with overrides, externalize large fixtures, and follow a 70/20/10 unit/integration/E2E heuristic. - Banned practices enforcement: Blocks .only/.skip, default snapshot testing, business-layer mocks, and weak test names via companion hooks. - Use Case: When asked to add tests for a payment retry function, write a test named 'retries failed operations 3 times before giving up' that runs the real retry logic and asserts the observable attempt count rather than spying on internal calls. ## Quick Start Ask the agent to write a test for a specific function or component and it will apply behavior-first assertions, factories, and boundary-only mocking.

Frequently Asked Questions about void-testing

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

FAQPage Schema
How do I write tests that don't break on refactoring?

Assert observable behavior at the boundary instead of implementation details like private methods or internal call sequences. For UI, query by accessible role or label rather than class or data-testid, so refactors that preserve behavior keep tests green.

When should I use mocks in unit tests?

Mock only at infrastructure boundaries: HTTP via MSW, databases via pglite, filesystem via memfs, time via fake timers, and randomness via seeded RNG. Mocking pure functions or business services is a coupling smell; run the real code instead.

Should I use beforeEach or factory functions for test data?

Use factory functions with overrides for test data and reserve beforeEach for environment setup like mounting the DOM or resetting the database. Shared mutable state in beforeEach leaks between tests and hides each test's actual preconditions.

Is snapshot testing a good practice?

Snapshot testing is banned by default because snapshots devolve into update-on-green, passing regardless of correctness. It is allowed only for visual regression in __visual__ directories or compiler output in __generated__ with documented review.

What is the ideal ratio of unit to integration to E2E tests?

A common heuristic is roughly 70% unit, 20% integration, and 10% E2E tests, but it is a guide rather than a quota. An inverted pyramid where E2E tests carry the proof usually signals design coupling that makes unit tests expensive.

Why does my test suite have console warnings and leaked timers?

Pristine output is a passing condition: no console.log from production code, no React act warnings, no unhandled rejections, and no leaked timers or handles. Configure Vitest with onConsoleLog set to fail so noisy output fails the test.