Unit tests in STM32CubeIDE

[MMich.2]

Currently I'm developing within the STM32CubeIDE for an STM32F373CC.

I use the main.c as entry point into a wrapper and program all of the rest in C++.

I generally try to keep any HAL code outside of simple classes that can be unit tested easily. Ideally my tests would still compile when data types and some definitions are used from the HW-related codes but I don't really need actual HW-code running within a test. I just want to test algorithms and basic classes. Any comments regarding the HAL or any other HW-related code would still be appreciated.

When adding a class to my project the IDE suggests adding a unit test:

 

So how exactly is this supported? The Foo_test.cpp is simply added to my project but I'm not sure how to proceed. Do I have to integrate a unit testing framework on my own? Is there a framework somehow included in the STM32CubeIDE? Is there support for test execution and visualization?

Any resources and guides are appreciated! If non of this is supported, I'd still like to know why the UI shows this nice "Unit Test" checkbox for me ; - )

A similar question was asked here but hopefully I at least get an answer to why there is a checkbox present in the UI.

[SKled.1]

"there is no flash/verify time required to run the program. If you had to wait 3-5+ minutes every time you wanted to run your test, you would probably run it much less frequently."

Have you looked into the Renode emulator framework ?
It seems much more practical for this than e.g. QEMU. If needed, the peripherals can be modeled, too (by writing C# or Python code modules, next to simple description files for simple cases).
They have a number of STM32 MCUs where some of the peripherals have simple models already.
The USART is implemented such that you'll see text output in a window. So one could use a debug UART to see test results in that window (seems to work with interrupt and even DMA, i.e. that's something that wouldn't need changing from a real implementation)
One could also write peripheral models that have more complex behavior, feed fake data etc. without abstractions in the firmware.
Right now I am only considering testing HW-independent code modules in unit tests with this, also looking at CppUTest now, but haven't got it working yet.
I prefer using the same compiler for tests & real program. But their (Renode's) idea is actually to allow one to test the whole firmware, without modification of its source code, to have a test that tests the same binary as it will be on the real device once it's available. This is a bit "optimistic" unless one is really willing to model all the peripherals in an appropriate manner ;)

[EvO]

I am transitioning from AVR to STM and am considering my options for TDD. I have been using TDD for well over a year now and I will never go back, so it is a must for me for any new project.

The way I have been working so far is:

• any hardware related code is separated out into separate files/modules, i.e. in STM terms: any HAL_* functions
• the main function hardly has any content, only e.g. initProject() and while(1) { runProject() }
• all other code (>95% in my case) is strictly under TDD on a pc, I don't worry about TDD on target.

So far this has worked well for me on MPlab and even ArduinoIDE (only for prototyping). 

The nice side-effect of this approach is also that all platform-specific code is separated by design, so it should make my transition to STM relatively painless (famous last words... ?). Also you can work with any IDE/editor you like for 95% of the development work (I use Kate), without worrying about  hardware.

On STM/Cube I hope to use the same method, although the nature of its main.c is such that I have to recosider how I am dealing with the platform specific code. If I dump it all into main.c it will become too big for my taste, but that is still WIP.

By the way, I am using cpputest (for pure C code) and learned a lot from the abovementioned Grenning book and watching some uncle Bob videos on YT.

Sorry for rambling on, but I thought this might be useful for others going down the same path.