Testing Strategies

Start with the affected behaviour

Use the shortest feedback loop that exercises the affected behaviour.

This practice governs verification selection, order and scope throughout the kit. Follow repository-mandated gates at their defined stages.

Start the normal application or native entry point when applicable. Observe diagnostics and exercise the changed behaviour.
Use focused tests for added evidence. Keep the relevant tests in watch mode while iterating, using the project's installed tooling.
Expand verification according to impact: affected consumers, shared logic, integration boundaries, and critical user journeys.
Run comprehensive suites for integration, release, CI, or explicit requirements rather than after every local edit.

For an actual bug, reproduce it first, then retain a focused regression when it provides useful ongoing protection. For poorly understood existing behaviour, characterize the relevant outcome before changing internals.

See fast feedback examples for the development loop and observable contract examples for choosing assertions.

Choose the evidence you need

Protect observable state and consumer contracts. Real local collaborators are useful when they keep the test simple and meaningful. Assert interactions when the request, event, count, or ordering is itself contractual.

Affected behaviour	Focused evidence	Read next
`calculateTotal(items)` or a domain rule	Inputs → returned result; boundary cases that matter	Unit patterns
`POST /api/users` or a database query	Request/response, persisted state, or transaction across the relevant boundary	Integration patterns
Registration form → API → redirect	Targeted journey through the application	E2E patterns
Service A → B communication	Consumer expectations plus provider verification	Service contracts
Generated configuration or installed package	What the consumer can load, import, execute, or observe	Observable contracts
Parser, serializer, or many input variations	Known fixtures and useful invariants	Test data

Use the decision tree to select a boundary. Use the testing pyramid to review suite design, not to impose test-count quotas on a change.

Keep boundaries meaningful

Exercise the real behaviour under test. Preserve the relevant real integration boundary or use a faithful double backed by contract evidence.
Use fixtures or local HTTP interception for routine vendor API tests; run external contract and sandbox checks selectively.
Control time, randomness, and test data where reproducibility matters. Dispose of temporary files, database contexts, and handlers after use.
Prefer returned domain results, visible state changes, persisted records, and contractual events over private helper-call sequences.

See mocking strategies for boundary selection and test data strategies for fixtures, factories, seeds, and counterexamples.

Analyse coverage deliberately

Coverage shows what executed, not whether useful behaviour was verified. Request coverage analysis when it helps identify missing affected branches or assess suite quality. Use mutation testing selectively for important logic. Honour existing project and CI thresholds without introducing a new per-task percentage target.

See coverage strategies. CI and release verification can combine broader integration, service contracts, critical journeys, and existing coverage checks according to project requirements. Keep that separate from the focused edit/watch loop.

Use the project's tooling

Follow installed runner versions and project scripts. Use Vitest guidance for Vitest-specific execution and watch workflows, and test generation when deriving focused cases from requirements or existing behaviour.

The supplied examples demonstrate patterns; adapt them to the application's actual entry points and contracts:

TypeScript unit examples: focused assertions and unit-test patterns.
TypeScript API-client examples: fetch through MSW interception, request payloads, and errors; not a real-database endpoint test.
Supplementary Python unit examples.
Supplementary Python property examples.

TypeScript test conventions

Use the bundled TypeScript test conventions for AAA, isolation, descriptions, query priority, and snapshot restraint. Consuming repository conventions take precedence.