# Tests, simulations, and fixtures

Tests prove exactly the behavior they exercise. One keeps four evidence classes
distinct—application tests, simulations, fault campaigns, and fixtures—so a
result cannot silently borrow authority from a stronger claim than its own
scope.

## Application tests are owner-authored scenarios

Application tests are scenarios owned by the selected root. A `scenario`
selects one root-reachable operation plus a project-relative canonical JSON
request document and a project-relative expected success document. A `browser`
scenario declares an ordered origin-relative sequence using only exact
accessibility targets.

This is a domain declaration, not new executable `.one` syntax. It does not
compile a program or run code during checking. The `one.test@1` domain is real
and exercised by the Components-owned normalizer and its tests; the snippet
below uses its published declaration form, while the concrete names are example
inputs.

```one
one 1

semantic acme.orders.tests
    domain one.test@1

    scenario Health@1
        invoke acme.orders#Orders.Health@1
        request ./tests/health.request.json
        expect ./tests/health.response.json
        expose readiness at route(path: /health)

    browser PublicPage@1
        open route(path: /)
        expect visible role(kind: heading, name: "Orders")
        click role(kind: button, name: "Review")
        viewport(width: 1280, height: 720)
```

A `scenario` may expose its exact result as readiness at one canonical route. A
`browser` scenario may declare `open`, `expect visible role(...)`, `click
role(...)`, `fill label(...)`, and an optional `viewport`. The Components owner
supplies the default viewport when it is absent. The scenario commits the exact
scenario, Build report, invocation report, actual JSON, and terminal comparison;
the retained invocation report remains the authoritative runtime evidence and
the scenario result grants no Build or runtime authority.

A root with no declared scenarios may use an already owner-approved
framework-native test realization. Otherwise, absence is typed unsupported. It
is never reported as zero passing tests.

## Simulations prove only their model

A simulation or replay binds everything it substitutes: virtual time, entropy
seeds, scheduler choices, fault points, model and human fixtures, provider
responses, network conditions, source, lock, artifacts, and every unmodeled
assumption it relies on. Replay re-evaluates the recorded inputs against those
bindings.

A simulation can prove only its declared model. It cannot issue production
conformance, provider-observation, or postcondition evidence, and it cannot mint
a production receipt. Simulated clocks, entropy, transports, stores, identity,
and effects are explicitly marked and isolated by policy. The resulting branch
is counterfactual, not a fact about production.

## Fault campaigns assert safety properties

A fault campaign targets named owner boundaries—authorization, dispatch,
provider acceptance, commit, acknowledgement, checkpoint, lease renewal,
observation, and reconciliation—and asserts product safety properties, not mere
process survival. Typical properties include:

- no duplicate effect across retries and restarts;
- bounded recovery within a declared deadline or budget;
- retained evidence for every ambiguous dispatch; and
- correct quarantine of an unreconciled outcome.

An unknown outcome is retained and reconciled; it is never blindly repeated. See
[Handle failures](/one/examples/failure-handling) for the failure model and
[Build a bounded agent](/one/examples/agent) for a bounded autonomous consumer.

## Fixtures live with their owner

Keep each fixture at the narrowest owner that can independently test it:

- unit, property, fuzz, compile, and negative tests live in the owning crate;
- reusable provider and adapter laws live in the owning system's `conformance/`;
- cross-system tests live in a deliberately named integration fixture owned by
  the narrowest affected system; and
- external-service, privileged-sandbox, destructive, and performance tests are
  explicit bounded opt-in fixtures with bounded inputs and cleanup.

A narrow fixture may construct public owner values directly to test an atom or
provider, but it remains owning test evidence. It never becomes the product
entry point, user documentation, acceptance path, or basis for claiming the
end-product milestone complete. Final acceptance starts at the same canonical
`one.one` lifecycle a user runs. See
[Check, test, and invoke](/one/lifecycle/check-test-invoke).

Benchmarks are controlled comparative measurements, not tests of correctness.
See [Benchmark and performance evidence](/one/platform/benchmark) for the exact
environment, methodology, and freshness a benchmark must bind.

Next: apply the same evidence path in
[Check, test, and invoke](/one/lifecycle/check-test-invoke) or measure
realizations in [Benchmark and performance evidence](/one/platform/benchmark).

## Normative owner & evidence

Normative owners are
[systems/developer-interface/AGENTS.md](https://github.com/muijf/one/blob/main/systems/developer-interface/AGENTS.md)
for scenario execution and [systems/components/AGENTS.md](https://github.com/muijf/one/blob/main/systems/components/AGENTS.md)
for the `one.test@1` domain and application-test contribution.
[systems/benchmark/AGENTS.md](https://github.com/muijf/one/blob/main/systems/benchmark/AGENTS.md)
owns controlled benchmark evidence. The repository-wide verification rules are
in [AGENTS.md](https://github.com/muijf/one/blob/main/AGENTS.md) and the root
`SPEC_V2.md`.

Demonstrated today: the `one.test@1` scenario and browser declaration form, its
normalizer, and the Developer Interface scenario execution path that commits
the exact Build report, invocation report, actual JSON, and terminal comparison.

Illustrative or deferred: the concrete `acme.orders` names above. The
simulation and fault-campaign prose describes the owned model and its evidence
classes; it is not a claim that every owner boundary has a current executable
fault harness.