Q: Testing strategies

[huntc]

Firstly, what an amazing effort! Thank you for this initiative!

Being new to the embedded world, I note a severe lack of unit tests in general. As C is often used, I put that down to the effort of setting up a test framework being a deterrent.

I’ve only begun looking at the source here, so I probably have missed some test coverage. I also realise that stubbing out peripherals can be particularly tricky, but I’m curious to learn more about the testing strategies used here.

Thanks for tolerating my questions.

[Dirbaio]

IMO tests that mock register reads/writes have limited value, wrt the required effort.

Many bugs in peripheral drivers are due to the peripheral not doing what you think it does given some register writes. (due to quirky behavior, ambiguous docs...). Testing that the code does the expected register writes doesn't really test that the hardware does what it should do.

[jonas-schievink]

If you want a good example of a well-tested embedded driver, check out bxcan.

CAN is simple to test because there is premade hardware where only the 2 CAN buses need to be connected to get something that can, in principle, test the entire peripheral. This is not the case for most other peripherals, so most HALs don't bother doing this.

If there was more industrial interest in embedded Rust, instead of almost all HALs being written by hobbyists, building such a testsuite to ensure reliability would make more sense.