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:
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?).
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?
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.).
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?
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)?
CI integration — Which layers run in CI? Cargo test + integration on PR, VM nightly? Physical on release tag?
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*
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
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:
Deliverable:
docs/testing-strategy.md.Migrated from github.com/soubarnak/Mjolnir#23