test-isolation
Test Isolation
Overview
Each test must be independent. No shared state. No dependencies between tests.
Tests that depend on each other are brittle, hard to debug, and can't run in parallel. Every test should set up its own state and clean up after itself.
When to Use
- Writing any test that uses shared data
- Tests that must run in a specific order
- Tests that fail randomly or when run alone
- Test suites that can't run in parallel
The Iron Rule
NEVER let one test depend on another test's state or execution.
More from yanko-belov/code-craft
dont-repeat-yourself
Use when writing similar code in multiple places. Use when copy-pasting code. Use when making the same change in multiple locations.
84lazy-loading
Use when loading all data upfront. Use when initial page load is slow. Use when fetching data that might not be needed.
54keep-it-simple
Use when tempted to write clever code. Use when solution feels complex. Use when showing off skills instead of solving problems.
51separation-of-concerns
Use when component does too many things. Use when mixing data fetching, logic, and presentation. Use when code is hard to test.
44single-responsibility-principle
Use when creating or modifying classes, modules, or functions. Use when feeling pressure to add functionality to existing code. Use when class has multiple reasons to change.
39fail-fast
Use when handling errors. Use when tempted to catch and swallow exceptions. Use when returning default values to hide failures.
35