Professional Documents
Culture Documents
Google Test
Last modified: 16 April 2024
Google Test ↗ and Google Mock ↗ are a pair of powerful unit testing tools: the framework is
portable, it includes a rich set of fatal and non-fatal assertions, provides instruments for
creating fixtures and test groups, gives informative messages, and exports the results in
XML. Probably the only drawback is a need to build gtest/gmock in your project in order to
use it.
Assertions
In Google Test, the statements that check whether a condition is true are referred to as
assertions ↗. Non-fatal assertions have the EXPECT_ prefix in their names, and assertions
that cause fatal failure and abort the execution are named starting with ASSERT_ . For
example:
Logical ASSERT_TRUE(condition)
ASSERT_FALSE(condition)
ASSERT_DOUBLE_EQ(expected, actual)
ASSERT_STRCASEEQ(expected_str, actual_str) /
ASSERT_STRCASENE(str1, str2)
ASSERT_ANY_THROW(statement)
ASSERT_NO_THROW(statement)
Also, Google Test supports predicate assertions ↗ which help make output messages more
informative. For example, instead of EXPECT_EQ(a, b) you can use a predicate function that
checks a and b for equivalency and returns a boolean result. In case of failure, the
assertion will print values of the function arguments:
Fixtures
Google tests that share common objects or subroutines can be grouped into fixtures. Here is
how a generalized fixture looks like:
void SetUp( ) {
// initialization or some code to run before each test
}
void TearDown( ) {
// code to run after each test;
// can be used instead of a destructor,
// but exceptions can be handled in this function only
}
~myTestFixture( ) {
//resources cleanup, no exceptions allowed
}
When used for a fixture, a TEST() macro should be replaced with TEST_F() to allow the
test to access the fixture's members and functions:
For more information about Google Test, explore the samples ↗ in the framework's
repository. Also, for more information about other noticeable Google Test features such as
value-parametrized tests ↗ and type-parameterized tests ↗, refer to Advanced options ↗.
Customize the following lines and add them into your script:
When writing tests, make sure to add #include "gtest/gtest.h" at the beginning of every
.cpp file with your tests code.
When called from a fixture, this menu additionally includes SetUp Method and TearDown
Method:
Google Test run/debug configuration
Although Google Test provides the main() entry, and you can run tests as regular
applications, we recommend using the dedicated Google Test run/debug configuration. It
includes test-related settings and let you benefit from the built-in test runner, which is
unavailable if you run tests as regular programs.
CLion automatically creates a Google Test configuration for every CMake target
linked with gtest or gmock .
2. Specify the test or suite to be included in the configuration, or provide a pattern for
filtering test names. Auto-completion is available in the fields to help you quickly fill
them up:
The Pattern control uses gtest-filter ↗ under the hood. For example, if you
specify Abs* as shown above, CLion will add the --gtest_filter=Abs*
flag.
3. In other fields of the configuration settings, you can set environment variables and
command line options. For example, use Program arguments field to pass the --
gtest_repeat flag and run a Google test multiple times:
The output will look as follows:
Instead of editing a single configuration, you can modify the Google Test
template itself. In this case, the settings you specify will apply as defaults to all
new configurations of this type.
Running tests
In CLion, there are several ways to start a run/debug session for tests, one of which is using
special gutter icons. These icons help quickly run or debug a single test or a whole
suite/fixture:
Gutter icons also show test results (when already available): success or failure .
When you run a test/suite/fixture using gutter icons, CLion creates a temporary Google Test
configuration, which is greyed out in the list of configurations. To save a temporary
configuration, select it in the Edit Configurations dialog and press .
Exploring results
When you run tests, the results (and the process) are shown in the test runner window. This
window includes:
• tree view of all the running tests with their status and duration,
• toolbar with the options to rerun failed tests, export or open previous results saved
automatically , sort the tests alphabetically to easily find a particular test, or sort them
by duration to understand which test ran longer than others.
Test tree shows all the tests while they are being executed one by one. For parameterized
tests, you will see the parameters in the tree as well. Also, the tree includes disabled tests
(those with the DISABLED prefix in their names) and marks them as skipped with the
corresponding icon.
Skipping tests at runtime
You can configure some tests to be skipped based on a condition evaluated at runtime. For
this, use the GTEST_SKIP() macro.
Google Test supports this feature starting from the version 1.10.0, so make sure to
update the framework's sources in your project.
Add the conditional statement and the GTEST_SKIP() macro to the test you want to skip:
TEST(Foo, Bar) {
//...
if (condition)
GTEST_SKIP_("message"); // or GTEST_SKIP() with no message
//...
}
Use the Show ignored icon to view/hide skipped tests in the Test Runner tree: