Testing & Simulation

Seven test layers, all verified pre-release. As of v1.39.2 (2026-10-11): 1703 Rust tests green + 6 ignored (regtest + network + real-journal opt-in), 376 svelte-check files / 0 errors / 0 warnings.

1. Unit Tests

Per crate, pure logic. cargo test --workspace covers all 19 library crates + 7 binaries.

Key test counts (as of v1.39.2 — #[test] / #[tokio::test] attributes per crate; the authoritative total comes from cargo test --workspace):

(The binaries carry their own glue-path tests: daemon 52 — supervisor loops, notifier hydration, wallet-moment cooldown, auto-backup loop, the connected-worker refcount over V1, TLS and Sv2, plus one #[ignore] per-worker regtest consensus E2E — CLI 7 for argument plumbing, the WarpTune CLI 3, and the macOS launcher 5.)

# Everything
cargo test --workspace

# A single crate
cargo test -p warppool-share-validator

# With output
cargo test -p warppool-stratum-v2 -- --nocapture

2. Integration Tests

Multiple crates in-process, axum mock servers for external services. Per crate under tests/ or in an in-crate tests.rs module (the api crate keeps its handler tests in src/tests.rs).

Typical cases:

3. Simulation (dvb-warppool-sim)

Runs against the real daemon process (or spawned in-process). Scenarios are end-to-end stories.

Built-in scenarios

Invocation

solo-block-found runs self-contained — it spawns a Stratum V1 server in-process with network_target=[0xff;32] (every valid share becomes a BlockFound) and a JsonStratumMiner (persona BitaxeUltra). No Bitcoin Core required:

dvb-warppool-sim scenario solo-block-found --duration 10
# → Result: BLOCK FOUND after 55 ms (worker=bc1qsim-bitaxe, job_id=sim-job-1)

dvb-warppool-sim scenario connection-storm-defense --duration 15 --attackers 200
# → Success: 10, RateLimit: 190, OtherErr: 0
# → OK: rate limit fired 190x (burst allowance was 10)

dvb-warppool-sim scenario enterprise-load-smoke --duration 15 --miners 200
# → Accepted: 57400 (~3826 shares/s), Rejected: 0, Disconnects: 200

Personas

Sim miners mimic real hardware (hashrate, user agent, TLS support, reconnect pattern):

Failure modes

dvb-warppool-sim failures <mode> injects production problems:

• rpc-down — Bitcoin Core unreachable
• zmq-disconnect — block notify gone
• tls-handshake-fail — expired cert
• miner-hang — connection stalls after N shares
• network-latency — artificial RTT
• packet-loss — N% packet loss
• invalid-template — broken coinbase tx
• reorg — tip gets rolled back
• memory-pressure — pool under RAM pressure
• disk-full — SQLite write failure

Security suite

dvb-warppool-sim security drives adversarial inputs (line flood, connection storm, slowloris, auth flood, weak ciphers, …).

Correct outcome: every connection rejected cleanly, no panic, no OOM.

4. Regtest E2E (Phase 15b — opt-in)

For full E2E against a real bitcoind regtest:

eval "$(scripts/regtest-up.sh)"   # starts bitcoind regtest + sets env vars
cargo test -p warppool-bitcoin-rpc --test regtest_e2e -- --ignored --nocapture
scripts/regtest-down.sh --purge   # cleanup

Four #[ignore] tests in total — three in warppool-bitcoin-rpc:

…plus a full consensus E2E in the daemon crate (per_worker_regtest_full_consensus_e2e, apps/dvb-warppool-daemon/src/regtest_e2e_tests.rs): it mines a real per-worker-coinbase block against regtest and asserts Bitcoin Core accepts it, the reward is attributed to the right worker, the witness commitment is correct and no cross-payment happens.

cargo test -p dvb-warppool-daemon --lib -- --ignored --nocapture per_worker

CI does not run them (no bitcoind in the runner image). Locally they are very useful before release tags. See Configuration Reference → WARPPOOL_E2E_REGTEST_*.

5. Performance Benchmarks (Phase 19 — opt-in)

Criterion suites for the hot paths:

cargo bench --workspace
# or
cargo bench -p warppool-share-validator --bench validate

See Performance Benchmarks for baseline numbers and interpretation.

6. UI side (svelte-check)

cd ui
pnpm install
pnpm run check   # = svelte-kit sync && svelte-check && node scripts/i18n-guard.mjs
# → 376 files / 0 errors / 0 warnings; i18n-guard: locale parity, key existence, no hardcoded German

svelte-check is clean — 0 errors, 0 warnings — and the i18n guard (all 8 locales carry the same key set, every i18n.t() key exists, no hardcoded German in components) is part of the same CI gate.

7. Fuzzing (opt-in)

The inbound Stratum parser reads bytes straight off the wire, so it is the prime hardening target. Two layers:

• Stable smoke fuzz (runs in the normal suite, no nightly): messages.rs::tests::fuzz_parse_never_panics drives StratumRequest::parse

  • sanitize_json_escapes through 20,000 deterministic mutated / pathological inputs (random bytes, byte-mutated valid messages, deep nesting, escape storms) and asserts none of them panic.

• Stable smoke fuzz, second layer (v1.26.0): stratum-v1/src/fuzz_smoke.rs and stratum-v2/src/fuzz_smoke.rs — dependency-free xorshift generators push noise, mutated valid input and random frames through StratumRequest::parse + the hex helpers, every Sv2 decode_payload, decode_frame, and MiningServerSession::process_frame (before and after a valid SetupConnection). Several thousand cases each, no panics allowed.

• Coverage-guided fuzz (crates/stratum-v1/fuzz/, needs nightly + cargo install cargo-fuzz):

  cargo +nightly fuzz run parse_stratum     # from crates/stratum-v1/
  

  The fuzz/ crate has its own workspace root, so the main cargo build/test --workspace never pulls in the nightly-only dependency. Crashes go into fuzz/artifacts/; minimise and add the input as a regression case in fuzz_parse_never_panics.

CI

CI runs on a self-hosted Forgejo runner (git.warppool.org); the workflow files still live under .github/workflows/ but are executed by Forgejo Actions. There are no macOS and no Windows runners — everything below is Linux-only. See CI porting notes.

.github/workflows/ci.yml matrix:

• cargo fmt --check (no diff)
• cargo clippy --workspace --all-targets -- -D warnings (a few style lints allowed: field_reassign_with_default, get_first, too_many_arguments)
• cargo test --workspace
• cargo deny check (licenses + advisories — RustSec feed via deny)
• UI job: pnpm install + pnpm svelte-check + pnpm build

Separate workflows (see Architecture):

• release.yml — tag-triggered: multi-arch Docker + native Linux binaries + SBOM. No macOS/Windows jobs — the .dmg/tarball assets are built manually per release with packaging/macos/build-macos-release.sh, the .msi is paused
• repro.yml — reproducible-builds verify (build twice + sha256 diff)
• docs.yml — mdBook → docs.warppool.org
• benches.yml — Criterion, manual dispatch only (not per-PR, not on tag push: the fat-LTO bench profile OOM-compiles on the CI box and benches must never gate a release)