A problem has been identified in Qt Creator that causes running or debugging targets to always use the launcher defined with CMAKE_TEST_LAUNCHER, see https://bugreports.qt.io/browse/QTCREATORBUG-32550.
The current workaround is to check the CTestTestfile.cmake file generated in the top-level build directory to see if a test exists for a specific target and, if not, not to use the launcher for that target, see https://codereview.qt-project.org/c/qt-creator/qt-creator/+/676306
Since CTestTestfile.cmake files can also be contained in subdirectories, this solution seems incomplete, and the question is whether there is a better way to achieve this via the cmake file api.
Information about tests can’t be provided via the CMake file API. The set of tests may not be known until after a build completes. For example, the gtest_discover_tests() command from the GoogleTest module runs the executable to ask it what test it defines. This can happen at build time or be delayed as late as when tests are run.
Because of the above, the only way you can reliably get information about tests is to run ctest. You can use the --dry-run option to at least query the set of tests without running them, but note that may still run executables to ask them to enumerate the tests they provide.
The question was not about what tests are combined in one binary. The question was what built executables are used in an add_test(). And this is also the scope of the test launcher that this question is about.