Module testing 

The beck test runner — docs/21-tests-in-beck-and-proof.md §21.2 and §21.3, executed.

Why the runner lives in the runtime crate

§21.2: “the test runs the same Roles the runtime drives, with the tiers co-located. What it proves is what the boundary means.” That is not a figure of speech here — a test’s when goes through the same validate crate::Runtime calls on a websocket frame, its given goes through the same fold the sequencer drives, and expect page(session("bo")) renders through the same view the server diffs. There is no second execution path to keep in agreement, which is the only reason the cross-boundary test in §21.2 is three lines instead of a docker-compose file.

What makes a test here unable to flake

Three things, none of them a convention:

• The log is the state, so there is nothing to arrange and nothing to tear down.
• Time and identity are data. The envelope’s at is the sequence position and its actor is written in the test, so two runs produce the same state bit for bit.
• Effects are stubbed, and the complete list of what was stubbed is the effect row, which the compiler already computed. §21.3 rule 1: “‘any value’ is the default, so it needs no expression” — and rule 1’s price is that the default must say what it did, which Report does.

Structs

Case

Options

Report

Stubbed

Enums

Outcome

Constants

DEFAULT_ACTOR

The actor a test speaks as when it does not name one.

DEFAULT_RUNS

How many inputs a property block is run with when nothing says otherwise.

Functions

render

The console form, so beck test and a harness print the same thing.

run

Run every test and property block in a compiled program.