unit test of arbitrary function on a remote embedded mcu using function pointers and variable arguments of arbitrary type, in C

Question

the idea is to write ONE universal unit test function that would execute arbitrary function-under-test on the embedded target mcu side using an externally generated test input arguments (from communication for example). so that the unit test function for the remote mcu is written only once and the test cases are generated on a host PC by sending the known function address and input arguments through some communication means.

for example, if on a remote mcu there is a function of int sumoftwoints(int, int) to be tested, the host pc would pass to this unitTestFcn pointer the address of sumoftwoints (known by linker) and two random ints generated on the host pc then send to the embedded target by uart. the embedded target "calls" by the function pointer received with the supplied number of argument and returns the result to send back to the host pc for result check.

any feedback on if this is plausible or there is fundamental flaw in this test scheme?

the benefit is to move the unit test from the embedded side to the host pc side, which has infinite test case expandability.

Answer 1

If I were to make a system like this, I'd make it consist of 3 parts:

• The PC-side software where you specify your tests in the form of a function address and arguments.
• A receiver/transmitter pair that implements some kind of communication between PC and MCU, eg over serial, Wifi or whatever's available.
• A test executor that runs on the MCU, that executes the function, and returns the result, if any.

Tbe PC-side software could read some artifacts produced by your build process to simplify things, eg so you may use actual function names instead of having to specify the actual address in your tests.

The communication protocol should be text based, relying on the receiver to convert values as appropriate for the receiving platform.

The executor would have to implement the ABI specific to the architecture of the MCU. This is where you'll reach your first major hurdle. First of all, ABIs vary a lot. From Arm where some arguments are passed in one or more registers, some as pointers to the actual argument, and some on stack, to x86 where it's all stack based.

Your next major hurdle is going to be structs. If you're going to allow functions with struct parameters or return values to be called, you have to know how your compiler chose to pack the fields for each specific struct.

All in all, creating something like this would be a non-trivial undertaking, and probably ending up being not that useful, unless you put a lot of work into it, as in making it a commercial product.

Another alternative is that you leave some scratch space on the device, then crosscompile your tests on the PC, then send them over to the MCU one by one or in groups, to be installed in the scratch space and be executed.

In any case, this kind of functionality should never be included in a shipping product, due to obvious security concerns.