# Google Test

[Google Test](https://github.com/google/googletest) and [Google Mock](https://github.com/google/googlemock) 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.

## Google Test basics

If you are not familiar with Google Test, you can find a description of its main concepts below:

### Assertions

In Google Test, the statements that check whether a condition is true are referred to as [assertions](https://github.com/google/googletest/blob/master/docs/primer.md#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:

```CPLUSPLUS
TEST (SquareTest /*test suite name*/, PosZeroNeg /*test name*/) {
EXPECT_EQ (9.0, (3.0*2.0)); // fail, test continues
ASSERT_EQ (0.0, (0.0));     // success
ASSERT_EQ (9, (3)*(-3.0));  // fail, test interrupts
ASSERT_EQ (-9, (-3)*(-3.0));// not executed due to the previous assert
}
```

Some of the asserts available in Google Test are listed below (in this table, `ASSERT_` is given as an example and can be switched with `EXPECT_`):

| Logical |     `ASSERT_TRUE(condition)`       `ASSERT_FALSE(condition)`     |
| General comparison |     `ASSERT_EQ(expected, actual) / ASSERT_NE(val1, val2)`       `ASSERT_LT(val1, val2) / ASSERT_LE(val1, val2)`       `ASSERT_GT(val1, val2) / ASSERT_GE(val1, val2)`     |
| Float point comparison |     `ASSERT_FLOAT_EQ(expected, actual)`       `ASSERT_DOUBLE_EQ(expected, actual)`       `ASSERT_NEAR(val1, val2, abs_error)`     |
| String comparison |     `ASSERT_STREQ(expected_str, actual_str) / ASSERT_STRNE(str1, str2)`       `ASSERT_STRCASEEQ(expected_str, actual_str) / ASSERT_STRCASENE(str1, str2)`     |
| Exception checking |     `ASSERT_THROW(statement, exception_type)`       `ASSERT_ANY_THROW(statement)`       `ASSERT_NO_THROW(statement)`     |

Also, Google Test supports [predicate assertions](https://github.com/google/googletest/blob/master/docs/advanced.md#predicate-assertions-for-better-error-messages) 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:

|    Predicate assertion example      ```CPLUSPLUS bool IsEq(int a, int b){ if (a==b) return true; else return false; }  TEST(BasicChecks, TestEq) { int a = 0; int b = 1; EXPECT_EQ(a, b); EXPECT_PRED2(IsEq, a, b); } ```    |    Output      ```CONSOLE Failure Value of: b Actual: 1 Expected: a Which is: 0  Failure IsEq(a, b) evaluates to false, where a evaluates to 0 b evaluates to 1 ```    |

In `EXPECT_PRED2` above, predN is a predicate function with N arguments. Google Test currently supports predicate assertions of arity up to 5.

### Fixtures

Google tests that share common objects or subroutines can be grouped into fixtures. Here is how a generalized fixture looks like:

```CPLUSPLUS
class myTestFixture: public ::testing::test {
public:
myTestFixture( ) {
// initialization;
// can also be done in SetUp()
}

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
}

// shared user data
};
```

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:

```CPLUSPLUS
TEST_F( myTestFixture, TestName) {/*...*/}
```

For more information about Google Test, explore the [samples](https://github.com/google/googletest/blob/master/docs/samples.md) in the framework's repository. Also, for more information about other noticeable Google Test features such as [value-parametrized tests](https://github.com/google/googletest/blob/master/docs/advanced.md#value-parameterized-tests) and [type-parameterized tests](https://github.com/google/googletest/blob/master/docs/advanced.md#type-parameterized-tests), refer to [Advanced options](https://github.com/google/googletest/blob/master/docs/advanced.md#advanced-googletest-topics).

## Adding Google Test to your project

Procedure:

1. Download Google Test from the official [repository](https://github.com/google/googletest) and extract the contents of googletest-main into an empty folder in your project (for example, `Google_tests/lib`).

Alternatively, clone Google Test as a [git submodule](https://git-scm.com/book/en/v2/Git-Tools-Submodules) or  [use CMake to download](https://github.com/google/googletest/tree/master/googletest#incorporating-into-an-existing-cmake-project) it (instructions below will not be applicable in the latter case).

2. Create a `CMakeLists.txt` file inside the Google_tests folder: right-click it in the project tree and select `New | CMakeLists.txt`.

Customize the following lines and add them into your script:

```CMAKE
# 'Google_test' is the subproject name
project(Google_tests)

# 'lib' is the folder with Google Test sources
add_subdirectory(lib)
include_directories(${gtest_SOURCE_DIR}/include ${gtest_SOURCE_DIR})

# 'Google_Tests_run' is the target name
# 'test1.cpp test2.cpp' are source files with tests
add_executable(Google_Tests_run test1.cpp test2.cpp)
target_link_libraries(Google_Tests_run gtest gtest_main)
```

3. In your root `CMakeLists.txt` script, add the `add_subdirectory(Google_tests)` command to the end, then reload the project.

When writing tests, make sure to add `#include "gtest/gtest.h"` at the beginning of every `.cpp` file with your tests code.

> **Tip:**
> Take a look at this [example](unit-testing-tutorial.html#adding-framework) in Unit Testing Tutorial.

## 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](#test-runner), which is unavailable if you run tests as regular programs.

> **Note:**
> CLion automatically creates a Google Test configuration for every CMake target linked with `gtest` or `gmock`.

Procedure:

1. To create a Google Test configuration, go to Run | Edit Configurations in the main menu, click ![](https://resources.jetbrains.com/help/img/idea/2026.2/app.expui.general.add.svg) and select Google Test from the list of templates.

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:

![Completion in configuration fields](https://resources.jetbrains.com/help/img/idea/2026.2/cl_googletest_config_completion.png)

Set wildcards to specify test patterns, for example:

![Pattern for tests](https://resources.jetbrains.com/help/img/idea/2026.2/cl_googletest_config_pattern.png)

> **Tip:**
> The Pattern control uses [gtest-filter](https://github.com/google/googletest/blob/master/docs/advanced.md#running-a-subset-of-the-tests) 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:

![Test flags in program arguments](https://resources.jetbrains.com/help/img/idea/2026.2/cl_UTtutorial_configs_flags.png)

The output will look as follows:

```CONSOLE
Repeating all tests (iteration 1) ...
Repeating all tests (iteration 2) ...
Repeating all tests (iteration 3) ...
```

4. Save the configuration, and it's ready for Run![](https://resources.jetbrains.com/help/img/idea/2026.2/app.actions.execute.svg) or Debug![](https://resources.jetbrains.com/help/img/idea/2026.2/app.actions.startDebugger.svg).

> **Note:**
> 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](performing-tests.html) 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 for tests](https://resources.jetbrains.com/help/img/idea/2026.2/cl_UTtutorial_guttericons.png)

Gutter icons also show test results (when already available): success ![](https://resources.jetbrains.com/help/img/idea/2026.2/app.runConfigurations.testState.green2.svg) or failure ![](https://resources.jetbrains.com/help/img/idea/2026.2/app.runConfigurations.testState.red2.svg).

When you run a test/suite/fixture using gutter icons, CLion creates a [temporary](run-debug-configuration.html) 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 ![](https://resources.jetbrains.com/help/img/idea/2026.2/app.expui.general.save.svg).

![Saving temporary test configuration](https://resources.jetbrains.com/help/img/idea/2026.2/cl_UTturorial_temporaryconfigs_save.png)

## Exploring results

When you run tests, the results (and the process) are shown in the test runner window. This window includes:

* progress bar with the percentage of tests executed so far,

* tree view of all the running tests with their status and duration,

* tests' output stream,

* toolbar with the options to rerun failed ![](https://resources.jetbrains.com/help/img/idea/2026.2/app.runConfigurations.testState.red2.svg) tests, export ![](https://resources.jetbrains.com/help/img/idea/2026.2/app.expui.general.export.svg) or open previous results saved automatically ![](https://resources.jetbrains.com/help/img/idea/2026.2/app.vcs.history.svg), sort the tests alphabetically ![](https://resources.jetbrains.com/help/img/idea/2026.2/app.objectBrowser.sorted.svg) to easily find a particular test, or sort them by duration ![](https://resources.jetbrains.com/help/img/idea/2026.2/app.runConfigurations.sortbyDuration.svg) 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.

![Test runner for Google tests](https://resources.jetbrains.com/help/img/idea/2026.2/cl_googletest_runner.png)

## 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.

> **Note:**
> 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:

```CPLUSPLUS
TEST(Foo, Bar) {
    //...
    if (condition)
        GTEST_SKIP_("message"); // or GTEST_SKIP() with no message
    //...
}
```

Use the Show ignored ![](https://resources.jetbrains.com/help/img/idea/2026.2/app.runConfigurations.showIgnored.svg) icon to view/hide skipped tests in the Test Runner tree:

![Skipped test in the Test Runner tab](https://resources.jetbrains.com/help/img/idea/2026.2/cl_google_test_skip.png)

## See also

### Getting Started

[Unit testing tutorial](unit-testing-tutorial.html) [Quick CMake tutorial](quick-cmake-tutorial.html)

### Procedures

[Run, debug, terminate tests](performing-tests.html) [Explore test results](viewing-and-exploring-test-results.html)