Unit-Testing with RTIC v2

[robamu]

Hello,

I have some components in my application which I'd like to unit-test. However, I am not sure how to do this, especially in the presence
of shared resources.

Normally, I would mock some components so I have fine-grained control over input and output. I do not know how to do that with RTIC v2 idiomatically.

Would this be possible by somehow implementing lock for my mock data structures? Maybe some examples would help here as well.

Another problem I found is that I simply can not run even a simple test harness on my host computer.
I get errors like this:

va416xx-rs/flashloader on  bootloader-flashloader [$!+?] is 📦 v0.1.0 via 🦀 v1.78.0
❯ cargo ut -p flashloader
   Compiling flashloader v0.1.0 (/home/rmueller/Rust/va416xx-rs/flashloader)
error[E0412]: cannot find type `Peripherals` in module `rtic::export`
  --> flashloader/src/main.rs:86:1
   |
86 | #[rtic::app(device = pac, dispatchers = [U1])]
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not found in `rtic::export`
   |
   = note: this error originates in the attribute macro `rtic::app` (in Nightly builds, run with -Z macro-backtrace for more info)
help: consider importing one of these items
   |
88 +     use cortex_m::Peripherals;
   |
88 +     use crate::pac::Peripherals;
   |

I also get linker errors which I try a regular cargo test --<host-triplet>, so what I did now was to define an additional library like this

#![no_std]
#[cfg(test)]
extern crate std;

#[cfg(test)]
mod tests {
    #[test]
    fn simple() {
        assert_eq!(1 + 1, 2);
    }
}

and now I can run tests using cargo test --<host-triplet> --lib . Some documentation related to unit-testing/automated testing might be useful. Embedded apps can have complex components where automated testing might be really useful, and ideally I'd like to do that inside the application without the need to create a new library just for that.

Kind Regards
Robin

[AfoHT]

Hi!

I think I follow what you want to achieve, and I think one of the primary issues you ran into is the distinction between "on host" and "on target" (given your example).

As you know, RTIC framework expects some kind of device pac that holds the svd2rust-representation of the device you intend to target.

If there is nothing device specific in your modules/units, maybe it would be a path forward to create some "mock" device pac satisfying this condition. If compiling/type-checking is enough I think you could come quite far, but running is quite something else.

Maybe building for your desired target is more realistic, or the lm3s6965 that you can run in QEMU, as done in RTIC CI.

For units that do not touch RTIC itself, could those not be tested completely independently?

On a completely different track, there was this cool RTIC v1 "on host" variant that runs on Linux, not tried it myself: https://github.com/chemicstry/linux-rtic

No real answers to your immediate concerns, but I agree with you that improving RTIC testing and verification capabilities in general is highly valuable. Eager to hear if you made any progress with this in general too.