Google Test

Google Test basics

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:

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 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 `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 `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`

Predicate assertion example

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

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.

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

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:

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

Adding Google Test to your project

Download Google Test from the official repository 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 or use CMake to download it (instructions below will not be applicable in the latter case).

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:

# '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)

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.

In the files with gtest included, you can generate code for tests and test fixtures using the Generate menu .

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.

To create a Google Test configuration, go to Run | Edit Configurations in the main menu, click and select Google Test from the list of templates.
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:
Set wildcards to specify test patterns, for example:
tip
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.
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:
```
Repeating all tests (iteration 1) ...
Repeating all tests (iteration 2) ...
Repeating all tests (iteration 3) ...
```
Save the configuration, and it's ready for Run or Debug.

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

Exploring results

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.

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
    //...
}

See also

Procedures

Getting Started

Google Test﻿

Google Test basics﻿

Assertions﻿

Fixtures﻿

Adding Google Test to your project﻿

tip

Generate menu for Google Test﻿

Google Test run/debug configuration﻿

note

tip

note

Running tests﻿

Exploring results﻿

Skipping tests at runtime﻿

note

See also

Procedures

Getting Started

Google Test

Google Test basics

Assertions

Fixtures

Adding Google Test to your project

Generate menu for Google Test

Google Test run/debug configuration

Running tests

Exploring results

Skipping tests at runtime