Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Testing and Quality Gates

The Verification Surface

cargo xtask verify is the umbrella for everything CI runs:

CommandScope
cargo xtask verify quickFull CI surface except the slow full-MSL parity gate
cargo xtask verify fullEverything, including full-MSL parity
cargo xtask verify lintFormatting + clippy
cargo xtask verify workspaceWorkspace build/tests
cargo xtask verify docsDocumentation build (rustdoc + mdBook books)
cargo xtask verify msl-parityMSL parity gate on its own
cargo xtask verify template-runtimesOpt-in execution tests for generated target code

Editor surfaces have their own gates:

cargo xtask vscode test   # extension compile + tests
cargo xtask wasm test     # wasm build + browser smoke tests

verify quick/full include the coverage, VS Code, and wasm gates, so they need the same prerequisites CI installs: cargo-llvm-cov, Node/npm, and the wasm Rust target/tooling.

During Development

Plain Cargo works for tight loops:

cargo test -p rumoca-phase-dae
cargo test -p rumoca-phase-structural some_test_name

When testing failure paths, assert the specific phase error you expect — the codebase’s expect-vs-error discipline exists so a passing test means the right thing failed for the right reason.

The MSL Quality Gate

The strongest regression net is the Modelica Standard Library gate: CI compiles and simulates a large MSL model population and compares against recorded baselines, blocking silent regressions in compile success, simulation success, and trace parity. Details, baseline policy, and promotion workflow: MSL Quality Gate.

For compiler changes that could affect MSL behavior, run the parity gate (or at minimum verify quick plus a targeted MSL model) before opening the PR — SPEC_0025 defines what evidence a PR needs.

Coverage

cargo xtask coverage report

CI enforces a coverage gate; locally you need cargo-llvm-cov.

Architecture Tests

Dependency boundaries from SPEC_0029 are enforced by tests. If one fails on your change, the answer is a design conversation (possibly a spec change) — not loosening the test.