Visual studio extension that adds support for the C++ testing framework Google Test.
As you might have noticed, this project is not maintained any more (I have moved to different technologies and are not even working as a developer any more). Since it still has a few features which the MS clone (which is still developed and delivered with Visual Studio) does not support, there still seems to be some interest in the project. Thus, if anybody wants to take over this project, please get in touch - I will certainly try to get you up and running!
Google Test Adapter (GTA) is a Visual Studio extension providing test discovery and execution of C++ tests written with the Google Test framework.
VSTest.Console.exe
Google Test Adapter can be installed in three ways:
After restarting VS, your tests will be displayed in the Test Explorer at build completion time. If no or not all tests show up, have a look at the trouble shooting section.
Note that due to Microsoft requiring VS extensions to support asynchronous package loading, the last version of Google Test Adapter which supports Visual Studio 2012 is 0.14.4.
GTA provides different ways of configuration:
.sln
file, and must have the same name as that file, but with extension .gta.runsettings
. E.g., if the solution file's name is Foo.sln
, the settings file must be named Foo.gta.runsettings
.VsTest.Console.exe
via the /Settings
parameter.GTA_FALLBACK_SETTINGS
. The settings file referred to from that environment variable will be used only if GTA fails to receive settings from the VS test framework; currently, this is only known to happen when running GTA through VsTest.Console.exe
on VS 2017 V15.5 and later (see #184).The format of solution and user settings files is the same: a <GoogleTestAdapterSettings>
node contains the solution settings and the (possibly empty) set of project settings and is itself contained in a <RunSettings>
node (which in the case of user settings files might contain additional, e.g. VS specific settings). In contrast to solution settings, each set of project settings additionally has a regular expression to be evaluated at test discovery and execution time.
The final settings to be used are computed by merging the available settings, vaguely following Visual Studio's approach of configuration inheritance. Merging is done in two stages:
Overall, given a test executable mytests.exe
, the following settings apply to that executable in decreasing priority:
mytests.exe
.mytests.exe
.Note that due to the overriding hierarchy described above, you probably want to provide only a subset of the nodes in your configuration files. For instance, providing the node <DebugMode>true</DebugMode>
in a shared solution settings file will make sure that all sharing developers will run GTA with debug output, no matter what the developer's individual settings at Tools/Options/Google Test Adapter are (and unless the developer has selected a test settings file via VS, which would override the solution setting).
For reference, see a settings file AllTestSettings.gta.runsettings containing all available settings, a more realistic solution settings file SampleTests.gta.runsettings as delivered with the SampleTests solution, and a user settings file NonDeterministic.runsettings as used by GTA's end-to-end tests. The syntax of the GTA settings files (excluding the <RunSettings>
node) is specified by this schema.
GTA does not provide direct access to VS project settings such as Project > Properties > Debugging > Environment. Additionally, when run as NuGet dependency, GTA does not have access to information such as solution dir or Platform/Configuration a test executable has been built with.
To overcome these problems, GTA supports so-called settings helper files which provide that information to GTA. Helper files are usually generated as part of the build, e.g. within a post-build event, which might look like this:
echo SolutionPath=$(SolutionPath)::GTA::SolutionDir=$(SolutionDir)::GTA::PlatformName=$(PlatformName)::GTA::ConfigurationName=$(ConfigurationName)::GTA::TheTarget=$(TargetFileName) > $(TargetPath).gta_settings_helper
This command generates a file $(TargetPath).gta_settings_helper
(where $(TargetPath)
is the path of the final test executable) containing key/value pairs separated by ::GTA::
. At file generation time, the VS macros will be replaced by the actual values, which can then in turn be used as placeholders within the GTA settings. In particular, the helper file generated by the above command will
$(SolutionDir)
, $(PlatformName)
, and $(ConfigurationName)
placeholders will be available even if the runtime environment does not provide them (CI) and$(TargetFileName)
macro to GTA, where it can be referred to as the $(TheTarget)
placeholderNote that the settings helper files need to be located within the same folder as their corresponding test executable, and must have the test executable's name concatenated with the .gta_settings_helper
ending (make sure to ignore these files in version control if necessary).
GTA has full support for traits, which can be assigned to tests in two ways:
<Google Test macro>_TRAITS
, where, obviously, <Google Test macro>
is the name of the according macro in Google Test. Each test can be assigned up to 8 traits.More precisely, traits are assigned to tests in three phases:
.*///Size,Medium
assigns the trait (Size,Medium) to all tests.TEST_P_TRAITS(ParameterizedTests, SimpleTraits, Size, Small)
will make sure that all test instances of test ParameterizedTest.SimpleTraits will be assigned the trait (Size,Small) (and override the Size trait assigned from the first phase)..*\[1.*\]///Size,Large
will make sure that all parameterized tests where the parameter starts with a 1 will be assigned the trait (Size,Large) (and override the traits assigned by phases 1 and 2).Note that traits are assigned in an additive manner within each phase, and in an overriding manner between phases. For instance, if a test is assigned the traits (Author,Foo) and (Author,Bar) in phase 1, the test will have both traits. If the test is also assigned the trait (Author,Baz) in phases 2 or 3, it will only have that trait. See test code for examples.
If option Exit code test case is non-empty, an additional test case will be generated per text executable (referred to as exit code test in the following), and that exit code test will pass if the test executable's exit code is 0. This allows to reflect some additional result as a test case; for instance, the test executable might be built such that it performs memory leak detection at shutdown (see below for example); the result of that check can then be seen within VS as the result of the according additional test.
A couple of tokens can used as part of a test executable's output; if GTA sees theses tokens, it will act accordingly:
GTA_EXIT_CODE_OUTPUT_BEGIN
: This token will make GTA capture the following output and add it to the exit code test as error message.GTA_EXIT_CODE_OUTPUT_END
: This token will stop GTA from adding the following output to the error message. If it is not provided, GTA will capture the complete remaining output as error message of the exit code test.GTA_EXIT_CODE_SKIP
: This token will make the exit code test have outcome Skipped. This can e.g. be useful if a particular check is only perfomed in Debug mode, or to provide a general warning that something has gone wrong without making the exit code test fail.Note that a test executable might be run more than once by GTA (e.g., if tests are run in parallel, or if the selection of tests to be run results in command lines too long for a single test run). In this case, the exit codes and respective outputs of a test exectutable are aggregated as follows:
An example usage of the Exit code test case can be found as part of the SampleTests solution: Project MemoryLeakTests makes use of MS' memory leak detection facilities and reports the results to VS via an exit code test. The approach can easily be re-used for other Google Test projects:
gta_leak_detection.h
and gta_leak_detection.cpp
to the projectmain
method, return the result of gta_leak_detection::PerformLeakDetection(argc, argv, RUN_ALL_TESTS())
(instead of the result of RUN_ALL_TESTS()
, see example)<ExitCodeTestCase>MemoryLeakTest</ExitCodeTestCase>
(enables evaluation of the executable's exit code; feel free to choose another name)<AdditionalTestExecutionParam>-is_run_by_gta</AdditionalTestExecutionParam>
(makes sure the test executable is aware of being run by GTA)However, note that Google Test as of V1.8.1 uses some memory allocation which is recognized by MS' leak detection mechanism as a leak (although it isn't), in particular for failing assertions. Some of these "false positives" have been fixed with the linked issue, making leak detection useful as long as all tests are green; however, and until this problem is fixed, the memory leak detection provided by GTA will result in a skipped exit code test in case RUN_ALL_TESTS()
does not return 0
, but will report the leak in the test's error message. If you run into such problems, please report them against the Google Test repository if appropriate.
main()
method of a BarTests project (e.g. by referencing its main.cpp
), the exit code test of FooTests will be grouped under BarTests' executable.VSTest.Console.exe
GTA can be used to run tests from the command line, which can be done making use of VS's VSTest.Console.exe. GTA supports all the tool's command line options, including /UseVsixExtensions
and /TestAdapterPath
.
Note, however, that VSTest.Console.exe will not make use of GTA solution settings (if the solution containing the tests happens to use such settings). All settings to be used by VSTest.Console.exe need to be passed using the /Settings
command line option. Note also that the $(SolutionDir)
placeholder is neither available in the Test setup/teardown batch file options nor in the Additional test execution parameters option.
The tests to be run can be selected via the /TestCaseFilter
option. Filters need to follow the syntax as described in this blog entry. GTA supports the following test properties:
Additionally, traits can be used in test case filters. E.g., all tests having a Duration
of short
can be executed by means of the filter /TestCaseFilter:"Duration=short"
.
Tests are run sequentially by default. If parallel test execution is enabled, the tests will be distributed to the available cores of your machine. To support parallel test execution, additional command line parameters can be passed to the Google Test executables (note that this feature is not restricted to parallel test execution); they can then be parsed by the test code at run time and e.g. be used to improve test isolation.
GTA remembers the durations of the executed tests to improve test scheduling for later test runs. The durations are stored in files with endings .gta.testdurations
- make sure your version control system ignores these files.
Note that since VS 2015 update 1, VS allows for the parallel execution of tests (again); since update 2, Test Explorer has an own Run tests in parallel button, and VsTest.Console.exe suppports a new command line option /Parallel. Neither button nor command line option has any effect on test execution with GTA.
If you need to perform some setup or teardown tasks in addition to the setup/teardown methods of your test code, you can do so by configuring test setup/teardown batch files, to which you can pass several values such as solution directory or test directory for exclusive usage of the tests.
GTA runs in three different environments:
VsTestConsole.exe
(making use of the /UseVsixExtensions:true
or the /TestAdapterPath:<dir>
options)For technical reasons, not all features are available in all environments by default; refer to the table below for details.
Feature | VS/VSIX | VS/NuGet | VsTest.Console |
---|---|---|---|
Test discovery | yes | yes | yes |
Test execution | yes | yes | yes |
Test debugging | yes | no | - |
Configuration via | |||
- VS Options | yes | no | - |
- VS Toolbar | yes | no | - |
- Solution test config file | yes | no | no |
- User test config file | yes1 | yes1 | yes2 |
Placeholders | |||
- $(SolutionDir) |
yes | yes3, 4 | yes3 |
- $(PlatformName) |
yes | yes3 | yes3 |
- $(ConfigurationName) |
yes | yes3 | yes3 |
- $(ExecutableDir) |
yes | yes | yes |
- $(Executable) |
yes | yes | yes |
- $(TestDir) 5 |
yes | yes | yes |
- $(ThreadId) 5 |
yes | yes | yes |
- Additional placeholders | yes3 | yes3 | yes3 |
- Environment variables | yes | yes | yes |
1: Via Test/Test Settings/Select Test Settings File
2: Via /Settings
option
3: If settings helper files are provided
4: During test execution, placeholders are available even without settings helper files
5: Only during test execution; placeholders are removed in discovery mode
--gtest_list_tests
...\FooTests.exe
, make sure that a file ..\FooTests.exe.is_google_test
exists.--gtest_list_tests
. Make sure that your tests can be listed via command line; if they do not, debug your test executable, e.g. by making the according test project the startup project of your solution, and placing a breakpoint at the main method of your test executable. Here are some reasons why your tests might not be listed:
F5
. Make sure that the Output setting of the project is consistent with its makefile to avoid this problem.In general, you can identify issues with your test executables by debugging them within VS: make the according test project the startup project of your solution, add command line arguments as desired, place breakpoints at points of interest and launch your test executable with F5.
Yes
or Optimize for debugging (/DEBUG)
Generate debug information optimized for sharing and publishing (/DEBUG:FULL)
false
, making GTA not parse that information out of the pdb file intentionally. The actual set of options used is potentially composed from VS options, a solution settings file, and a user settings file; the resulting set of options will be logged to the test output window if the Print debug info option is set to true
..pdb
files..is_google_test
file (see above). This will avoid scanning the binary for gtest indications.false
.You might consider using GTA's project settings to switch off symbol parsing and binary scanning for problematic test executables only, thus compromising between speed of test discovery and build maintainability.
Please refer to our wiki.
Google Test Adapter is written and maintained by Christian Soltenborn.
The first version of GTA was a slightly enhanced C# port of the F# Google Test Runner, written by Markus Lindqvist. We have also learned a lot from the JavaScript test runner Chutzpah, written by Matthew Manela.
GTA has benefited from all kinds of contributions, be it feature requests, bug reports, code snippets, testing of new features and bugfixes, or even pull requests: