Testing missions

The cosmos_dev package runs missions outside Cosmos, so you can test in the browser or headlessly in CI.

Testing aid, not the engine

The mock approximates Cosmos to make offline testing useful — it is not a reimplementation and does not aim for 100% parity. Some behaviors are approximated or absent by design. Please don't file issues or feature requests for more engine parity; confirm anything engine-exact in Cosmos.

Mock GUI (in the browser)

sbs debug . --gui           # or just: sbs debug .

Opens a browser renderer at http://localhost:8765/ with a 3D cinematic view and a 2D radar, backed by an in-process mock of the sbs engine API. The mock is calibrated to the real engine: ship speeds, 3D steering, per-facing shields, heat, energy, and the weapons model (beams, torpedoes, drones, mines, EMP).

Headless conformance run

sbs debug . --no-gui --map 0 --test 30

Plays ~30 sim-seconds, prints MAST coverage, and exits 0/1 with a pass/fail verdict — ideal for CI. Add --exercise to actively drive selections/comms/console-cycling for more route coverage, --junit <path> for a JUnit report, and --seed N for reproducibility.

Validating AMD files

sbs lint .                  # check .amd for silent structural/reference errors

AMD's failure modes are silent — a typo'd # [Display](key) heading drops a whole quest with no error. sbs lint re-scans a mission's .amd and reports broken/vanishing headings, unclosed --- fences, and heading-level jumps (errors, exit 1), plus dangling Then: reveal / choice / Scene: targets, a signal X with no //signal/X route, and a reach i,j with no landmark At: (warnings). Add --strict to fail on warnings for CI. See the CLI page.

Unit tests

The library uses unittest:

python -m unittest discover -s tests

See Contributing › Testing for writing tests against the cosmos_dev.mock API.