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 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 for the failure model and Build a bounded 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.

Benchmarks are controlled comparative measurements, not tests of correctness. See Benchmark and performance evidence for the exact environment, methodology, and freshness a benchmark must bind.

Next: apply the same evidence path in Check, test, and invoke or measure realizations in Benchmark and performance evidence.

Normative owner & evidence#

Normative owners are systems/developer-interface/AGENTS.md for scenario execution and systems/components/AGENTS.md for the one.test@1 domain and application-test contribution. systems/benchmark/AGENTS.md owns controlled benchmark evidence. The repository-wide verification rules are in 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.