Unit testing for embedded development

I'm not an expert on test-driven development. I know the general ideas behind TDD, however I never used it in my projects.

I want to start using TDD, at least creating some unit testing on some more critical units. However I have many difficulties.

For a module that calculates a checksum, it is very simple to create a unit test. However an embedded firmware is more complex.

Consider a simple example. When the user press button 1, a buzzer must be activated for 1 second.

----- Start of buzzer.c ----- #include "timer.h" #include "bsp.h"

statis Timer tmr_buzzer;

void buzzer_on(uint16 time_ms) { TimerSet(&tmr_buzzer, time_ms); bsp_buzzer_on(); }

void buzzer_off(void) { bsp_buzzer_off(); }

void buzzer_task(void) { if (TimerExpired(&tmr_buzzer)) { buzzer_off(); } }

----- End of buzzer.c -----

Of course I have a bsp.c/bsp.h and a timer.c/timer.h.

Now I want to create a unit test for buzzer module, to run on PC.

----- Start of test_buzzer.c ----- #include #include "timer.h" /* driver for PC testing */ #include "bsp.h" /* bsp_buzzer_on/off declarations */

static bool buzzer_on;

int main(int argc, char *argv[]) { /* Test if buzzer_on() works */ buzzer_on(10000); if (!buzzer_on) ... test failed ... /* Wait for 10010 ms */ if (buzzer_on) ... test failed ...

... }

void bsp_buzzer_on(void) { buzzer_on = true; } void bsp_buzzer_off(void) { buzzer_on = false; }

----- End of test_buzzer.c -----

How do you simulate passing of the time (wait for 1010ms)? Of course, I don't want to wait 10 seconds for the test. I need to speed up the time.

Is this the correct way to create a unit testing for a buzzer library?

Reply to
Loading thread data ...

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.


 Click to see the full signature
Reply to
Tobias Baumann

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.

Reply to
Tom Gardner

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.

formatting link
might be sort of helpful.

Reply to
Paul Rubin

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

formatting link

James has a whole chapter on faking the time.

Reply to

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.