When there were many cases (two digits or more) the "prettier" would
fail to recognize the pretty part leaving the test name unprocessed.
The fix made sure the processing would work correctly, irrespective
of the case number.
Before the fix, for the following input:
TypedSuite/1. # TypeParam = int
case
TypedSuite/10. # TypeParam = char
case
The output would be:
TypedSuite/int.case
TypedSuite/10. # TypeParam = char.case
Now the output will be:
TypedSuite/int.case
TypedSuite/char.case
Before the fix the gtest_discover_tests() function would strip the
user data in test parameters (everything to the right of GetParam())
of spaces. Now the parameters aren't altered in any way.
Fixes#23058
If a test name contains a square bracket (due to parameters) then it
breaks gtest_discovery_test() function in some not-so-predictable
way. That happens due to the special meaning these brackets have in
the CMake language and they can't be escaped universally.
So the following treatment has been implemented:
* Every occurrence of ('[' | ']') in a test name gets replaced with
the corresponding placeholder ("__osb_*" | "__csb_*") before the
Google Test output processing and gets replaced back before adding
a new test to CTest, keeping the original test name intact in the
CTest output.
The placeholders are chosen that way to minimize the chance of
clashing with something in the user tests but even if the default
ones would clash with something then they are enhanced to not clash
with anything (hence "_*" at the placeholder's end).
* The GTest output gets searched for the default test name guards
("[=[" | "]=]") and if they are found a new one gets generated until
the one is found which can safely encompass any test name. The
search is quite simple: find the least amount of '=' which would
allow escaping any test.
* The resulting ${TEST_LIST} variable will contain every test but
tests with square brackets as there is no way to make sure such
tests won't break the list altogether.
Fixes: #23039
The `TEST_FILTER` argument can be used to filter tests during the
discovery phase. It combines `--gtest_filter=<expr>` with the
`--gtest_list_tests` argument when invoking the test excutable for
listing defined tests.
Fixes: #17493
The function gtest_discover_tests calls the passed test executable with
the parameter --gtest_list_tests and parses the output to find all
tests.
In case of value-parameterized tests ([1]), the test values are included
in the output. While test names are alphanumeric, the values can contain
arbitrary content.
First, the output is separated into lines with `foreach`. Included
semi-colons breaks this and need to get escaped.
Afterwards, the testname is passed on to the `add_command` helper. This
helper was converted into a macro in commit dac201442d (GoogleTest:
Optimize gtest_discover_tests, 2020-02-18). As a macro, its arguments
are re-evaluated. Therefore we need to escape `\`, `;` and to prevent
unwanted variable expansion `$`.
Fixes: #20661
[1] <https://github.com/google/googletest/blob/0eea2e9/googletest/docs/advanced.md#value-parameterized-tests>
Add a new gtest_discover_tests function to GoogleTest.cmake,
implementing dynamic test discovery (i.e. tests are discovered by
actually running the test executable and asking for the list of
available tests, which is used to dynamically declare the tests) rather
than the source-parsing approach used by gtest_add_tests. Compared to
the source-parsing approach, this has the advantage of being robust
against users declaring tests in unusual ways, and much better support
for advanced features such as parameterized tests.
A unit test, modeled after the TEST_INCLUDE_DIR[S] test, is also
included. Note that the unit test does not actually require that Google
Test is available. The new functionality does not actually depend on
Google Test as such; it only requires that the test executable lists
tests in the expected format when invoked with --gtest_list_tests, which
the unit test can fake readily.
