Discovery timeout test needs split out into two components:
- build
- test
Building the project should result in a failure due to the timeout
when executing gtest discovery as a post build step.
Likewise, if you ran CTest after this build failure,
we should *also* detect that the discovery_timeout_test has not been built
because no discovery_timeout_test[1]_tests.cmake has been created
due to the test discovery failure (caused by the timeout).
Run the `clang-format.bash` script to update all our C and C++ code to a
new style defined by `.clang-format`. Use `clang-format` version 6.0.
* If you reached this commit for a line in `git blame`, re-run the blame
operation starting at the parent of this commit to see older history
for the content.
* See the parent commit for instructions to rebase a change across this
style transition commit.
In gtest_discover_tests(), the TIMEOUT keyword was making it
impossible to set the TIMEOUT test property via the PROPERTIES
keyword. This would be a frequent case, but it doesn't complain
and instead silently does something different to what would
normally be expected. The TIMEOUT keyword has been renamed
to DISCOVERY_TIMEOUT, thereby removing the clash.
This is a breaking change. 3.10.1 and 3.10.2 were the only versions
that supported the TIMEOUT keyword and uses of it were likely
not working as intended.
Fixes: #17801
Add a test to verify expected behavior when a test executable on which
gtest_discover_tests is invoked was not built. (The test for the newly
added timeout conveniently sets up this situation, so this new test was
almost trivial to add.)
Add a TIMEOUT option to gtest_discover_tests. This provides a
work-around in case a test goes out to lunch, rather than causing the
build to simply hang. (Although this is still a problem with the user's
project, hanging the build is not cool, especially in the case of
automatically running CI builds. It is much preferred that the build
should actively fail in this case, and it is trivially easy for us to
implement that.)
According to the documentation, tests can be discovered for a target
multiple times by using a different prefix and/or suffix to ensure name
uniqueness. However, while this worked for gtest_add_tests, it did not
work with gtest_discover_tests because the generated file that sets up
the tests was named based only on the target name, and so subsequent
discovery from the same target would clobber earlier discovery.
Fix this by introducing a counter that records how many times discovery
has been used on a target, and use this to generate unique names of the
generated test list files.
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.
