Testing

February 12, 2026 ยท View on GitHub

This document summarizes how to validate the driver and where the testing gaps remain. Hardware correctness is the highest-risk area and requires on-device validation.

Table of Contents

Host Checks

cargo test --lib
cargo clippy --all-targets -- -D warnings
cargo doc --no-deps

Optional coverage (requires cargo-llvm-cov):

cargo llvm-cov --lib

Hardware Validation

Hardware QA lives in apps/qa-runner/ and is the primary way to exercise DMA, register access, and PHY behavior.

From the repo root:

cargo xtask build qa-runner
cargo xtask run qa-runner

See apps/qa-runner/README.md for wiring and board notes.

CI Coverage

CI validates the host toolchain and documentation, and includes an ESP32 target check. Current CI jobs cover:

  • cargo fmt --all -- --check
  • cargo clippy --all-targets -- -D warnings
  • cargo test --lib
  • cargo doc --no-deps
  • cargo +esp check --target xtensa-esp32-none-elf -Zbuild-std=core

Clippy also runs a feature matrix (default + smoltcp + async + critical-section + embassy-net) to catch feature-gated issues.

Coverage and Gaps

Covered well:

  • Configuration, error handling, and parsing logic (host unit tests)
  • PHY logic via MDIO mocks (host tests)
  • Core DMA ring behavior with mocked descriptors (host tests)

Known gaps and risks:

  • Hardware-only paths: register access, clock/reset sequencing, DMA ownership
  • Network variability: DHCP and link bring-up depend on external traffic
  • Async runtime behavior: waker logic is unit-tested, full behavior is on-target

Notes for Production Use

If you are shipping to production or critical devices, validate on the exact board/PHY and network environment you plan to deploy. Treat hardware validation as required, not optional.