Testing

Testing is an integral part of application development. Using the example of how we do it at esp-hal, you can write and run tests for your application that run on the hardware itself.

Host Testing

Where possible, and where it makes sense, you should try to test as much as possible on your host machine, not on the target device. It’s easier to test in CI, faster, and won’t waste flash write cycles on your device. Tests that need the real hardware to run them, should use a Hardware In Loop testing setup instead.

Hardware-in-Loop Testing

Hardware In Loop (HIL) testing is the use of real devices in the testing setup. We use the embedded-test framework to write unit and integration tests, so in principle, the process is only slightly different from normal non-embedded projects. We use probe-rs (check correct revision in hil-test sub-repository) to flash and run tests on the target device. To do this, you must use only the USB-Serial-JTAG port on your DevKit (see Hardware Overview). If your device does not have such a port, you will have to use esp-prog or another suitable programmer and connect it according to the connection instructions (select the desired chip on the page).

Using esp-generate, and selecting embedded-test under probe-rs will set up testing in your project for you, such that you can just run cargo test locally when the device is connected correctly.

embedded-test

embedded-test tests are written as functions placed under the #[test] macro, similar to the std test framework. Typically, the result of the test is the result of this function, i.e. if the code panicked, the test is considered failed and the next test is run. However, there are many ways to customize this process, such as the #[should_panic] attribute macro, where panic is considered a successful test completion, setting timeouts for tests, and much more, which can be found in the embedded-test documentation. It also supports integration with IDE, as it mimics the default Rust test harness.