3 ## Introduction: Why googletest?
5 *googletest* helps you write better C++ tests.
7 googletest is a testing framework developed by the Testing Technology team with
8 Google's specific requirements and constraints in mind. Whether you work on
9 Linux, Windows, or a Mac, if you write C++ code, googletest can help you. And it
10 supports *any* kind of tests, not just unit tests.
12 So what makes a good test, and how does googletest fit in? We believe:
14 1. Tests should be *independent* and *repeatable*. It's a pain to debug a test
15 that succeeds or fails as a result of other tests. googletest isolates the
16 tests by running each of them on a different object. When a test fails,
17 googletest allows you to run it in isolation for quick debugging.
18 2. Tests should be well *organized* and reflect the structure of the tested
19 code. googletest groups related tests into test suites that can share data
20 and subroutines. This common pattern is easy to recognize and makes tests
21 easy to maintain. Such consistency is especially helpful when people switch
22 projects and start to work on a new code base.
23 3. Tests should be *portable* and *reusable*. Google has a lot of code that is
24 platform-neutral; its tests should also be platform-neutral. googletest
25 works on different OSes, with different compilers, with or without
26 exceptions, so googletest tests can work with a variety of configurations.
27 4. When tests fail, they should provide as much *information* about the problem
28 as possible. googletest doesn't stop at the first test failure. Instead, it
29 only stops the current test and continues with the next. You can also set up
30 tests that report non-fatal failures after which the current test continues.
31 Thus, you can detect and fix multiple bugs in a single run-edit-compile
33 5. The testing framework should liberate test writers from housekeeping chores
34 and let them focus on the test *content*. googletest automatically keeps
35 track of all tests defined, and doesn't require the user to enumerate them
37 6. Tests should be *fast*. With googletest, you can reuse shared resources
38 across tests and pay for the set-up/tear-down only once, without making
39 tests depend on each other.
41 Since googletest is based on the popular xUnit architecture, you'll feel right
42 at home if you've used JUnit or PyUnit before. If not, it will take you about 10
43 minutes to learn the basics and get started. So let's go!
45 ## Beware of the nomenclature
47 _Note:_ There might be some confusion arising from different definitions of the
48 terms _Test_, _Test Case_ and _Test Suite_, so beware of misunderstanding these.
50 Historically, googletest started to use the term _Test Case_ for grouping
51 related tests, whereas current publications, including International Software
52 Testing Qualifications Board ([ISTQB](http://www.istqb.org/)) materials and
53 various textbooks on software quality, use the term
54 _[Test Suite][istqb test suite]_ for this.
56 The related term _Test_, as it is used in googletest, corresponds to the term
57 _[Test Case][istqb test case]_ of ISTQB and others.
59 The term _Test_ is commonly of broad enough sense, including ISTQB's definition
60 of _Test Case_, so it's not much of a problem here. But the term _Test Case_ as
61 was used in Google Test is of contradictory sense and thus confusing.
63 googletest recently started replacing the term _Test Case_ with _Test Suite_.
64 The preferred API is *TestSuite*. The older TestCase API is being slowly
65 deprecated and refactored away.
67 So please be aware of the different definitions of the terms:
69 <!-- mdformat off(github rendering does not support multiline tables) -->
71 Meaning | googletest Term | [ISTQB](http://www.istqb.org/) Term
72 :----------------------------------------------------------------------------------- | :---------------------- | :----------------------------------
73 Exercise a particular program path with specific input values and verify the results | [TEST()](#simple-tests) | [Test Case][istqb test case]
77 [istqb test case]: http://glossary.istqb.org/en/search/test%20case
78 [istqb test suite]: http://glossary.istqb.org/en/search/test%20suite
82 When using googletest, you start by writing *assertions*, which are statements
83 that check whether a condition is true. An assertion's result can be *success*,
84 *nonfatal failure*, or *fatal failure*. If a fatal failure occurs, it aborts the
85 current function; otherwise the program continues normally.
87 *Tests* use assertions to verify the tested code's behavior. If a test crashes
88 or has a failed assertion, then it *fails*; otherwise it *succeeds*.
90 A *test suite* contains one or many tests. You should group your tests into test
91 suites that reflect the structure of the tested code. When multiple tests in a
92 test suite need to share common objects and subroutines, you can put them into a
95 A *test program* can contain multiple test suites.
97 We'll now explain how to write a test program, starting at the individual
98 assertion level and building up to tests and test suites.
102 googletest assertions are macros that resemble function calls. You test a class
103 or function by making assertions about its behavior. When an assertion fails,
104 googletest prints the assertion's source file and line number location, along
105 with a failure message. You may also supply a custom failure message which will
106 be appended to googletest's message.
108 The assertions come in pairs that test the same thing but have different effects
109 on the current function. `ASSERT_*` versions generate fatal failures when they
110 fail, and **abort the current function**. `EXPECT_*` versions generate nonfatal
111 failures, which don't abort the current function. Usually `EXPECT_*` are
112 preferred, as they allow more than one failure to be reported in a test.
113 However, you should use `ASSERT_*` if it doesn't make sense to continue when the
114 assertion in question fails.
116 Since a failed `ASSERT_*` returns from the current function immediately,
117 possibly skipping clean-up code that comes after it, it may cause a space leak.
118 Depending on the nature of the leak, it may or may not be worth fixing - so keep
119 this in mind if you get a heap checker error in addition to assertion errors.
121 To provide a custom failure message, simply stream it into the macro using the
122 `<<` operator or a sequence of such operators. An example:
125 ASSERT_EQ(x.size(), y.size()) << "Vectors x and y are of unequal length";
127 for (int i = 0; i < x.size(); ++i) {
128 EXPECT_EQ(x[i], y[i]) << "Vectors x and y differ at index " << i;
132 Anything that can be streamed to an `ostream` can be streamed to an assertion
133 macro--in particular, C strings and `string` objects. If a wide string
134 (`wchar_t*`, `TCHAR*` in `UNICODE` mode on Windows, or `std::wstring`) is
135 streamed to an assertion, it will be translated to UTF-8 when printed.
139 These assertions do basic true/false condition testing.
141 Fatal assertion | Nonfatal assertion | Verifies
142 -------------------------- | -------------------------- | --------------------
143 `ASSERT_TRUE(condition);` | `EXPECT_TRUE(condition);` | `condition` is true
144 `ASSERT_FALSE(condition);` | `EXPECT_FALSE(condition);` | `condition` is false
146 Remember, when they fail, `ASSERT_*` yields a fatal failure and returns from the
147 current function, while `EXPECT_*` yields a nonfatal failure, allowing the
148 function to continue running. In either case, an assertion failure means its
149 containing test fails.
151 **Availability**: Linux, Windows, Mac.
153 ### Binary Comparison
155 This section describes assertions that compare two values.
157 Fatal assertion | Nonfatal assertion | Verifies
158 ------------------------ | ------------------------ | --------------
159 `ASSERT_EQ(val1, val2);` | `EXPECT_EQ(val1, val2);` | `val1 == val2`
160 `ASSERT_NE(val1, val2);` | `EXPECT_NE(val1, val2);` | `val1 != val2`
161 `ASSERT_LT(val1, val2);` | `EXPECT_LT(val1, val2);` | `val1 < val2`
162 `ASSERT_LE(val1, val2);` | `EXPECT_LE(val1, val2);` | `val1 <= val2`
163 `ASSERT_GT(val1, val2);` | `EXPECT_GT(val1, val2);` | `val1 > val2`
164 `ASSERT_GE(val1, val2);` | `EXPECT_GE(val1, val2);` | `val1 >= val2`
166 Value arguments must be comparable by the assertion's comparison operator or
167 you'll get a compiler error. We used to require the arguments to support the
168 `<<` operator for streaming to an `ostream`, but this is no longer necessary. If
169 `<<` is supported, it will be called to print the arguments when the assertion
170 fails; otherwise googletest will attempt to print them in the best way it can.
171 For more details and how to customize the printing of the arguments, see the
172 [documentation](../../googlemock/docs/cook_book.md#teaching-gmock-how-to-print-your-values).
174 These assertions can work with a user-defined type, but only if you define the
175 corresponding comparison operator (e.g., `==` or `<`). Since this is discouraged
177 [C++ Style Guide](https://google.github.io/styleguide/cppguide.html#Operator_Overloading),
178 you may need to use `ASSERT_TRUE()` or `EXPECT_TRUE()` to assert the equality of
179 two objects of a user-defined type.
181 However, when possible, `ASSERT_EQ(actual, expected)` is preferred to
182 `ASSERT_TRUE(actual == expected)`, since it tells you `actual` and `expected`'s
185 Arguments are always evaluated exactly once. Therefore, it's OK for the
186 arguments to have side effects. However, as with any ordinary C/C++ function,
187 the arguments' evaluation order is undefined (i.e., the compiler is free to
188 choose any order), and your code should not depend on any particular argument
191 `ASSERT_EQ()` does pointer equality on pointers. If used on two C strings, it
192 tests if they are in the same memory location, not if they have the same value.
193 Therefore, if you want to compare C strings (e.g. `const char*`) by value, use
194 `ASSERT_STREQ()`, which will be described later on. In particular, to assert
195 that a C string is `NULL`, use `ASSERT_STREQ(c_string, NULL)`. Consider using
196 `ASSERT_EQ(c_string, nullptr)` if c++11 is supported. To compare two `string`
197 objects, you should use `ASSERT_EQ`.
199 When doing pointer comparisons use `*_EQ(ptr, nullptr)` and `*_NE(ptr, nullptr)`
200 instead of `*_EQ(ptr, NULL)` and `*_NE(ptr, NULL)`. This is because `nullptr` is
201 typed, while `NULL` is not. See the [FAQ](faq.md) for more details.
203 If you're working with floating point numbers, you may want to use the floating
204 point variations of some of these macros in order to avoid problems caused by
205 rounding. See [Advanced googletest Topics](advanced.md) for details.
207 Macros in this section work with both narrow and wide string objects (`string`
210 **Availability**: Linux, Windows, Mac.
212 **Historical note**: Before February 2016 `*_EQ` had a convention of calling it
213 as `ASSERT_EQ(expected, actual)`, so lots of existing code uses this order. Now
214 `*_EQ` treats both parameters in the same way.
216 ### String Comparison
218 The assertions in this group compare two **C strings**. If you want to compare
219 two `string` objects, use `EXPECT_EQ`, `EXPECT_NE`, and etc instead.
221 <!-- mdformat off(github rendering does not support multiline tables) -->
223 | Fatal assertion | Nonfatal assertion | Verifies |
224 | -------------------------- | ------------------------------ | -------------------------------------------------------- |
225 | `ASSERT_STREQ(str1,str2);` | `EXPECT_STREQ(str1,str2);` | the two C strings have the same content |
226 | `ASSERT_STRNE(str1,str2);` | `EXPECT_STRNE(str1,str2);` | the two C strings have different contents |
227 | `ASSERT_STRCASEEQ(str1,str2);` | `EXPECT_STRCASEEQ(str1,str2);` | the two C strings have the same content, ignoring case |
228 | `ASSERT_STRCASENE(str1,str2);` | `EXPECT_STRCASENE(str1,str2);` | the two C strings have different contents, ignoring case |
232 Note that "CASE" in an assertion name means that case is ignored. A `NULL`
233 pointer and an empty string are considered *different*.
235 `*STREQ*` and `*STRNE*` also accept wide C strings (`wchar_t*`). If a comparison
236 of two wide strings fails, their values will be printed as UTF-8 narrow strings.
238 **Availability**: Linux, Windows, Mac.
240 **See also**: For more string comparison tricks (substring, prefix, suffix, and
241 regular expression matching, for example), see [this](advanced.md) in the
242 Advanced googletest Guide.
248 1. Use the `TEST()` macro to define and name a test function. These are
249 ordinary C++ functions that don't return a value.
250 2. In this function, along with any valid C++ statements you want to include,
251 use the various googletest assertions to check values.
252 3. The test's result is determined by the assertions; if any assertion in the
253 test fails (either fatally or non-fatally), or if the test crashes, the
254 entire test fails. Otherwise, it succeeds.
257 TEST(TestSuiteName, TestName) {
262 `TEST()` arguments go from general to specific. The *first* argument is the name
263 of the test suite, and the *second* argument is the test's name within the test
264 case. Both names must be valid C++ identifiers, and they should not contain
265 any underscores (`_`). A test's *full name* consists of its containing test suite and
266 its individual name. Tests from different test suites can have the same
269 For example, let's take a simple integer function:
272 int Factorial(int n); // Returns the factorial of n
275 A test suite for this function might look like:
278 // Tests factorial of 0.
279 TEST(FactorialTest, HandlesZeroInput) {
280 EXPECT_EQ(Factorial(0), 1);
283 // Tests factorial of positive numbers.
284 TEST(FactorialTest, HandlesPositiveInput) {
285 EXPECT_EQ(Factorial(1), 1);
286 EXPECT_EQ(Factorial(2), 2);
287 EXPECT_EQ(Factorial(3), 6);
288 EXPECT_EQ(Factorial(8), 40320);
292 googletest groups the test results by test suites, so logically related tests
293 should be in the same test suite; in other words, the first argument to their
294 `TEST()` should be the same. In the above example, we have two tests,
295 `HandlesZeroInput` and `HandlesPositiveInput`, that belong to the same test
296 suite `FactorialTest`.
298 When naming your test suites and tests, you should follow the same convention as
300 [naming functions and classes](https://google.github.io/styleguide/cppguide.html#Function_Names).
302 **Availability**: Linux, Windows, Mac.
304 ## Test Fixtures: Using the Same Data Configuration for Multiple Tests {#same-data-multiple-tests}
306 If you find yourself writing two or more tests that operate on similar data, you
307 can use a *test fixture*. This allows you to reuse the same configuration of
308 objects for several different tests.
312 1. Derive a class from `::testing::Test` . Start its body with `protected:`, as
313 we'll want to access fixture members from sub-classes.
314 2. Inside the class, declare any objects you plan to use.
315 3. If necessary, write a default constructor or `SetUp()` function to prepare
316 the objects for each test. A common mistake is to spell `SetUp()` as
317 **`Setup()`** with a small `u` - Use `override` in C++11 to make sure you
318 spelled it correctly.
319 4. If necessary, write a destructor or `TearDown()` function to release any
320 resources you allocated in `SetUp()` . To learn when you should use the
321 constructor/destructor and when you should use `SetUp()/TearDown()`, read
322 the [FAQ](faq.md#CtorVsSetUp).
323 5. If needed, define subroutines for your tests to share.
325 When using a fixture, use `TEST_F()` instead of `TEST()` as it allows you to
326 access objects and subroutines in the test fixture:
329 TEST_F(TestFixtureName, TestName) {
334 Like `TEST()`, the first argument is the test suite name, but for `TEST_F()`
335 this must be the name of the test fixture class. You've probably guessed: `_F`
338 Unfortunately, the C++ macro system does not allow us to create a single macro
339 that can handle both types of tests. Using the wrong macro causes a compiler
342 Also, you must first define a test fixture class before using it in a
343 `TEST_F()`, or you'll get the compiler error "`virtual outside class
346 For each test defined with `TEST_F()`, googletest will create a *fresh* test
347 fixture at runtime, immediately initialize it via `SetUp()`, run the test,
348 clean up by calling `TearDown()`, and then delete the test fixture. Note that
349 different tests in the same test suite have different test fixture objects, and
350 googletest always deletes a test fixture before it creates the next one.
351 googletest does **not** reuse the same test fixture for multiple tests. Any
352 changes one test makes to the fixture do not affect other tests.
354 As an example, let's write tests for a FIFO queue class named `Queue`, which has
355 the following interface:
358 template <typename E> // E is the element type.
362 void Enqueue(const E& element);
363 E* Dequeue(); // Returns NULL if the queue is empty.
369 First, define a fixture class. By convention, you should give it the name
370 `FooTest` where `Foo` is the class being tested.
373 class QueueTest : public ::testing::Test {
375 void SetUp() override {
381 // void TearDown() override {}
389 In this case, `TearDown()` is not needed since we don't have to clean up after
390 each test, other than what's already done by the destructor.
392 Now we'll write tests using `TEST_F()` and this fixture.
395 TEST_F(QueueTest, IsEmptyInitially) {
396 EXPECT_EQ(q0_.size(), 0);
399 TEST_F(QueueTest, DequeueWorks) {
400 int* n = q0_.Dequeue();
401 EXPECT_EQ(n, nullptr);
404 ASSERT_NE(n, nullptr);
406 EXPECT_EQ(q1_.size(), 0);
410 ASSERT_NE(n, nullptr);
412 EXPECT_EQ(q2_.size(), 1);
417 The above uses both `ASSERT_*` and `EXPECT_*` assertions. The rule of thumb is
418 to use `EXPECT_*` when you want the test to continue to reveal more errors after
419 the assertion failure, and use `ASSERT_*` when continuing after failure doesn't
420 make sense. For example, the second assertion in the `Dequeue` test is
421 `ASSERT_NE(nullptr, n)`, as we need to dereference the pointer `n` later, which
422 would lead to a segfault when `n` is `NULL`.
424 When these tests run, the following happens:
426 1. googletest constructs a `QueueTest` object (let's call it `t1`).
427 2. `t1.SetUp()` initializes `t1`.
428 3. The first test (`IsEmptyInitially`) runs on `t1`.
429 4. `t1.TearDown()` cleans up after the test finishes.
430 5. `t1` is destructed.
431 6. The above steps are repeated on another `QueueTest` object, this time
432 running the `DequeueWorks` test.
434 **Availability**: Linux, Windows, Mac.
436 ## Invoking the Tests
438 `TEST()` and `TEST_F()` implicitly register their tests with googletest. So,
439 unlike with many other C++ testing frameworks, you don't have to re-list all
440 your defined tests in order to run them.
442 After defining your tests, you can run them with `RUN_ALL_TESTS()`, which
443 returns `0` if all the tests are successful, or `1` otherwise. Note that
444 `RUN_ALL_TESTS()` runs *all tests* in your link unit--they can be from
445 different test suites, or even different source files.
447 When invoked, the `RUN_ALL_TESTS()` macro:
449 * Saves the state of all googletest flags.
451 * Creates a test fixture object for the first test.
453 * Initializes it via `SetUp()`.
455 * Runs the test on the fixture object.
457 * Cleans up the fixture via `TearDown()`.
459 * Deletes the fixture.
461 * Restores the state of all googletest flags.
463 * Repeats the above steps for the next test, until all tests have run.
465 If a fatal failure happens the subsequent steps will be skipped.
467 > IMPORTANT: You must **not** ignore the return value of `RUN_ALL_TESTS()`, or
468 > you will get a compiler error. The rationale for this design is that the
469 > automated testing service determines whether a test has passed based on its
470 > exit code, not on its stdout/stderr output; thus your `main()` function must
471 > return the value of `RUN_ALL_TESTS()`.
473 > Also, you should call `RUN_ALL_TESTS()` only **once**. Calling it more than
474 > once conflicts with some advanced googletest features (e.g., thread-safe
475 > [death tests](advanced.md#death-tests)) and thus is not supported.
477 **Availability**: Linux, Windows, Mac.
479 ## Writing the main() Function
481 Write your own main() function, which should return the value of
484 You can start from this boilerplate:
487 #include "this/package/foo.h"
488 #include "gtest/gtest.h"
492 // The fixture for testing class Foo.
493 class FooTest : public ::testing::Test {
495 // You can remove any or all of the following functions if its body
499 // You can do set-up work for each test here.
502 ~FooTest() override {
503 // You can do clean-up work that doesn't throw exceptions here.
506 // If the constructor and destructor are not enough for setting up
507 // and cleaning up each test, you can define the following methods:
509 void SetUp() override {
510 // Code here will be called immediately after the constructor (right
511 // before each test).
514 void TearDown() override {
515 // Code here will be called immediately after each test (right
516 // before the destructor).
519 // Objects declared here can be used by all tests in the test suite for Foo.
522 // Tests that the Foo::Bar() method does Abc.
523 TEST_F(FooTest, MethodBarDoesAbc) {
524 const std::string input_filepath = "this/package/testdata/myinputfile.dat";
525 const std::string output_filepath = "this/package/testdata/myoutputfile.dat";
527 EXPECT_EQ(f.Bar(input_filepath, output_filepath), 0);
530 // Tests that Foo does Xyz.
531 TEST_F(FooTest, DoesXyz) {
532 // Exercises the Xyz feature of Foo.
537 int main(int argc, char **argv) {
538 ::testing::InitGoogleTest(&argc, argv);
539 return RUN_ALL_TESTS();
543 The `::testing::InitGoogleTest()` function parses the command line for
544 googletest flags, and removes all recognized flags. This allows the user to
545 control a test program's behavior via various flags, which we'll cover in
546 the [AdvancedGuide](advanced.md). You **must** call this function before calling
547 `RUN_ALL_TESTS()`, or the flags won't be properly initialized.
549 On Windows, `InitGoogleTest()` also works with wide strings, so it can be used
550 in programs compiled in `UNICODE` mode as well.
552 But maybe you think that writing all those main() functions is too much work? We
553 agree with you completely, and that's why Google Test provides a basic
554 implementation of main(). If it fits your needs, then just link your test with
555 gtest\_main library and you are good to go.
557 NOTE: `ParseGUnitFlags()` is deprecated in favor of `InitGoogleTest()`.
561 * Google Test is designed to be thread-safe. The implementation is thread-safe
562 on systems where the `pthreads` library is available. It is currently
563 _unsafe_ to use Google Test assertions from two threads concurrently on
564 other systems (e.g. Windows). In most tests this is not an issue as usually
565 the assertions are done in the main thread. If you want to help, you can
566 volunteer to implement the necessary synchronization primitives in
567 `gtest-port.h` for your platform.