Test Data Edge Cases Review — Claude Code Guide

Test data must prove the risk

A test suite is built as a chain: risk → scenario → data → result assertion → quality review → evidence in the PR. The number of tests does not equal quality if they do not distinguish a correct implementation from a defective one.

Category	Examples	What to check
Invalid input	Zero amount, negative value, missing description	Validation and no stray operations
Boundaries	Full amount, last allowed day	No off-by-one error
Access	User without the required role	Access error and no changes
Repetition	Two identical requests	Idempotency and no duplicate
External service	Payment provider timeout	Understandable error and consistent state
Time	UTC, crossing midnight	Stable deadline calculation

Boundary analysis checks neighboring values

For a refund policy, this may be the previous day, the last permitted day, and the first forbidden day; for an amount, it may be the minimum, zero, a negative value, and a value above the remaining balance.

Find the lowest permitted boundary.
Check the value exactly at the boundary.
Check the first value beyond the boundary.
Compare expected behavior and side effects.
Add time zones or calendar boundaries only when relevant to the change.

A negative test checks for absence of side effects

An invalid request returns the agreed status and error body.
A refund record is not created.
The order status does not change.
The payment service is not called.
Funds are not charged or partially refunded.
No inconsistent state remains after the error.

Fixtures must be synthetic

Representative data should be understandable, stable, and close enough to the scenario, but completely safe. Use a sample order ID, the example.com domain, a test currency, and an obvious amount.

Do not copy production IDs, real addresses, tokens, keys, payment data, or log fragments into tests. Realism does not justify leaking private information.

Safe direction for a fixture

orderId: test-order-001
customerEmail: reviewer@example.com
currency: TST
amount: 42.00

Test review asks the same question as code review

Does the scenario test external behavior rather than a private method?
Are the assertions meaningful?
Is the object under test itself not mocked?
Is there no dependency on time, network, randomness, or execution order?
Is the scenario name clear?
Was the regression test red before the fix and green after?
Does the data contain no confidential information?