Testing strategy — unit, integration, simulated-manifest, VM, and physical layers #1

Open
opened 2026-08-03 22:18:33 +00:00 by xavierk · 0 comments
Owner

Part of #1

Question

Define the testing strategy for mjolnird (Rust daemon), mjolnirctl (CLI), mjolnir-gtk (GTK), and mjolnir-km (C kernel module) across five layers. Module boundaries are now settled (ADR-005, modules.md).

Settle:

  1. Unit tests — Per Rust module, per C function. Decide test framework (cargo test, kunit?), mock strategy for HAL (trait-based vs cfg-gated?), and what SQLite/store.rs looks like in unit tests (in-memory? file-per-test?).
  2. Integration tests — Cross-module within mjolnird. Which integration scenarios justify a test? D-Bus method → policy → hal path? Telemetry poll → store → aggregation pipeline? Startup/shutdown sequencing?
  3. Simulated manifests — ADR-001 mentions "Policy engine is testable against simulated manifests." Define the simulated-manifest test harness: how manifests are injected, which modules are exercised, how many manifest variants cover the probe matrix (AMD-only, Intel-only, hybrid-graphics, no-KM, etc.).
  4. VM testing — Kernel module requires a VM. Decide VM tooling (QEMU/libvirt, Vagrant?), test automation for km load/unload, netlink round-trip, governor select/deselect, telemetry sample with real /sys data. Kernel version matrix?
  5. Physical testing — Reference machine (MSI Thin A15 B7UCX). Which tests must run on bare metal? DKMS install, charge thresholds, dGPU power, thermal override. How is the physical test run automated (ssh + just target)?
  6. CI integration — Which layers run in CI? Cargo test + integration on PR, VM nightly? Physical on release tag?
  7. Coverage targets — Per-layer coverage expectations. Module-level coverage vs FR coverage mapping.

Deliverable: docs/testing-strategy.md.


Migrated from github.com/soubarnak/Mjolnir#23

Part of #1 ## Question Define the testing strategy for mjolnird (Rust daemon), mjolnirctl (CLI), mjolnir-gtk (GTK), and mjolnir-km (C kernel module) across five layers. Module boundaries are now settled (ADR-005, modules.md). Settle: 1. **Unit tests** — Per Rust module, per C function. Decide test framework (cargo test, kunit?), mock strategy for HAL (trait-based vs cfg-gated?), and what SQLite/store.rs looks like in unit tests (in-memory? file-per-test?). 2. **Integration tests** — Cross-module within mjolnird. Which integration scenarios justify a test? D-Bus method → policy → hal path? Telemetry poll → store → aggregation pipeline? Startup/shutdown sequencing? 3. **Simulated manifests** — ADR-001 mentions "Policy engine is testable against simulated manifests." Define the simulated-manifest test harness: how manifests are injected, which modules are exercised, how many manifest variants cover the probe matrix (AMD-only, Intel-only, hybrid-graphics, no-KM, etc.). 4. **VM testing** — Kernel module requires a VM. Decide VM tooling (QEMU/libvirt, Vagrant?), test automation for km load/unload, netlink round-trip, governor select/deselect, telemetry sample with real /sys data. Kernel version matrix? 5. **Physical testing** — Reference machine (MSI Thin A15 B7UCX). Which tests must run on bare metal? DKMS install, charge thresholds, dGPU power, thermal override. How is the physical test run automated (ssh + just target)? 6. **CI integration** — Which layers run in CI? Cargo test + integration on PR, VM nightly? Physical on release tag? 7. **Coverage targets** — Per-layer coverage expectations. Module-level coverage vs FR coverage mapping. Deliverable: `docs/testing-strategy.md`. --- *Migrated from github.com/soubarnak/Mjolnir#23*
xavierk added the wayfinder:grilling label 2026-08-03 22:18:33 +00:00
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: xavierk/Mjolnir#1