Correct file structure/architecture for testing

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.

Also, I am having trouble with debugging unit tests. I can get it to debug from the command line by running:
pio debug -e native --interface=gdb -x .pioinit

However the current line is not highlighted. Once I have run it from the command line I can also launch it from the GUI, but still it seems to only partially work.