this would lead to making an extra copy and an overhead of ensuring code copying when the source file is modified in the production code base
As high_flyer asks, why? You create your test project and add the same files that live in your production directory. No need to copy anything. Modify the file in either place, it will get rebuilt when you rebuild either project. The only thing that gets "copied" is the object file that results from compiling - in one case it is built to the intermediate directory of the test project, and in the other it goes to the production project.

If you want to actually include the dynamic loading as part of the test, here is how I do it in my Windows projects: I have a separate test project that loads these DLLs the same way the actual app does. In Visual Studio, you debug a DLL by specifying an executable to be run when the debugger starts. In my case, the executable is the test program. Clicking "debug" in the DLL project starts the debugger, loads the test program, runs it, when then loads my DLL. I can set breakpoints anywhere in the DLL which do not become "valid" until the DLL is dynamically loaded.

You could do the same thing, except that instead of breakpoints, your test app runs unit tests on your DLL or the code in it if you add links to the source to your test project. I am not so familiar with Qt Creator, but if you use that I am sure there is a similar mechanism.

The reason for keeping your test suites separate from your production code is mainly to minimize confusion over which files belong where. You don't need special project configurations and conditional builds.