Test Strategy First: Writing the Plan Before the Code

Here is a question that separates operators from hobbyists: when do you write your test strategy?

If the answer is "after the code is done," you are not writing a test strategy. You are writing documentation for code that already exists. That is fundamentally different — and fundamentally weaker.

The Build Order

Every feature, every project, every significant change follows this sequence:

1. PRD (Product Requirements Document)
2. UX Audit (how it should look and behave)
3. Test Strategy (how we verify it works)
4. Build (write the code)
5. Playwright (visual and E2E validation)

This is not optional. This is not "nice to have for big projects." This is the order. Every time.

The reason is simple: each step informs the next. The PRD tells you what to build. The UX audit tells you how it should look. The test strategy tells you what "working" means. The build satisfies the strategy. Playwright confirms it visually.

Skip any step and you pay for it later. Always.

The InDecision Command Lesson

Let me tell you what happens when you skip the test strategy.

InDecision Command — a decision intelligence dashboard — shipped its initial version without tests. The team was moving fast, the features were landing, the UI looked good in development. Ship it.

Then the bugs started. Not dramatic, system-down bugs. Subtle ones. A filter that silently dropped results. A date parser that worked in US locale but broke in EU format. A pagination component that reset to page 1 whenever the parent re-rendered.

Each bug was small. Together, they eroded trust in the product.

The retrofit cost: 148 pages of test coverage written after the fact, reverse-engineering the intended behavior from the actual behavior (which was sometimes wrong). Three weeks of work that would have been three days if the test strategy had existed from the start.

That experience created a hard rule: test strategy before code, no exceptions.

What the Test Strategy Document Contains

A test strategy is not a list of unit tests. It is a map of every way the feature can fail and the verification plan for each one.

1. Critical Paths

The user journeys that must work or the feature is broken. Not every path — the critical ones.

## Critical Paths
- User loads dashboard → data populates within 2s → all 5 sections render
- User applies filter → results update → filter state persists on refresh
- User clicks export → file downloads → file contains filtered data (not all data)

2. Data Edge Cases

The inputs that break assumptions. Empty states. Null values. Lists with one item vs. 10,000 items. Unicode. Dates across timezone boundaries.

## Data Edge Cases
- Empty dataset: dashboard shows empty state, not a crash
- Single item: pagination does not render
- 10,000 items: pagination works, no performance degradation > 3s
- Null values in API response: graceful fallback, not undefined errors

3. Integration Boundaries

Every point where your code talks to something external. APIs, databases, file systems, third-party services. These are where mocks lie and real behavior diverges.

## Integration Boundaries
- Polymarket CLOB API: pagination at 500+ results (urljoin bug surface)
- Discord webhook: rate limiting at 30 msg/min
- File system: state file lock acquisition under concurrent access

4. Visual Breakpoints

The viewport widths where layout must be verified. Not "it is responsive." Specifically which layouts change at which breakpoints.

## Visual Breakpoints
- 1280px (desktop): 3-column grid, sidebar visible
- 768px (tablet): 2-column grid, sidebar collapsed
- 375px (mobile): single column, hamburger nav

5. State Transitions

How data flows through the system and what the state looks like at each stage. This catches the bugs that unit tests miss — the ones where the output is correct but the internal state is corrupted.

## State Transitions
- Initial load: state file created with default schema
- After first trade: positions array populated, balance updated
- After position close: position moved to history, P&L calculated
- Crash recovery: state file loaded, incomplete transactions rolled back

6. Failure Signatures

What does "broken" look like? This is the most underrated section. If you know what failure looks like, you can build detection for it.

## Failure Signatures
- Stale data: timestamp > 5 min old on dashboard
- Silent API failure: empty array returned instead of error
- State corruption: balance < 0 or positions count != trade log count

Scaling Strategy to Scope

Not every feature needs a 3-page test strategy. The depth scales with the blast radius.

The scaling heuristic: if you would be embarrassed to explain the bug to your team, the feature needed a written strategy.

The Strategy-to-Test Pipeline

Once the strategy exists, converting it to actual tests is mechanical:

1. Each critical path becomes an E2E test (Playwright or integration)
2. Each data edge case becomes a unit test with that specific input
3. Each integration boundary gets both a mocked unit test AND a live integration test
4. Each visual breakpoint becomes a Playwright screenshot assertion
5. Each state transition becomes a state verification test
6. Each failure signature becomes a monitoring check or alerting rule

The strategy makes the test suite intentional. You are not writing tests to hit a coverage number. You are writing tests to verify specific failure modes you have already identified.

The test strategy document will evolve as you build. That is fine. The value is in the planning — forcing yourself to think about failure before you start building.

Lesson 139 Drill

1. Pick a feature you are about to build (or recently built without a strategy). Write a test strategy document with all six sections: critical paths, data edge cases, integration boundaries, visual breakpoints, state transitions, and failure signatures.
2. Take one existing test file in your project. For each test, identify which section of the test strategy it would fall under. If a test does not map to any section, ask whether it is actually testing anything meaningful.
3. Estimate the time you spent debugging your last three bugs. Now estimate how much of that time would have been saved if the failure mode was identified in a test strategy before the code was written. Track the ratio.

The test strategy is not bureaucracy. It is the fastest path to shipping with confidence — because it forces you to understand the problem before you start solving it.