We have legacy code that has unit tests (wohooo :D [is it then still legacy?:D]).
The production code is an exe file, another one is a DLL but with only one single entry point exported (for some plugin interface).
Then there are separate unit test projects which need to test the exe and the plugin dll. The current approach is very simple: Include the sources for the executable in the test project and test the code. Same thing for the dll file.
This has massive drawbacks: The code has to be compiled multiple times. Changing a file in the exe triggers a build for the test too. I assume the way it was done was because we were all young and clueless.
AFAIK there is no proper way to exercise the executable code (beside calling the executable and observe its effects) and it was not possible to test the DLL only via the exported functions. We did not want to spam the DLL code nor the exe with lots of __declspecs to export and import data just for the test. (Please: This discussion should not be about the fact that we should only test the DLLs public interface, this topic is more complicated).
I am now getting creative with that because compilation time is critical for us and we do not want to create a separate configuration for the exe and dll file which produces a static library as this will be still compilation overhead.
One approach I've done was for the test project to have a pre-build step that does some dirty trick: It gathers all existing obj files and links them into an impromptu static lib which is consumed by the test project. This works very well but still has some drawbacks: The pre-build step is executed always, so even if no obj file has changed, the linking of obj files has to be executed every time I build the test project -> annoying.
Now I remember that I've toyed around with adding the intermediate obj files directly to my test project but dropped this approach.
Adding the obj files has one advantage: Speed, I add the obj files I need from the project, if I do not test everything I do not need to link all obj files. But this has some major drawback: I need to manually include all those required obj files. If the exe gets another .cpp file which results in an obj it might break the test code compilation (when somebody needs this new obj file).
I would really value some different point of view on this topic.
I actually like the impromptu static lib generation very much but have to check whether I can use some msbuild facility to detect changed files to avoid creating this file every time.
