How to enable tests inside another exe

[shivendra14]

I have an application built on a plugin architecture. https://github.com/shivendra14/unit_test/
I have created a testApp where I configure doc test. I am able to load Test cases in Plugin using LoadLibrary() functionality as explained in examples. However, I don't understand how to load test cases present inside the main App.
https://github.com/shivendra14/unit_test/blob/794bd7e14d767c7f5dcc90030696f144f80f1a1b/testApp/main.cpp#L54

[onqtam]

Hello!

I'm on Linux and it seems the code can't be built on that platform because of Config.hpp - I might try it in a week or two when I get back in front of a Windows machine.

So I have a few notes:

• you call LoadDynamicLib("Plugin"); but it seems to me that you are linking against that "plugin" at build time and you are referencing the SayHello function directly - not by using GetProcAddress. You are also not checking the return status of LoadDynamicLib - I think that is not a plugin at all and that it isn't loaded at runtime, but at program startup time because it was used to link aginst it at build time - in app/CMakeLists.txt you do target_link_libraries(App PRIVATE Plugin) but true plugins aren't linked against - they are discovered and loaded at runtime with code and you can't simply include a header with the API of that plugin and use it. Notice how in doctest nobody links against the plugin target - it is only added as a dependency so it gets built together with the executable_dll_and_plugin target - https://github.com/onqtam/doctest/blob/master/examples/executable_dll_and_plugin/CMakeLists.txt#L19 - that is necessary precisely because there is no call to target_link_libraries(X plugin) - nobody links against the plugin - it is plugged in at runtime by being loaded and discovered by the program.
• in testApp/main.cpp I see that you have factored out some code in RunDocTest. In there you check for context.shouldExit() but it basically has no effect since whatever it returns you will always return from that function the value of res. The if statement with the context.shouldExit() condition isn't meant to be factored out into a function like that - the main idea of that return statement in the then part of the if statement is to exit from the main() function and not continue with the program after running the tests (or doctest query flags) if context.shouldExit() returns true. Currently no matter what context.shouldExit() returns the program will always continue after the call to RunDocTest(context);. Currently there is nothing going on there but eventually there would be.
• you don't need to list the doctest.h header in the list of sources when defining CMake targets (like with add_executable)
• you dont need such calls: target_include_directories(XXX PUBLIC "${CMAKE_CURRENT_SOURCE_DIR}/../shared/doctest") (except for in lib/CMakeLists.txt) because when someone links against DocTestLib they will automatically get the public include directory you have setup in lib/CMakeLists.txt. Make sure to look at how modern CMake works in terms of being more target-oriented with transivite public/interface/private properties.
• you could define DOCTEST_CONFIG_IMPLEMENTATION_IN_DLL through CMake so you don't have to write it everywhere before including it in the source. You could also make it a PUBLIC or INTERFACE definition of DocTestLib so whenever something links against it the config identifier would be automatically defined as well - just like with the public include directories setup for DocTestLib.
• seems to me that there are multiple executables (app/main.cpp and testApp/main.cpp) - so which one is the "main" App? I don't see a way for one executable to load another one and have the tests from there registered as well. Perhaps it could be done with some magic platform-specific API calls but you would be better off factoring all functionality and tests in .dll libraries and link against those .dll files from the executables. You could also have tests in the executables but then those tests will be available only for the executable they are written in.

Does this all help?

[onqtam]

I'm closing this due to inactivity