I am writing unit tests for some embedded C, that run on a host machine (not testing on target yet) and compile with GCC. I have been using the Ceedling build system with the Unity testing framework to test.
One of the files I would like to test includes a file (say a.h) that includes another file (say, cpu.h) that is part of the board support package from the embedded device vendor, and uses keywords specific to the target compiler (e.g. __cregister, such as in extern __cregister volatile unsigned int IER;.
Another issue, again with such a file included from the BSP, is inline assembly asm() sections such as in #define FOO_ASM asm("FOO").
These both of course throws an error when building tests as GCC does not recognise these keywords.
I had thought I could prevent these BSP headers from being added in by having Ceedling generate a mock, by adding #include "mock_a.h" to my test file, but GCC still compiles a.h, and thus b.h.
Is there a best practice way of solving such issues?
I could add something like the below to the BSP file in question, but I am loath to alter vendor code that would change or overwrite my changes with a new version release, I would rather understand how to isolate the unit properly.
// Unknown how __cregister is initially defined
#ifdef TEST
#undef __cregister // Redefine __cregister to nothing
#define __cregister
#endif
extern __cregister volatile unsigned int IER;
It ended up that I followed the method outlined in the link in my comment to the OP.
So for the example from my original post
/* foo.h */
extern __cregister volatile unsigned int IER;
#define FOO_BAR_ASM asm("BAR");
I created the following file, with the same name, within the test/support/ directory and removed the include path for the real BSP files from the test build settings:
/*foo.h - in test/support */
extern volatile unsigned int IER;
#define FOO_BAR_ASM
Then added an include like #include "mock_foo.h" to the test file.