summaryrefslogtreecommitdiffstats
path: root/Tests/RunCMake/GoogleTest
Commit message (Collapse)AuthorAgeFilesLines
* GENERATOR_IS_MULTI_CONFIG: Use for multi-config checks in TestsCraig Scott2017-12-291-1/+1
|
* GoogleTest: Add test for missing test executableMatthew Woehlke2017-12-063-0/+10
| | | | | | | 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.)
* GoogleTest: Add timeout to discoveryMatthew Woehlke2017-12-065-0/+43
| | | | | | | | | | 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.)
* GoogleTest: Fix multiple discovery on same targetMatthew Woehlke2017-11-214-3/+42
| | | | | | | | | | | | | 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 dynamic test discovery for for Google TestMatthew Woehlke2017-07-275-0/+110
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.