# Testing strategy

Product design

This page describes the product model and requirements. Examples illustrate the model, not a guaranteed API or completed feature. Check the [application contracts](/stormtrust/apps/) and [dataset inventory](/stormtrust/product/platform-and-data/datasets-and-source-contracts/) for implemented scope. Use [operations guides](/stormtrust/engineering/operations/) for runnable procedures.

StormTrust testing proves software correctness and domain correctness. An HTTP `200` response does not prove a hail algorithm is accurate.

For current commands, use [Validate a change](/stormtrust/engineering/operations/validate/). For a proposed feature, use [Review a product change](/stormtrust/product/build-and-operate/review-change/) to turn these requirements into acceptance evidence.

## Unit tests

Unit tests cover pure scoring, normalization, geometry helpers, classification, permissions, and transformations.

## Weather fixtures

Frozen fixtures should represent no hail, marginal hail, severe hail, missing frames, degraded radar quality, multiple cells, splits, merges, late reports, and contradictory reports.

## Historical replay

[Storm History](/stormtrust/product/platform-and-data/intelligence/storm-history/) and [Storm Replay](/stormtrust/product/platform-and-data/intelligence/storm-replay/) are user-facing capabilities, and testing exercises their shared evidence and read contracts. The [History and Replay contract](/stormtrust/product/platform-and-data/intelligence/history-replay-contract/#shared-testing-contract) owns pinned inputs, controlled clocks, time modes, and isolated delivery.

Reproduce an original result with its frozen evidence and rule version. Compare a new algorithm in a separate retrospective run; do not overwrite a customer's report or call later-arriving evidence available earlier. Test missing frames, corrections, retention expiry, reconnect, access, and live-update buffering. Only compare property exposure or outcomes when their required data exists.

## Ingestion tests

Ingestion tests cover duplicate assets, out-of-order objects, malformed inputs, missing sources, retries, late sources, and network failures.

## Property tests

Property tests cover boundary intersections, edge touching, multipolygons, missing geometry, duplicates, overrides, and provider changes.

## Tenant isolation tests

Every sensitive resource has a test proving one tenant cannot access another tenant's properties, assignments, contacts, campaigns, reports, exports, or integrations.

## API contract tests

The OpenAPI document is validated against implementation behavior. It remains the machine-readable contract for service capabilities.

## Browser tests

Critical flows include login, map load, filtering, event and property selection, assignments, report generation, campaign approval, and mobile navigation.

## Performance tests

Performance measures include map load, event and property queries, alert latency, ingestion lag, report rendering, public-page time to first byte, and API tail latency.

## Failure injection

Failure tests simulate unavailable weather sources, D1 errors, queue duplicates and delays, provider timeouts, property-data outages, campaign API failures, and report-generation failures.