In practice there was the need for passing arbitrary arguments to the test executalbe run target. To meet these needs I want to allow the user more control over the generated run targets.
I imagine something like:
cpfAddCppPackage(
...
ADD_RUN_TESTS_TARGET
NAME run_MyAppTests
ARGS --TestDir "bla" --gtest_filter=*
ADD_RUN_TESTS_TARGET
NAME run_MyAppFastTests
ARGS --TestDir "bla" --gtest_filter=*FastTests*
...
)
This would replace the current TEST_EXE_ARGUMENTS and CPF_ENABLE_RUN_TESTS_TARGET options.
This removes the need for the hardcoded fast tests target and with it the need for knowing specifics about the test executable. Maybe we should also add a global default setting like it is done with other options.
The command line arguments should also be set as debuggin arguments in Visual Studio and within a generated GoogleTestAdapter option file.
The arguments must also be passed to the dynamic code analysis targets.
In practice there was the need for passing arbitrary arguments to the test executalbe run target. To meet these needs I want to allow the user more control over the generated run targets.
I imagine something like:
This would replace the current
TEST_EXE_ARGUMENTS
andCPF_ENABLE_RUN_TESTS_TARGET
options.This removes the need for the hardcoded fast tests target and with it the need for knowing specifics about the test executable. Maybe we should also add a global default setting like it is done with other options.
The command line arguments should also be set as debuggin arguments in Visual Studio and within a generated GoogleTestAdapter option file.
The arguments must also be passed to the dynamic code analysis targets.