I don’t understand how I should structure my tests if I want to test multiple files/classes.
My file structure:
lib/ common/ -> Abstract classes (interfaces) and common platform-independent code/logic embedded/ -> Embedded implementations of classes test/ -> Testing implementations of interfaces from the common folder to be stubbed/mocked src/ main.cpp -> One single small file containing the RTOS task functions test/ test_common/ -> Tests code from the lib/common folder test_embedded/ -> Empty, but would test code on the device test_native/ -> Empty and probably not needed
Within my test/test_common folder I have tried different things. The only thing that seemed to work is to have one main file that calls the entry points for the files that run the test_suite of every individual class.
There are some problems with this though, I can’t use the setUp / tearDown functions from unity, as I would obviously get multiple definition errors when the linker tries to link all the test suites together into one executable. Also if there is a serious error like a segfault the tests after the error won’t be executed anymore. This approach overall requires a lot of manual boilerplate and it is easy to mess up.
What is the correct way of going about this? In my eyes, it seems like every test suite would have to be compiled into a separate executable and executed separately.