Test strategy
Layers
| Layer | Evidence | Scope |
|---|---|---|
| niseCore focused unit | GTest/GMock CMake targets | matcher, sensor, storage and supporting PAL/VFM pieces |
| WBF source-derived unit | Extracted CBiometricDevice functions + generated customer props | capture, thread, completion, wake and cancellation paths |
| C++/Rust adapter integration | Dedicated C++/Rust workflows and replay-oriented tests | tested adapter surfaces and parity observations |
| Virtual specifications | Markdown test cases and generated harnesses | function-level preconditions and expected results |
| Customer build | Exact niseCore/WBF/include refs + WBF project | compile/link/package compatibility |
| Firmware integration | Host command/update tests plus exact device/firmware version | command/status/update behavior across the external firmware boundary |
| Driver validation | HLK, accuracy, package/security checks | OS/device/customer acceptance evidence |
| Release evidence | Workflow run, signed artifact and exact SHA row | delivery result |
utest branch model
dev is the implementation baseline with 333 files and complete test trees. main has nine files and publication/workflow infrastructure; it is not equivalent coverage. See utest branch differences.
Current Jira-driven test direction
- HDRFP-12256: hardware-independent captured-behavior replay for C++/Rust adapter parity.
- HDRFP-12248: virtual testing for Dell telemetry behavior.
- HDRFP-11807: verify existing PAL/VFM failure cases through virtual tests.
- HDRFP-12166: restore/setup AutoHLK for 26H2/Rust development; current evidence includes mixed builds.
- HDRFP-12269: quality-verification planning only; no test system is claimed complete.
Result semantics
- Passing source-derived tests prove the tested function/variant at the selected revision.
- Passing C++ and Rust adapter workflows proves those workflow checks; it is not automatically complete parity.
- A build failure, extraction failure, skipped test or missing artifact is not a pass.
- Customer build success does not by itself prove runtime, firmware, HLK, security or accuracy acceptance.
- Host mocks do not prove firmware command semantics; joint evidence requires a real or authoritative firmware counterpart.
- Branch-specific expectations belong in explicit variants, not hidden conditional assumptions.
See GitHub Actions evidence for the bounded run inventory and exact interpretation rules.