# Googletest Primer
-
## Introduction: Why googletest?
*googletest* helps you write better C++ tests.
-googletest is a testing framework developed by the Testing
-Technology team with Google's specific
-requirements and constraints in mind. No matter whether you work on Linux,
-Windows, or a Mac, if you write C++ code, googletest can help you. And it
+googletest is a testing framework developed by the Testing Technology team with
+Google's specific requirements and constraints in mind. Whether you work on
+Linux, Windows, or a Mac, if you write C++ code, googletest can help you. And it
supports *any* kind of tests, not just unit tests.
So what makes a good test, and how does googletest fit in? We believe:
that succeeds or fails as a result of other tests. googletest isolates the
tests by running each of them on a different object. When a test fails,
googletest allows you to run it in isolation for quick debugging.
-1. Tests should be well *organized* and reflect the structure of the tested
- code. googletest groups related tests into test cases that can share data
+2. Tests should be well *organized* and reflect the structure of the tested
+ code. googletest groups related tests into test suites that can share data
and subroutines. This common pattern is easy to recognize and makes tests
easy to maintain. Such consistency is especially helpful when people switch
projects and start to work on a new code base.
-1. Tests should be *portable* and *reusable*. Google has a lot of code that is
- platform-neutral, its tests should also be platform-neutral. googletest
- works on different OSes, with different compilers (gcc, icc, and MSVC), with
- or without exceptions, so googletest tests can easily work with a variety of
- configurations.
-1. When tests fail, they should provide as much *information* about the problem
+3. Tests should be *portable* and *reusable*. Google has a lot of code that is
+ platform-neutral; its tests should also be platform-neutral. googletest
+ works on different OSes, with different compilers, with or without
+ exceptions, so googletest tests can work with a variety of configurations.
+4. When tests fail, they should provide as much *information* about the problem
as possible. googletest doesn't stop at the first test failure. Instead, it
only stops the current test and continues with the next. You can also set up
tests that report non-fatal failures after which the current test continues.
Thus, you can detect and fix multiple bugs in a single run-edit-compile
cycle.
-1. The testing framework should liberate test writers from housekeeping chores
+5. The testing framework should liberate test writers from housekeeping chores
and let them focus on the test *content*. googletest automatically keeps
track of all tests defined, and doesn't require the user to enumerate them
in order to run them.
-1. Tests should be *fast*. With googletest, you can reuse shared resources
+6. Tests should be *fast*. With googletest, you can reuse shared resources
across tests and pay for the set-up/tear-down only once, without making
tests depend on each other.
## Beware of the nomenclature
-_Note:_ There might be some confusion of idea due to different
-definitions of the terms _Test_, _Test Case_ and _Test Suite_, so beware
-of misunderstanding these.
+{: .callout .note}
+_Note:_ There might be some confusion arising from different definitions of the
+terms _Test_, _Test Case_ and _Test Suite_, so beware of misunderstanding these.
Historically, googletest started to use the term _Test Case_ for grouping
-related tests, whereas current publications including the International Software
-Testing Qualifications Board ([ISTQB](http://www.istqb.org/)) and various
-textbooks on Software Quality use the term _[Test
-Suite](http://glossary.istqb.org/search/test%20suite)_ for this.
+related tests, whereas current publications, including International Software
+Testing Qualifications Board ([ISTQB](http://www.istqb.org/)) materials and
+various textbooks on software quality, use the term
+_[Test Suite][istqb test suite]_ for this.
+
+The related term _Test_, as it is used in googletest, corresponds to the term
+_[Test Case][istqb test case]_ of ISTQB and others.
+
+The term _Test_ is commonly of broad enough sense, including ISTQB's definition
+of _Test Case_, so it's not much of a problem here. But the term _Test Case_ as
+was used in Google Test is of contradictory sense and thus confusing.
+
+googletest recently started replacing the term _Test Case_ with _Test Suite_.
+The preferred API is *TestSuite*. The older TestCase API is being slowly
+deprecated and refactored away.
-The related term _Test_, as it is used in the googletest, is corresponding to
-the term _[Test Case](http://glossary.istqb.org/search/test%20case)_ of ISTQB
-and others.
+So please be aware of the different definitions of the terms:
-The term _Test_ is commonly of broad enough sense, including ISTQB's
-definition of _Test Case_, so it's not much of a problem here. But the
-term _Test Case_ as used in Google Test is of contradictory sense and thus confusing.
-Unfortunately replacing the term _Test Case_ by _Test Suite_ throughout the
-googletest is not easy without breaking dependent projects, as `TestCase` is
-part of the public API at various places.
+Meaning | googletest Term | [ISTQB](http://www.istqb.org/) Term
+:----------------------------------------------------------------------------------- | :---------------------- | :----------------------------------
+Exercise a particular program path with specific input values and verify the results | [TEST()](#simple-tests) | [Test Case][istqb test case]
-So for the time being, please be aware of the different definitions of
-the terms:
-Meaning | googletest Term | [ISTQB](http://www.istqb.org/) Term
-:----------------------------------------------------------------------------------- | :--------------------------------------------------------------------------------------------------------- | :----------------------------------
-Exercise a particular program path with specific input values and verify the results | [TEST()](#simple-tests) | [Test Case](http://glossary.istqb.org/search/test%20case)
-A set of several tests related to one component | [TestCase](#basic-concepts) | [TestSuite](http://glossary.istqb.org/search/test%20suite)
+[istqb test case]: http://glossary.istqb.org/en/search/test%20case
+[istqb test suite]: http://glossary.istqb.org/en/search/test%20suite
## Basic Concepts
*Tests* use assertions to verify the tested code's behavior. If a test crashes
or has a failed assertion, then it *fails*; otherwise it *succeeds*.
-A *test case* contains one or many tests. You should group your tests into test
-cases that reflect the structure of the tested code. When multiple tests in a
-test case need to share common objects and subroutines, you can put them into a
+A *test suite* contains one or many tests. You should group your tests into test
+suites that reflect the structure of the tested code. When multiple tests in a
+test suite need to share common objects and subroutines, you can put them into a
*test fixture* class.
-A *test program* can contain multiple test cases.
+A *test program* can contain multiple test suites.
We'll now explain how to write a test program, starting at the individual
-assertion level and building up to tests and test cases.
+assertion level and building up to tests and test suites.
## Assertions
this in mind if you get a heap checker error in addition to assertion errors.
To provide a custom failure message, simply stream it into the macro using the
-`<<` operator, or a sequence of such operators. An example:
+`<<` operator or a sequence of such operators. See the following example, using
+the [`ASSERT_EQ` and `EXPECT_EQ`](reference/assertions.md#EXPECT_EQ) macros to
+verify value equality:
```c++
ASSERT_EQ(x.size(), y.size()) << "Vectors x and y are of unequal length";
(`wchar_t*`, `TCHAR*` in `UNICODE` mode on Windows, or `std::wstring`) is
streamed to an assertion, it will be translated to UTF-8 when printed.
-### Basic Assertions
-
-These assertions do basic true/false condition testing.
-
-Fatal assertion | Nonfatal assertion | Verifies
--------------------------- | -------------------------- | --------------------
-`ASSERT_TRUE(condition);` | `EXPECT_TRUE(condition);` | `condition` is true
-`ASSERT_FALSE(condition);` | `EXPECT_FALSE(condition);` | `condition` is false
-
-Remember, when they fail, `ASSERT_*` yields a fatal failure and returns from the
-current function, while `EXPECT_*` yields a nonfatal failure, allowing the
-function to continue running. In either case, an assertion failure means its
-containing test fails.
-
-**Availability**: Linux, Windows, Mac.
-
-### Binary Comparison
-
-This section describes assertions that compare two values.
-
-Fatal assertion | Nonfatal assertion | Verifies
------------------------- | ------------------------ | --------------
-`ASSERT_EQ(val1, val2);` | `EXPECT_EQ(val1, val2);` | `val1 == val2`
-`ASSERT_NE(val1, val2);` | `EXPECT_NE(val1, val2);` | `val1 != val2`
-`ASSERT_LT(val1, val2);` | `EXPECT_LT(val1, val2);` | `val1 < val2`
-`ASSERT_LE(val1, val2);` | `EXPECT_LE(val1, val2);` | `val1 <= val2`
-`ASSERT_GT(val1, val2);` | `EXPECT_GT(val1, val2);` | `val1 > val2`
-`ASSERT_GE(val1, val2);` | `EXPECT_GE(val1, val2);` | `val1 >= val2`
-
-Value arguments must be comparable by the assertion's comparison operator or
-you'll get a compiler error. We used to require the arguments to support the
-`<<` operator for streaming to an `ostream`, but it's no longer necessary. If
-`<<` is supported, it will be called to print the arguments when the assertion
-fails; otherwise googletest will attempt to print them in the best way it can.
-For more details and how to customize the printing of the arguments, see
-gMock [recipe](../../googlemock/docs/CookBook.md#teaching-google-mock-how-to-print-your-values).).
-
-These assertions can work with a user-defined type, but only if you define the
-corresponding comparison operator (e.g. `==`, `<`, etc). Since this is
-discouraged by the Google [C++ Style
-Guide](https://google.github.io/styleguide/cppguide.html#Operator_Overloading),
-you may need to use `ASSERT_TRUE()` or `EXPECT_TRUE()` to assert the equality of
-two objects of a user-defined type.
-
-However, when possible, `ASSERT_EQ(actual, expected)` is preferred to
-`ASSERT_TRUE(actual == expected)`, since it tells you `actual` and `expected`'s
-values on failure.
-
-Arguments are always evaluated exactly once. Therefore, it's OK for the
-arguments to have side effects. However, as with any ordinary C/C++ function,
-the arguments' evaluation order is undefined (i.e. the compiler is free to
-choose any order) and your code should not depend on any particular argument
-evaluation order.
-
-`ASSERT_EQ()` does pointer equality on pointers. If used on two C strings, it
-tests if they are in the same memory location, not if they have the same value.
-Therefore, if you want to compare C strings (e.g. `const char*`) by value, use
-`ASSERT_STREQ()`, which will be described later on. In particular, to assert
-that a C string is `NULL`, use `ASSERT_STREQ(c_string, NULL)`. Consider use
-`ASSERT_EQ(c_string, nullptr)` if c++11 is supported. To compare two `string`
-objects, you should use `ASSERT_EQ`.
-
-When doing pointer comparisons use `*_EQ(ptr, nullptr)` and `*_NE(ptr, nullptr)`
-instead of `*_EQ(ptr, NULL)` and `*_NE(ptr, NULL)`. This is because `nullptr` is
-typed while `NULL` is not. See [FAQ](faq.md#why-does-google-test-support-expect_eqnull-ptr-and-assert_eqnull-ptr-but-not-expect_nenull-ptr-and-assert_nenull-ptr)
-for more details.
-
-If you're working with floating point numbers, you may want to use the floating
-point variations of some of these macros in order to avoid problems caused by
-rounding. See [Advanced googletest Topics](advanced.md) for details.
-
-Macros in this section work with both narrow and wide string objects (`string`
-and `wstring`).
-
-**Availability**: Linux, Windows, Mac.
-
-**Historical note**: Before February 2016 `*_EQ` had a convention of calling it
-as `ASSERT_EQ(expected, actual)`, so lots of existing code uses this order. Now
-`*_EQ` treats both parameters in the same way.
-
-### String Comparison
-
-The assertions in this group compare two **C strings**. If you want to compare
-two `string` objects, use `EXPECT_EQ`, `EXPECT_NE`, and etc instead.
-
-| Fatal assertion | Nonfatal assertion | Verifies |
-| ------------------------------- | ------------------------------- | -------------------------------------------------------- |
-| `ASSERT_STREQ(str1, str2);` | `EXPECT_STREQ(str1, str2);` | the two C strings have the same content |
-| `ASSERT_STRNE(str1, str2);` | `EXPECT_STRNE(str1, str2);` | the two C strings have different contents |
-| `ASSERT_STRCASEEQ(str1, str2);` | `EXPECT_STRCASEEQ(str1, str2);` | the two C strings have the same content, ignoring case |
-| `ASSERT_STRCASENE(str1, str2);` | `EXPECT_STRCASENE(str1, str2);` | the two C strings have different contents, ignoring case |
-
-Note that "CASE" in an assertion name means that case is ignored. A `NULL`
-pointer and an empty string are considered *different*.
-
-`*STREQ*` and `*STRNE*` also accept wide C strings (`wchar_t*`). If a comparison
-of two wide strings fails, their values will be printed as UTF-8 narrow strings.
-
-**Availability**: Linux, Windows, Mac.
-
-**See also**: For more string comparison tricks (substring, prefix, suffix, and
-regular expression matching, for example), see
-[this](https://github.com/google/googletest/blob/master/googletest/docs/advanced.md)
-in the Advanced googletest Guide.
+GoogleTest provides a collection of assertions for verifying the behavior of
+your code in various ways. You can check Boolean conditions, compare values
+based on relational operators, verify string values, floating-point values, and
+much more. There are even assertions that enable you to verify more complex
+states by providing custom predicates. For the complete list of assertions
+provided by GoogleTest, see the [Assertions Reference](reference/assertions.md).
## Simple Tests
To create a test:
-1. Use the `TEST()` macro to define and name a test function, These are
+1. Use the `TEST()` macro to define and name a test function. These are
ordinary C++ functions that don't return a value.
-1. In this function, along with any valid C++ statements you want to include,
+2. In this function, along with any valid C++ statements you want to include,
use the various googletest assertions to check values.
-1. The test's result is determined by the assertions; if any assertion in the
+3. The test's result is determined by the assertions; if any assertion in the
test fails (either fatally or non-fatally), or if the test crashes, the
entire test fails. Otherwise, it succeeds.
```c++
-TEST(TestCaseName, TestName) {
+TEST(TestSuiteName, TestName) {
... test body ...
}
```
`TEST()` arguments go from general to specific. The *first* argument is the name
-of the test case, and the *second* argument is the test's name within the test
-case. Both names must be valid C++ identifiers, and they should not contain
-underscore (`_`). A test's *full name* consists of its containing test case and
-its individual name. Tests from different test cases can have the same
+of the test suite, and the *second* argument is the test's name within the test
+suite. Both names must be valid C++ identifiers, and they should not contain
+any underscores (`_`). A test's *full name* consists of its containing test suite and
+its individual name. Tests from different test suites can have the same
individual name.
For example, let's take a simple integer function:
int Factorial(int n); // Returns the factorial of n
```
-A test case for this function might look like:
+A test suite for this function might look like:
```c++
// Tests factorial of 0.
}
```
-googletest groups the test results by test cases, so logically-related tests
-should be in the same test case; in other words, the first argument to their
+googletest groups the test results by test suites, so logically related tests
+should be in the same test suite; in other words, the first argument to their
`TEST()` should be the same. In the above example, we have two tests,
-`HandlesZeroInput` and `HandlesPositiveInput`, that belong to the same test case
-`FactorialTest`.
+`HandlesZeroInput` and `HandlesPositiveInput`, that belong to the same test
+suite `FactorialTest`.
-When naming your test cases and tests, you should follow the same convention as
-for [naming functions and
-classes](https://google.github.io/styleguide/cppguide.html#Function_Names).
+When naming your test suites and tests, you should follow the same convention as
+for
+[naming functions and classes](https://google.github.io/styleguide/cppguide.html#Function_Names).
**Availability**: Linux, Windows, Mac.
-## Test Fixtures: Using the Same Data Configuration for Multiple Tests
+## Test Fixtures: Using the Same Data Configuration for Multiple Tests {#same-data-multiple-tests}
If you find yourself writing two or more tests that operate on similar data, you
-can use a *test fixture*. It allows you to reuse the same configuration of
+can use a *test fixture*. This allows you to reuse the same configuration of
objects for several different tests.
To create a fixture:
-1. Derive a class from `::testing::Test` . Start its body with `protected:` as
+1. Derive a class from `::testing::Test` . Start its body with `protected:`, as
we'll want to access fixture members from sub-classes.
-1. Inside the class, declare any objects you plan to use.
-1. If necessary, write a default constructor or `SetUp()` function to prepare
+2. Inside the class, declare any objects you plan to use.
+3. If necessary, write a default constructor or `SetUp()` function to prepare
the objects for each test. A common mistake is to spell `SetUp()` as
**`Setup()`** with a small `u` - Use `override` in C++11 to make sure you
- spelled it correctly
-1. If necessary, write a destructor or `TearDown()` function to release any
+ spelled it correctly.
+4. If necessary, write a destructor or `TearDown()` function to release any
resources you allocated in `SetUp()` . To learn when you should use the
constructor/destructor and when you should use `SetUp()/TearDown()`, read
- this [FAQ](faq.md#should-i-use-the-constructordestructor-of-the-test-fixture-or-setupteardown) entry.
-1. If needed, define subroutines for your tests to share.
+ the [FAQ](faq.md#CtorVsSetUp).
+5. If needed, define subroutines for your tests to share.
When using a fixture, use `TEST_F()` instead of `TEST()` as it allows you to
access objects and subroutines in the test fixture:
```c++
-TEST_F(TestCaseName, TestName) {
+TEST_F(TestFixtureName, TestName) {
... test body ...
}
```
-Like `TEST()`, the first argument is the test case name, but for `TEST_F()` this
-must be the name of the test fixture class. You've probably guessed: `_F` is for
-fixture.
+Like `TEST()`, the first argument is the test suite name, but for `TEST_F()`
+this must be the name of the test fixture class. You've probably guessed: `_F`
+is for fixture.
Unfortunately, the C++ macro system does not allow us to create a single macro
that can handle both types of tests. Using the wrong macro causes a compiler
`TEST_F()`, or you'll get the compiler error "`virtual outside class
declaration`".
-For each test defined with `TEST_F()` , googletest will create a *fresh* test
-fixture at runtime, immediately initialize it via `SetUp()` , run the test,
-clean up by calling `TearDown()` , and then delete the test fixture. Note that
-different tests in the same test case have different test fixture objects, and
+For each test defined with `TEST_F()`, googletest will create a *fresh* test
+fixture at runtime, immediately initialize it via `SetUp()`, run the test,
+clean up by calling `TearDown()`, and then delete the test fixture. Note that
+different tests in the same test suite have different test fixture objects, and
googletest always deletes a test fixture before it creates the next one.
googletest does **not** reuse the same test fixture for multiple tests. Any
changes one test makes to the fixture do not affect other tests.
to use `EXPECT_*` when you want the test to continue to reveal more errors after
the assertion failure, and use `ASSERT_*` when continuing after failure doesn't
make sense. For example, the second assertion in the `Dequeue` test is
-=ASSERT_NE(nullptr, n)=, as we need to dereference the pointer `n` later, which
+`ASSERT_NE(n, nullptr)`, as we need to dereference the pointer `n` later, which
would lead to a segfault when `n` is `NULL`.
When these tests run, the following happens:
-1. googletest constructs a `QueueTest` object (let's call it `t1` ).
-1. `t1.SetUp()` initializes `t1` .
-1. The first test ( `IsEmptyInitially` ) runs on `t1` .
-1. `t1.TearDown()` cleans up after the test finishes.
-1. `t1` is destructed.
-1. The above steps are repeated on another `QueueTest` object, this time
+1. googletest constructs a `QueueTest` object (let's call it `t1`).
+2. `t1.SetUp()` initializes `t1`.
+3. The first test (`IsEmptyInitially`) runs on `t1`.
+4. `t1.TearDown()` cleans up after the test finishes.
+5. `t1` is destructed.
+6. The above steps are repeated on another `QueueTest` object, this time
running the `DequeueWorks` test.
**Availability**: Linux, Windows, Mac.
-
## Invoking the Tests
`TEST()` and `TEST_F()` implicitly register their tests with googletest. So,
unlike with many other C++ testing frameworks, you don't have to re-list all
your defined tests in order to run them.
-After defining your tests, you can run them with `RUN_ALL_TESTS()` , which
+After defining your tests, you can run them with `RUN_ALL_TESTS()`, which
returns `0` if all the tests are successful, or `1` otherwise. Note that
-`RUN_ALL_TESTS()` runs *all tests* in your link unit -- they can be from
-different test cases, or even different source files.
+`RUN_ALL_TESTS()` runs *all tests* in your link unit--they can be from
+different test suites, or even different source files.
When invoked, the `RUN_ALL_TESTS()` macro:
-1. Saves the state of all googletest flags
+* Saves the state of all googletest flags.
* Creates a test fixture object for the first test.
* Deletes the fixture.
-* Restores the state of all googletest flags
+* Restores the state of all googletest flags.
* Repeats the above steps for the next test, until all tests have run.
If a fatal failure happens the subsequent steps will be skipped.
+{: .callout .important}
> IMPORTANT: You must **not** ignore the return value of `RUN_ALL_TESTS()`, or
> you will get a compiler error. The rationale for this design is that the
> automated testing service determines whether a test has passed based on its
> return the value of `RUN_ALL_TESTS()`.
>
> Also, you should call `RUN_ALL_TESTS()` only **once**. Calling it more than
-> once conflicts with some advanced googletest features (e.g. thread-safe [death
-> tests](advanced#death-tests)) and thus is not supported.
+> once conflicts with some advanced googletest features (e.g., thread-safe
+> [death tests](advanced.md#death-tests)) and thus is not supported.
**Availability**: Linux, Windows, Mac.
## Writing the main() Function
-In `google3`, the simplest approach is to use the default main() function
-provided by linking in `"//testing/base/public:gtest_main"`. If that doesn't
-cover what you need, you should write your own main() function, which should
-return the value of `RUN_ALL_TESTS()`. Link to `"//testing/base/public:gunit"`.
+Most users should _not_ need to write their own `main` function and instead link
+with `gtest_main` (as opposed to with `gtest`), which defines a suitable entry
+point. See the end of this section for details. The remainder of this section
+should only apply when you need to do something custom before the tests run that
+cannot be expressed within the framework of fixtures and test suites.
+
+If you write your own `main` function, it should return the value of
+`RUN_ALL_TESTS()`.
+
You can start from this boilerplate:
```c++
#include "this/package/foo.h"
+
#include "gtest/gtest.h"
+namespace my {
+namespace project {
namespace {
// The fixture for testing class Foo.
class FooTest : public ::testing::Test {
protected:
- // You can remove any or all of the following functions if its body
- // is empty.
+ // You can remove any or all of the following functions if their bodies would
+ // be empty.
FooTest() {
// You can do set-up work for each test here.
// before the destructor).
}
- // Objects declared here can be used by all tests in the test case for Foo.
+ // Class members declared here can be used by all tests in the test suite
+ // for Foo.
};
// Tests that the Foo::Bar() method does Abc.
}
} // namespace
+} // namespace project
+} // namespace my
int main(int argc, char **argv) {
::testing::InitGoogleTest(&argc, argv);
}
```
-
The `::testing::InitGoogleTest()` function parses the command line for
googletest flags, and removes all recognized flags. This allows the user to
control a test program's behavior via various flags, which we'll cover in
-[AdvancedGuide](advanced.md). You **must** call this function before calling
+the [AdvancedGuide](advanced.md). You **must** call this function before calling
`RUN_ALL_TESTS()`, or the flags won't be properly initialized.
On Windows, `InitGoogleTest()` also works with wide strings, so it can be used
in programs compiled in `UNICODE` mode as well.
-But maybe you think that writing all those main() functions is too much work? We
-agree with you completely and that's why Google Test provides a basic
+But maybe you think that writing all those `main` functions is too much work? We
+agree with you completely, and that's why Google Test provides a basic
implementation of main(). If it fits your needs, then just link your test with
-gtest\_main library and you are good to go.
+the `gtest_main` library and you are good to go.
+{: .callout .note}
NOTE: `ParseGUnitFlags()` is deprecated in favor of `InitGoogleTest()`.
-
## Known Limitations
* Google Test is designed to be thread-safe. The implementation is thread-safe
biod.pnpi.spb.ru / alexxy / gromacs.git / blobdiff