embededd header files mock

[Artur Karbin]

Hi,

I started reading books about testing. I am at medium level with knowledge of c ++. I write mainly for Windows app. For this reason, I have little knowledge about how the compiler/linker works.

I would like to testing the code that I wrote for some uC (embedeed world). I tested Ceedling, but it works to much automatically (hah, so ironic). For this reason, I will not be forced to know the more advanced c/c++ syntax.
I have reached to the stage that I can test simple functions/classes etc. However, I have a problem with the understanding of the code prepared for microprocessors.

For example,
I have my old legacy code with file:

Files tree:

mocks:
------ fake_uart.h (test compiler)
src:  
------ uart.c, uart.h (native compiler)
test:
------ test_uart.c (test compiler)


//------ uart.h ----

#include <native_io.h> //basic header file for PIN, lots of useless macro for testing
#include <native_timer.h> //timer settings,

void fun1();
....
int funN();

//-----------------


I would like to test functions from file uart.c (fun1-funN). I will not be able to do it, without including files: <native_io.h>, <native_timer.h>. So, should I create /mocks/fake_uart.h or <native_io.h> files ? How to merge functions from the src/uart.c with the mocks/fake_uart.h and  <native_io.h> files ? I don't understand this stage of testing. How to do it, ofc without redesigning the entire uart.c file. I understand that it was best to divide the code into layers. Separate logic from hardware. However, in this case, only the macros (<native_io.h>, <native_timer.h>) included in src/uart.h are problem. Therefore, it probably doesn't make sense to rewrite/splitt code from src/uart.c.

How you do it ? Please help :)


Regards,
Arthur

[James Grenning]

Hi Author

I have numerous articles on using the preprocessor for adding tests to legacy c.

https://wingman-sw.com/articles/tdd-legacy-c

You'll find links to articles about specific problems under the headings "Don't Panic". The article on non-portable header (#include Test Double) file is probably a direct hit.

Generally, if you use the preprocessor, it is indicating a design problem. The preferred alternative for off-target unit testing is to use the linker. In my book I show a driver example where IORead() and IOWrite() are substituted by the linker.

HTH, James

---

James Grenning -- Author of TDD for Embedded C - wingman-sw.com/tddec
Join my live-via-the-web TDD Training

wingman-sw.com -- blog --@jwgrenning -- facebook

--
You received this message because you are subscribed to the Google Groups "cpputest" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cpputest+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cpputest/171ec7a9-6168-4aab-ac59-8a249c49838c%40googlegroups.com.

[James Grenning]

I mean 'Arthur'

To view this discussion on the web visit https://groups.google.com/d/msgid/cpputest/7C722A33-672A-438F-BAE9-920304C537B8%40grenning.net.