I am currently writing a generic telecommand and telemetry library which I plan to use on Zephyr RTOS.

Given an input CSV file, it generates some C++ code which can then easily be integrated in the rest of the project. Specifically, it generates a telecommand function and a telemetry function per defined subsystem. Each subsystem has a set of valid TM and TC data points, but those are known only at generation time.

How should I go about testing that the library can work? I am thinking about defining stub functions which could check that the correct telemetry is read and the correct telecommand is acted upon.

Are stub methods the usual testing methodology for embedded/IoT device testing? If not, what is the more common practice?

1 Answer 1


This belongs more on the SQA SE, but here there is better context. Usually you would want three levels of testing

  • Unit tests, in your case this can be testing the generated code even without an OS. You can achieve it by mocking whatever is missing.

  • Integration tests, mocking everything will check the generated code but will tell you nothing about how it behaves in a real system using a real OS. Starting from small things like "will the code compile" to more subtle things like sending the correct parameters to external functions, or taking into considerations timing. Integration tests might need to run on the real system and hardware, but will not need external dependencies like a network or servers.

  • End to end or system tests, finally you will really want to see that everything works together using real system and environment. in E2E tests you will find things that are hard to simulate, for example extreme timing conditions, malformed or lost messages, or different input formats.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.