Problem / motivation
The project depends on generated client code and already contains workarounds for real API behaviour. That makes deeper compatibility testing especially valuable.
Proposed solution
Expand the testing strategy to cover contract drift, integration behaviour, and concurrency/resilience edge cases.
Scope:
- contract tests for generated client behaviour
- integration coverage against a real or fixture-backed Seerr instance
- race tests for concurrent enrichment paths
- fuzz coverage for parsers and URL normalisation
- stronger regression coverage for known search/encoding quirks
Alternatives considered
Rely only on command-level tests and fixture mocks. This is simpler, but it is less likely to catch generator or API compatibility drift.
Additional context
Related existing issue:
Suggested checklist:
Problem / motivation
The project depends on generated client code and already contains workarounds for real API behaviour. That makes deeper compatibility testing especially valuable.
Proposed solution
Expand the testing strategy to cover contract drift, integration behaviour, and concurrency/resilience edge cases.
Scope:
Alternatives considered
Rely only on command-level tests and fixture mocks. This is simpler, but it is less likely to catch generator or API compatibility drift.
Additional context
Related existing issue:
Suggested checklist: