"> <@t-moe:matrix.org> Hi Manuel,..." <- > <@mhatzl:matrix.org> you mean a custom proc-macro per test function? > How does this work together with running `cargo test`? > In embedded-test you flash the binary with all tests included and use probe-rs to selectively execute the test fns if I understood that correctly. > > For now, I only created my own cargo runner that takes the binary, flashes it and receives defmt logs via OpenOCD using RTT. > Memory access to the target while testing won't be possible for many chips from Infineon, but it is planned to use UART instead of RTT in these cases, so defmt should still work. well, that depends a bit on whether you need to reset the device between each test case or only after the entire suite. the (revised) overall idea would be the following: * you annotate your `mod tests` in each file with a custom proc macro, * you set harness=false for lib in Cargo.toml * when running the unit tests for the host architecture, the proc macro around `mod test` can create the needed main function and use something like libtest_mimic in the background. You'll also have to collect the tests across all files, but this is possible. * when running the unit tests for the target architecture, the proc macro basically compiles the entire (unit test) file twice: * once for the target architecture, annotating the #[test] functions with something like defmt_test::test. * once for x86, resulting in code that flashes the target and checks the uart output and in turn output test failure/sucess for each test case (via libtest-mimic)