pairwise-test-coverage
Pairwise Test Coverage
Combinatorial testing that covers all factor pairs in near-minimal test cases.
When to use: Multi-factor systems where exhaustive testing is impractical, state machines, retry/recovery logic, configuration matrices, compatibility testing, any code with 3+ interacting parameters.
When not to use: Single-factor tests (just test each value), two-factor systems (test all combinations directly), UI snapshot tests, type-only changes.
Pairwise vs Model-Based
Pairwise selects which input combinations to test. Model-based testing derives which state transitions to test. Different questions, different tools:
| Your system has... | Use | Example |
|---|---|---|
| Independent parameters with discrete values | Pairwise | OS × browser × locale config matrix |
| Named states with transitions between them | Model-based | draft → review → published workflow |
| State machine guards with 5+ boolean inputs | Both | Model-based finds the guards, pairwise covers the flag combos |
Rule of thumb: if you're testing what goes in, use pairwise. If you're testing what happens next, use model-based.
More from apankov1/quality-engineering
breaking-change-detector
Audit 6 categories of breaking changes with executable checks for contracts, API diffs, serialized state, and event types.
17websocket-client-resilience
Client-side WebSocket resilience patterns: backoff with jitter, circuit breakers, heartbeat hysteresis, command acknowledgment, sequence gap detection, and mobile-aware timeouts.
17barrier-concurrency-testing
Deterministic race condition testing using barriers and deferred promises. Replaces flaky setTimeout-based timing tests with reproducible interleaving control.
17fault-injection-testing
Use when testing what happens when things fail — storage errors, network timeouts, API 500s, service outages. Provides circuit breaker state machine, retry policies with exponential backoff, fault injection, and queue preservation assertions. Trigger on: 'circuit breaker test', 'retry logic', 'exponential backoff', 'what happens if the API fails', 'simulate network failure', 'fault injection', 'resilience test', 'queue preservation after crash', 'graceful degradation'. Skip for: happy-path unit tests, UI testing, or code review.
15zod-contract-testing
Validates Zod schema parsing at boundaries. Tests valid/invalid inputs, schema evolution, refinement coverage, and compound state matrices (2^N optional field combinations).
13model-based-testing
Tests state machine transitions with XState-style patterns. Validates transition matrices, guard truth tables, context mutations, and terminal state handling.
13