process-test-design

Guides writing deterministic, behavior-focused tests with real dependencies and adversarial input coverage.

1|Updated Jun 23, 2026
One-click install
npx skills add https://github.com/bitranox/bitranox-skills --skill process-test-design-bitranox
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: process-test-design
Source: https://github.com/bitranox/bitranox-skills/tree/main/plugins/bitranox/skills/process-test-design
Command: npx skills add https://github.com/bitranox/bitranox-skills --skill process-test-design-bitranox

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Test suites often accumulate mocks that hide broken contracts, flaky order-dependent tests, and low-value filler that adds maintenance without catching bugs. This Skill provides language-neutral rules for designing tests that can actually fail for real reasons: preferring real dependencies over mocks, covering adversarial boundary inputs, and keeping suites deterministic and offline by default. ## Core Features & Use Cases - Mock vs. real dependency decisions: Inject collaborators through ports and interfaces instead of monkeypatching, with per-language mechanics for Python, TypeScript/JS, Go, Rust, and Bash. - Adversarial input coverage: A boundary test battery covering Unicode, emoji, CJK, binary, wrong types, oversized payloads, and numeric edges, with a stopping rule of one test per branch the code distinguishes. - Determinism and flake diagnosis: Rules for order-independence, injected clocks and randomness, plus measured techniques for reproducing flakes via CPU starvation or slowing the raced clock. - Use Case: When reviewing a pytest or vitest suite that is green but ships broken contracts, apply this Skill to replace self-mocks with injected fakes, mark integration tiers correctly, and prune assertion-free tests. ## Quick Start Ask the AI to review your test suite using the process-test-design skill to identify mock anti-patterns, missing edge-case coverage, and flaky order-dependent tests.

Frequently Asked Questions about process-test-design

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

FAQPage Schema
How do I decide between mocking and using real dependencies in tests?▼

Default to integration or e2e tests against the real dependency, and inject collaborators through a port or interface so tests can substitute a fake behind the same contract. Reserve monkeypatching for true external edges you cannot inject, like third-party globals, the clock, or the network.

What edge cases should I test at API boundaries?▼

Cover text inputs (empty, whitespace, emoji, CJK, RTL, zero-width), bytes (control chars, NUL, invalid UTF-8), wrong types, missing or extra fields, numeric edges (0, -1, max, overflow, NaN), size limits, and malformed structure. Write one test per branch the code actually distinguishes, asserting the specific error or normalization behavior.

Why are my tests flaky and order-dependent?▼

Flakiness comes from shared mutable state between tests, real sleep calls for timing, and uninjected clocks or randomness. Each test must set up its own fixtures, poll conditions with timeouts instead of sleeping, and pass both alone and under shuffled ordering.

How do I reproduce a flaky test that only fails in CI?▼

Match the reproduction pressure to the mechanism: races between tasks reproduce under CPU starvation with busy competitors pinned to one core, while races against a timer require slowing the clock the test races, such as a UI framework tick or poll interval. Always reproduce through the real test entry point.

When should I delete a test instead of fixing it?▼

Delete tests that assert nothing, restate the implementation line-by-line, test the language or framework rather than your behavior, or duplicate another test's coverage. Fewer behavior-focused tests beat many brittle ones; coverage percentage is a smell detector, not a goal.

Does this test design guidance work for languages other than Python?▼

Yes, all principles are language-neutral with a per-language mechanics table covering Python, TypeScript/JS, Go, Rust, and Bash. The table maps each ecosystem's injection seam, self-mock anti-pattern, real dependency option, and test shuffle flag.