Skip to content

Testing

Tobias Vorwachs edited this page Oct 25, 2026 · 3 revisions

Testing

Unit and integration tests

cargo test --workspace --locked   # Rust: all crates, including src-tauri
npm test                          # UI: vitest run (Testing Library, axe-core accessibility checks)

Live engine tests (crates/engine/tests/live.rs) are ignored by default. They need the local v15 server and use netsim on 127.0.0.1:64800/64801:

testenv/up.sh v15
MUMCORD_LIVE=1 cargo test -p mumcord-engine --features test-backend --test live -- --ignored --test-threads=1

See Development for the test servers.

Other checks: cargo fmt --all --check, cargo clippy --workspace --all-targets --locked -- -D warnings, npm run lint, npm run typecheck.

End-to-end tests

UI end-to-end tests drive the real app (real engine inside Tauri) through WebDriver, against the local test servers.

npm run e2e                                              # whole suite
npm run e2e -- --spec e2e/specs/smoke/app.e2e.ts         # one spec (args go to `wdio run`)
MUMCORD_E2E_SHARD=2 npm run e2e                          # one of the four CI shards (e2e/shards.json)
  • Requires only Docker (your user in the docker group) and npm ci on the host. Everything else runs in the mumcord-e2e image (WebKitWebDriver, tauri-driver, Xvfb, gnome-keyring).
  • Cold run takes about 5 minutes (image build and first debug build), a warm run about 15 seconds without code changes. Build caches live in ~/.cache/mumcord-build/e2e/ (override with MUMCORD_E2E_CACHE).
  • Extra docker run flags go into MUMCORD_E2E_DOCKER_ARGS, for example MUMCORD_E2E_DOCKER_ARGS="--cpus=2" npm run e2e to mimic a 2-core CI runner. MUMCORD_E2E_IMAGE changes the image name.
  • Audio: the app is built with the test-backend feature, and MUMCORD_AUDIO_BACKEND selects null (silence in, discard out; default) or file:<in.wav>:<out.wav> (48 kHz mono 16-bit).
  • Every spec file gets a fresh profile and an empty keyring; spec files run one at a time.
  • Failures save a screenshot and page source to e2e/artifacts/ (git-ignored); axe reports go there too.
  • Specs live in e2e/specs/<area>/<name>.e2e.ts (mocha + WebdriverIO) and use helpers from e2e/helpers/index.ts for starting servers, running the bot, using netsim and restarting the app. See e2e/README.md.

In CI the suite runs on pull requests to main: one job builds the test image and app once, four shard jobs run the spec files listed in e2e/shards.json in parallel (each with its own test servers), and the "Linux E2E" job sums them up. A full run takes about 13–15 minutes. A new spec file must be added to e2e/shards.json, otherwise the run fails.

Packaging smoke test

scripts/smoke/smoke.sh starts an installed build and checks that it connects to a local server. The test-builds workflow runs it on Linux, Windows and macOS.

CI workflows

Workflow File Runs on What it does
CI .github/workflows/ci.yml every push and pull request On Ubuntu, Windows and macOS: cargo fmt, clippy, cargo test, UI lint, typecheck, UI tests, and a Tauri debug build (--debug --no-bundle)
E2E .github/workflows/e2e.yml pull requests to main, manual Linux E2E suite via npm run e2e; uploads failure artifacts
Release .github/workflows/release.yml pushes of v* tags Unsigned AppImage, Windows installer and universal DMG, installed and smoke-tested on fresh runners, then a draft GitHub Release with SHA256SUMS (see Development)

Manual checks

Things that cannot be judged automatically (how audio sounds, Windows and macOS behaviour) are checked by hand against a local test server, following the acceptance criteria in the spec.

Clone this wiki locally