Laboratory Service — Testing Strategy
Status: populated Owner: TBD Last updated: 2026-04-18 Companion: Service Template · 03 platform-services · 02 DDD
1. Coverage Targets
| Layer | Target |
|---|---|
| Unit | ≥ 80% statement coverage |
| Integration | All use cases have at least one integration test |
| Contract | All REST endpoints have Pact tests; all events have schema tests |
| E2E | Critical paths: accession → verify → release; critical value escalation |
2. Mandatory Tests
| Test file | What it covers |
|---|---|
test/integration/tenant-isolation.spec.ts | Requests from one tenant cannot read/write another tenant's data |
test/integration/outbox.spec.ts | Domain commands produce events in outbox; relay publishes them |
test/integration/inbox.spec.ts | clinical.orders.placed event processed idempotently |
3. Unit Test Scenarios
| Module | Key scenarios |
|---|---|
AccessionStateMachine | All valid and invalid transitions; cancellation rules |
LabResultStateMachine | Draft → verified → released; correction chain |
CriticalValuePolicyEngine | Values above/below threshold trigger critical flag; no false positives |
AccessionNumberGenerator | Uniqueness per tenant per day; format validation |
ResultValueValidator | Numeric/text/boolean mutually exclusive constraints |
AbnormalFlagCalculator | Flag derivation from reference range vs value |
4. Integration Test Scenarios
| Scenario | Description |
|---|---|
| Order event → accession creation | Publish clinical.orders.placed; assert accession created and diag.laboratory.accession.created published |
| Full LIS lifecycle | Create accession → collect → receive → enter result → verify → release; assert FHIR resources created |
| Critical value flow | Enter result above critical threshold; assert diag.laboratory.critical.triggered published |
| Correction chain | Release result → correct → assert new version, prior version marked superseded |
| Duplicate inbox event | Replay clinical.orders.placed with same event ID; assert idempotent (no duplicate accession) |
| FHIR publish failure | Simulate FHIR gateway unavailable; assert release queued in outbox; assert retry on reconnect |
5. Contract Tests
| Contract | Type | Consumer |
|---|---|---|
GET /v1/laboratory/accessions | Pact provider | Any consuming UI |
POST /v1/laboratory/results/{id}/verify | Pact provider | Lab UI |
diag.laboratory.result.released schema | JSON schema | patient-chart-service, patient-portal-service |
diag.laboratory.critical.triggered schema | JSON schema | communication-service |
GET /fhir/R4/Observation | FHIR conformance | interop-service, patient-chart-service |
6. E2E Test Scenarios (Playwright)
| Scenario | Priority |
|---|---|
| Clinician views released lab results in chart | P0 |
| Lab tech creates accession and enters results from order | P0 |
| Pathologist releases results and chart updates | P0 |
| Critical value triggers visible alert in clinician inbox | P1 |
| Clinician acknowledges critical result and escalation stops | P1 |
| Lab admin creates test catalog item with LOINC validation | P2 |
7. Performance Tests
| Test | Target |
|---|---|
| Worklist retrieval (1000 accessions) | < 2 s p95 |
| Result ingestion burst (50 results/s) | No errors; outbox lag < 30 s |
| Trending query (12 months, 1 analyte) | < 2 s p95 |