Unit testing for embedded development

Am 18.05.2018 um 09:18 schrieb pozz:

You should think about placing constants like the buzzer on/off time in a header file and using preprocessor macros. Then you can use two different header files, one for unit testing and one for the real embedded system.

You need to understand the concept of "mocking" w.r.t. interfaces and time. Then you need to structure your implementation so that the real interfaces can be replaced with the mock interfaces during testing.

By symmetry, to unit test the interfaces you need to have many mock applications.

A good way to do this type of thing with "dependency injection" and "mock objects". It's traditionally done with OOP but you can do it with plain C as well. You interface the external world through an object so you'd say (pseudocode):

class World { ... }; class Real_world extends World { ... };

int run(World world) { world.buzzer_on(); world.sleep(1000); // ms world.buzzer_off() } int main() { World w = new Real_world(); run(w); } or things like that. In the real system "world"'s methods would call stuff from the BSP.

You'd also have a test class, e.g.

class Test_world extends World { ... };

int run_test() { World w = new Test_world(); run(w); // run your application with the test world instead of // the real one } The test world wouldn't trigger the real hardware, but instead would just feed the application some canned fake data, and keep a few variables to track whether the buzzer was on, how much time had passed, etc. Then your unit tests would make sure those variables got updated to the right values.

If you do this thoroughly enough, and have enough logging in your app code, then when something goes wrong you can translate the logged input stream into mock inputs in your test world. Then you can reproduce the error by running the app with the test world instead of the real one, so you don't have to go mess with all the buzzers and timers and stuff. Once you've reproduced it, you can debug it completely in the test world and with luck, the fixed version will work the real world.

Better yet, you can run and debug the test world completely on your workstation with its capacious memory and nice debugging tools, without touching the embedded hardware at all, no cross compiling, etc.

Read the book "Test Driven Development for Embedded C" by James Grenning:

James has a whole chapter on faking the time.