advanced.md 81.7 KB
Newer Older
Gennadiy Civil's avatar
Gennadiy Civil committed
1
# Advanced googletest Topics
2

Gennadiy Civil's avatar
Gennadiy Civil committed
3
## Introduction
4

5
6
7
8
9
Now that you have read the [googletest Primer](primer.md) and learned how to
write tests using googletest, it's time to learn some new tricks. This document
will show you more assertions as well as how to construct complex failure
messages, propagate fatal failures, reuse and speed up your test fixtures, and
use various flags with your tests.
Gennadiy Civil's avatar
Gennadiy Civil committed
10
11

## More Assertions
12
13
14
15

This section covers some less frequently used, but still significant,
assertions.

Gennadiy Civil's avatar
Gennadiy Civil committed
16
### Explicit Success and Failure
17

Abseil Team's avatar
Abseil Team committed
18
19
See [Explicit Success and Failure](reference/assertions.md#success-failure) in
the Assertions Reference.
20

Gennadiy Civil's avatar
Gennadiy Civil committed
21
### Exception Assertions
22

Abseil Team's avatar
Abseil Team committed
23
24
See [Exception Assertions](reference/assertions.md#exceptions) in the Assertions
Reference.
25

Gennadiy Civil's avatar
Gennadiy Civil committed
26
### Predicate Assertions for Better Error Messages
27

Gennadiy Civil's avatar
Gennadiy Civil committed
28
29
30
31
32
Even though googletest has a rich set of assertions, they can never be complete,
as it's impossible (nor a good idea) to anticipate all scenarios a user might
run into. Therefore, sometimes a user has to use `EXPECT_TRUE()` to check a
complex expression, for lack of a better macro. This has the problem of not
showing you the values of the parts of the expression, making it hard to
33
34
35
36
37
understand what went wrong. As a workaround, some users choose to construct the
failure message by themselves, streaming it into `EXPECT_TRUE()`. However, this
is awkward especially when the expression has side-effects or is expensive to
evaluate.

Gennadiy Civil's avatar
Gennadiy Civil committed
38
googletest gives you three different options to solve this problem:
39

Gennadiy Civil's avatar
Gennadiy Civil committed
40
#### Using an Existing Boolean Function
41

Gennadiy Civil's avatar
Gennadiy Civil committed
42
43
If you already have a function or functor that returns `bool` (or a type that
can be implicitly converted to `bool`), you can use it in a *predicate
Abseil Team's avatar
Abseil Team committed
44
45
46
assertion* to get the function arguments printed for free. See
[`EXPECT_PRED*`](reference/assertions.md#EXPECT_PRED) in the Assertions
Reference for details.
47

Gennadiy Civil's avatar
Gennadiy Civil committed
48
#### Using a Function That Returns an AssertionResult
49

Gennadiy Civil's avatar
Gennadiy Civil committed
50
51
52
53
While `EXPECT_PRED*()` and friends are handy for a quick job, the syntax is not
satisfactory: you have to use different macros for different arities, and it
feels more like Lisp than C++. The `::testing::AssertionResult` class solves
this problem.
54

Gennadiy Civil's avatar
Gennadiy Civil committed
55
56
57
An `AssertionResult` object represents the result of an assertion (whether it's
a success or a failure, and an associated message). You can create an
`AssertionResult` using one of these factory functions:
58

Gennadiy Civil's avatar
Gennadiy Civil committed
59
```c++
60
61
62
63
64
65
66
67
68
69
70
71
72
namespace testing {

// Returns an AssertionResult object to indicate that an assertion has
// succeeded.
AssertionResult AssertionSuccess();

// Returns an AssertionResult object to indicate that an assertion has
// failed.
AssertionResult AssertionFailure();

}
```

Gennadiy Civil's avatar
Gennadiy Civil committed
73
74
You can then use the `<<` operator to stream messages to the `AssertionResult`
object.
75

Gennadiy Civil's avatar
Gennadiy Civil committed
76
77
78
To provide more readable messages in Boolean assertions (e.g. `EXPECT_TRUE()`),
write a predicate function that returns `AssertionResult` instead of `bool`. For
example, if you define `IsEven()` as:
79

Gennadiy Civil's avatar
Gennadiy Civil committed
80
```c++
Abseil Team's avatar
Abseil Team committed
81
testing::AssertionResult IsEven(int n) {
82
  if ((n % 2) == 0)
Abseil Team's avatar
Abseil Team committed
83
    return testing::AssertionSuccess();
84
  else
Abseil Team's avatar
Abseil Team committed
85
    return testing::AssertionFailure() << n << " is odd";
86
87
88
89
90
}
```

instead of:

Gennadiy Civil's avatar
Gennadiy Civil committed
91
```c++
92
93
94
95
96
97
98
bool IsEven(int n) {
  return (n % 2) == 0;
}
```

the failed assertion `EXPECT_TRUE(IsEven(Fib(4)))` will print:

Gennadiy Civil's avatar
Gennadiy Civil committed
99
100
101
102
103
```none
Value of: IsEven(Fib(4))
  Actual: false (3 is odd)
Expected: true
```
104
105
106

instead of a more opaque

Gennadiy Civil's avatar
Gennadiy Civil committed
107
108
109
110
111
```none
Value of: IsEven(Fib(4))
  Actual: false
Expected: true
```
112

Gennadiy Civil's avatar
Gennadiy Civil committed
113
114
115
116
If you want informative messages in `EXPECT_FALSE` and `ASSERT_FALSE` as well
(one third of Boolean assertions in the Google code base are negative ones), and
are fine with making the predicate slower in the success case, you can supply a
success message:
117

Gennadiy Civil's avatar
Gennadiy Civil committed
118
```c++
Abseil Team's avatar
Abseil Team committed
119
testing::AssertionResult IsEven(int n) {
120
  if ((n % 2) == 0)
Abseil Team's avatar
Abseil Team committed
121
    return testing::AssertionSuccess() << n << " is even";
122
  else
Abseil Team's avatar
Abseil Team committed
123
    return testing::AssertionFailure() << n << " is odd";
124
125
126
127
128
}
```

Then the statement `EXPECT_FALSE(IsEven(Fib(6)))` will print

Gennadiy Civil's avatar
Gennadiy Civil committed
129
130
131
132
133
```none
  Value of: IsEven(Fib(6))
     Actual: true (8 is even)
  Expected: false
```
134

Gennadiy Civil's avatar
Gennadiy Civil committed
135
#### Using a Predicate-Formatter
136

Abseil Team's avatar
Abseil Team committed
137
138
139
140
141
142
143
144
If you find the default message generated by
[`EXPECT_PRED*`](reference/assertions.md#EXPECT_PRED) and
[`EXPECT_TRUE`](reference/assertions.md#EXPECT_TRUE) unsatisfactory, or some
arguments to your predicate do not support streaming to `ostream`, you can
instead use *predicate-formatter assertions* to *fully* customize how the
message is formatted. See
[`EXPECT_PRED_FORMAT*`](reference/assertions.md#EXPECT_PRED_FORMAT) in the
Assertions Reference for details.
145

Gennadiy Civil's avatar
Gennadiy Civil committed
146
### Floating-Point Comparison
147

Abseil Team's avatar
Abseil Team committed
148
149
See [Floating-Point Comparison](reference/assertions.md#floating-point) in the
Assertions Reference.
150

Gennadiy Civil's avatar
Gennadiy Civil committed
151
#### Floating-Point Predicate-Format Functions
152

Gennadiy Civil's avatar
Gennadiy Civil committed
153
154
Some floating-point operations are useful, but not that often used. In order to
avoid an explosion of new macros, we provide them as predicate-format functions
Abseil Team's avatar
Abseil Team committed
155
156
157
that can be used in the predicate assertion macro
[`EXPECT_PRED_FORMAT2`](reference/assertions.md#EXPECT_PRED_FORMAT), for
example:
158

Gennadiy Civil's avatar
Gennadiy Civil committed
159
```c++
Abseil Team's avatar
Abseil Team committed
160
161
EXPECT_PRED_FORMAT2(testing::FloatLE, val1, val2);
EXPECT_PRED_FORMAT2(testing::DoubleLE, val1, val2);
162
163
```

Abseil Team's avatar
Abseil Team committed
164
165
The above code verifies that `val1` is less than, or approximately equal to,
`val2`.
166

Gennadiy Civil's avatar
Gennadiy Civil committed
167
168
### Asserting Using gMock Matchers

Abseil Team's avatar
Abseil Team committed
169
170
See [`EXPECT_THAT`](reference/assertions.md#EXPECT_THAT) in the Assertions
Reference.
Gennadiy Civil's avatar
Gennadiy Civil committed
171
172
173

### More String Assertions

Abseil Team's avatar
Abseil Team committed
174
175
(Please read the [previous](#asserting-using-gmock-matchers) section first if
you haven't.)
Gennadiy Civil's avatar
Gennadiy Civil committed
176

Abseil Team's avatar
Abseil Team committed
177
You can use the gMock [string matchers](reference/matchers.md#string-matchers)
Abseil Team's avatar
Abseil Team committed
178
179
180
with [`EXPECT_THAT`](reference/assertions.md#EXPECT_THAT) to do more string
comparison tricks (sub-string, prefix, suffix, regular expression, and etc). For
example,
Gennadiy Civil's avatar
Gennadiy Civil committed
181
182
183
184
185
186
187
188
189
190

```c++
using ::testing::HasSubstr;
using ::testing::MatchesRegex;
...
  ASSERT_THAT(foo_string, HasSubstr("needle"));
  EXPECT_THAT(bar_string, MatchesRegex("\\w*\\d+"));
```

### Windows HRESULT assertions
191

Abseil Team's avatar
Abseil Team committed
192
193
See [Windows HRESULT Assertions](reference/assertions.md#HRESULT) in the
Assertions Reference.
194

Gennadiy Civil's avatar
Gennadiy Civil committed
195
### Type Assertions
196
197

You can call the function
Gennadiy Civil's avatar
Gennadiy Civil committed
198
199

```c++
200
201
202
::testing::StaticAssertTypeEq<T1, T2>();
```

Gennadiy Civil's avatar
Gennadiy Civil committed
203
204
to assert that types `T1` and `T2` are the same. The function does nothing if
the assertion is satisfied. If the types are different, the function call will
Abseil Team's avatar
Abseil Team committed
205
206
207
fail to compile, the compiler error message will say that `T1 and T2 are not the
same type` and most likely (depending on the compiler) show you the actual
values of `T1` and `T2`. This is mainly useful inside template code.
Gennadiy Civil's avatar
Gennadiy Civil committed
208
209
210
211
212
213

**Caveat**: When used inside a member function of a class template or a function
template, `StaticAssertTypeEq<T1, T2>()` is effective only if the function is
instantiated. For example, given:

```c++
214
215
template <typename T> class Foo {
 public:
Abseil Team's avatar
Abseil Team committed
216
  void Bar() { testing::StaticAssertTypeEq<int, T>(); }
217
218
};
```
Gennadiy Civil's avatar
Gennadiy Civil committed
219

220
the code:
Gennadiy Civil's avatar
Gennadiy Civil committed
221
222

```c++
223
224
void Test1() { Foo<bool> foo; }
```
Gennadiy Civil's avatar
Gennadiy Civil committed
225
226
227
228
229

will not generate a compiler error, as `Foo<bool>::Bar()` is never actually
instantiated. Instead, you need:

```c++
230
231
void Test2() { Foo<bool> foo; foo.Bar(); }
```
Gennadiy Civil's avatar
Gennadiy Civil committed
232

233
234
to cause a compiler error.

Gennadiy Civil's avatar
Gennadiy Civil committed
235
### Assertion Placement
236

Gennadiy Civil's avatar
Gennadiy Civil committed
237
238
239
240
241
242
243
244
You can use assertions in any C++ function. In particular, it doesn't have to be
a method of the test fixture class. The one constraint is that assertions that
generate a fatal failure (`FAIL*` and `ASSERT_*`) can only be used in
void-returning functions. This is a consequence of Google's not using
exceptions. By placing it in a non-void function you'll get a confusing compile
error like `"error: void value not ignored as it ought to be"` or `"cannot
initialize return object of type 'bool' with an rvalue of type 'void'"` or
`"error: no viable conversion from 'void' to 'string'"`.
245

Gennadiy Civil's avatar
Gennadiy Civil committed
246
247
If you need to use fatal assertions in a function that returns non-void, one
option is to make the function return the value in an out parameter instead. For
248
249
250
251
252
example, you can rewrite `T2 Foo(T1 x)` to `void Foo(T1 x, T2* result)`. You
need to make sure that `*result` contains some sensible value even when the
function returns prematurely. As the function now returns `void`, you can use
any assertion inside of it.

Gennadiy Civil's avatar
Gennadiy Civil committed
253
254
If changing the function's type is not an option, you should just use assertions
that generate non-fatal failures, such as `ADD_FAILURE*` and `EXPECT_*`.
255

Abseil Team's avatar
Abseil Team committed
256
{: .callout .note}
Gennadiy Civil's avatar
Gennadiy Civil committed
257
258
NOTE: Constructors and destructors are not considered void-returning functions,
according to the C++ language specification, and so you may not use fatal
259
260
261
262
263
assertions in them; you'll get a compilation error if you try. Instead, either
call `abort` and crash the entire test executable, or put the fatal assertion in
a `SetUp`/`TearDown` function; see
[constructor/destructor vs. `SetUp`/`TearDown`](faq.md#CtorVsSetUp)

Abseil Team's avatar
Abseil Team committed
264
{: .callout .warning}
265
WARNING: A fatal assertion in a helper function (private void-returning method)
Abseil Team's avatar
Abseil Team committed
266
267
called from a constructor or destructor does not terminate the current test, as
your intuition might suggest: it merely returns from the constructor or
268
269
270
destructor early, possibly leaving your object in a partially-constructed or
partially-destructed state! You almost certainly want to `abort` or use
`SetUp`/`TearDown` instead.
271

272
273
## Skipping test execution

274
275
Related to the assertions `SUCCEED()` and `FAIL()`, you can prevent further test
execution at runtime with the `GTEST_SKIP()` macro. This is useful when you need
276
277
to check for preconditions of the system under test during runtime and skip
tests in a meaningful way.
278

279
280
281
`GTEST_SKIP()` can be used in individual test cases or in the `SetUp()` methods
of classes derived from either `::testing::Environment` or `::testing::Test`.
For example:
282
283

```c++
284
285
286
287
288
289
TEST(SkipTest, DoesSkip) {
  GTEST_SKIP() << "Skipping single test";
  EXPECT_EQ(0, 1);  // Won't fail; it won't be executed
}

class SkipFixture : public ::testing::Test {
290
291
 protected:
  void SetUp() override {
292
    GTEST_SKIP() << "Skipping all tests for this fixture";
293
294
295
  }
};

296
297
298
// Tests for SkipFixture won't be executed.
TEST_F(SkipFixture, SkipsOneTest) {
  EXPECT_EQ(5, 7);  // Won't fail
299
300
301
}
```

302
As with assertion macros, you can stream a custom message into `GTEST_SKIP()`.
303

Gennadiy Civil's avatar
Gennadiy Civil committed
304
## Teaching googletest How to Print Your Values
305

Gennadiy Civil's avatar
Gennadiy Civil committed
306
307
When a test assertion such as `EXPECT_EQ` fails, googletest prints the argument
values to help you debug. It does this using a user-extensible value printer.
308
309

This printer knows how to print built-in C++ types, native arrays, STL
Gennadiy Civil's avatar
Gennadiy Civil committed
310
311
containers, and any type that supports the `<<` operator. For other types, it
prints the raw bytes in the value and hopes that you the user can figure it out.
312

Gennadiy Civil's avatar
Gennadiy Civil committed
313
314
315
As mentioned earlier, the printer is *extensible*. That means you can teach it
to do a better job at printing your particular type than to dump the bytes. To
do that, define `<<` for your type:
316

Gennadiy Civil's avatar
Gennadiy Civil committed
317
318
```c++
#include <ostream>
319
320
321

namespace foo {

Gennadiy Civil's avatar
Gennadiy Civil committed
322
323
324
class Bar {  // We want googletest to be able to print instances of this.
...
  // Create a free inline friend function.
325
  friend std::ostream& operator<<(std::ostream& os, const Bar& bar) {
Gennadiy Civil's avatar
Gennadiy Civil committed
326
327
328
    return os << bar.DebugString();  // whatever needed to print bar to os
  }
};
329

Gennadiy Civil's avatar
Gennadiy Civil committed
330
331
332
// If you can't declare the function in the class it's important that the
// << operator is defined in the SAME namespace that defines Bar.  C++'s look-up
// rules rely on that.
333
std::ostream& operator<<(std::ostream& os, const Bar& bar) {
334
335
336
337
338
339
  return os << bar.DebugString();  // whatever needed to print bar to os
}

}  // namespace foo
```

Gennadiy Civil's avatar
Gennadiy Civil committed
340
341
342
343
Sometimes, this might not be an option: your team may consider it bad style to
have a `<<` operator for `Bar`, or `Bar` may already have a `<<` operator that
doesn't do what you want (and you cannot change it). If so, you can instead
define a `PrintTo()` function like this:
344

Gennadiy Civil's avatar
Gennadiy Civil committed
345
346
```c++
#include <ostream>
347
348
349

namespace foo {

Gennadiy Civil's avatar
Gennadiy Civil committed
350
351
class Bar {
  ...
352
  friend void PrintTo(const Bar& bar, std::ostream* os) {
Gennadiy Civil's avatar
Gennadiy Civil committed
353
354
355
    *os << bar.DebugString();  // whatever needed to print bar to os
  }
};
356

Gennadiy Civil's avatar
Gennadiy Civil committed
357
358
359
// If you can't declare the function in the class it's important that PrintTo()
// is defined in the SAME namespace that defines Bar.  C++'s look-up rules rely
// on that.
360
void PrintTo(const Bar& bar, std::ostream* os) {
361
362
363
364
365
366
  *os << bar.DebugString();  // whatever needed to print bar to os
}

}  // namespace foo
```

Gennadiy Civil's avatar
Gennadiy Civil committed
367
368
369
370
If you have defined both `<<` and `PrintTo()`, the latter will be used when
googletest is concerned. This allows you to customize how the value appears in
googletest's output without affecting code that relies on the behavior of its
`<<` operator.
371

Gennadiy Civil's avatar
Gennadiy Civil committed
372
373
If you want to print a value `x` using googletest's value printer yourself, just
call `::testing::PrintToString(x)`, which returns an `std::string`:
374

Gennadiy Civil's avatar
Gennadiy Civil committed
375
```c++
376
377
378
vector<pair<Bar, int> > bar_ints = GetBarIntVector();

EXPECT_TRUE(IsCorrectBarIntVector(bar_ints))
Abseil Team's avatar
Abseil Team committed
379
    << "bar_ints = " << testing::PrintToString(bar_ints);
380
381
```

Gennadiy Civil's avatar
Gennadiy Civil committed
382
## Death Tests
383

Gennadiy Civil's avatar
Gennadiy Civil committed
384
In many applications, there are assertions that can cause application failure if
Abseil Team's avatar
Abseil Team committed
385
386
387
388
a condition is not met. These consistency checks, which ensure that the program
is in a known good state, are there to fail at the earliest possible time after
some program state is corrupted. If the assertion checks the wrong condition,
then the program may proceed in an erroneous state, which could lead to memory
Gennadiy Civil's avatar
Gennadiy Civil committed
389
390
corruption, security holes, or worse. Hence it is vitally important to test that
such assertion statements work as expected.
391
392
393
394
395
396

Since these precondition checks cause the processes to die, we call such tests
_death tests_. More generally, any test that checks that a program terminates
(except by throwing an exception) in an expected fashion is also a death test.

Note that if a piece of code throws an exception, we don't consider it "death"
Gennadiy Civil's avatar
Gennadiy Civil committed
397
398
for the purpose of death tests, as the caller of the code could catch the
exception and avoid the crash. If you want to verify exceptions thrown by your
399
code, see [Exception Assertions](#ExceptionAssertions).
400

Gennadiy Civil's avatar
Gennadiy Civil committed
401
If you want to test `EXPECT_*()/ASSERT_*()` failures in your test code, see
Abseil Team's avatar
Abseil Team committed
402
["Catching" Failures](#catching-failures).
403

Gennadiy Civil's avatar
Gennadiy Civil committed
404
### How to Write a Death Test
405

Abseil Team's avatar
Abseil Team committed
406
407
408
GoogleTest provides assertion macros to support death tests. See
[Death Assertions](reference/assertions.md#death) in the Assertions Reference
for details.
409

Abseil Team's avatar
Abseil Team committed
410
411
To write a death test, simply use one of the macros inside your test function.
For example,
412

Gennadiy Civil's avatar
Gennadiy Civil committed
413
```c++
414
415
TEST(MyDeathTest, Foo) {
  // This death test uses a compound statement.
Gennadiy Civil's avatar
Gennadiy Civil committed
416
417
418
419
  ASSERT_DEATH({
    int n = 5;
    Foo(&n);
  }, "Error on line .* of Foo()");
420
}
Gennadiy Civil's avatar
Gennadiy Civil committed
421

422
TEST(MyDeathTest, NormalExit) {
Abseil Team's avatar
Abseil Team committed
423
  EXPECT_EXIT(NormalExit(), testing::ExitedWithCode(0), "Success");
424
}
Gennadiy Civil's avatar
Gennadiy Civil committed
425

Abseil Team's avatar
Abseil Team committed
426
427
TEST(MyDeathTest, KillProcess) {
  EXPECT_EXIT(KillProcess(), testing::KilledBySignal(SIGKILL),
Gennadiy Civil's avatar
Gennadiy Civil committed
428
              "Sending myself unblockable signal");
429
430
431
432
433
}
```

verifies that:

Gennadiy Civil's avatar
Gennadiy Civil committed
434
435
436
*   calling `Foo(5)` causes the process to die with the given error message,
*   calling `NormalExit()` causes the process to print `"Success"` to stderr and
    exit with exit code 0, and
Abseil Team's avatar
Abseil Team committed
437
*   calling `KillProcess()` kills the process with signal `SIGKILL`.
438
439
440
441

The test function body may contain other assertions and statements as well, if
necessary.

Abseil Team's avatar
Abseil Team committed
442
443
444
445
446
447
448
449
450
451
452
453
Note that a death test only cares about three things:

1.  does `statement` abort or exit the process?
2.  (in the case of `ASSERT_EXIT` and `EXPECT_EXIT`) does the exit status
    satisfy `predicate`? Or (in the case of `ASSERT_DEATH` and `EXPECT_DEATH`)
    is the exit status non-zero? And
3.  does the stderr output match `matcher`?

In particular, if `statement` generates an `ASSERT_*` or `EXPECT_*` failure, it
will **not** cause the death test to fail, as googletest assertions don't abort
the process.

Gennadiy Civil's avatar
Gennadiy Civil committed
454
### Death Test Naming
455

Abseil Team's avatar
Abseil Team committed
456
{: .callout .important}
Gennadiy Civil's avatar
Gennadiy Civil committed
457
IMPORTANT: We strongly recommend you to follow the convention of naming your
458
**test suite** (not test) `*DeathTest` when it contains a death test, as
459
460
demonstrated in the above example. The
[Death Tests And Threads](#death-tests-and-threads) section below explains why.
Gennadiy Civil's avatar
Gennadiy Civil committed
461
462
463

If a test fixture class is shared by normal tests and death tests, you can use
`using` or `typedef` to introduce an alias for the fixture class and avoid
464
duplicating its code:
Gennadiy Civil's avatar
Gennadiy Civil committed
465
466

```c++
Abseil Team's avatar
Abseil Team committed
467
class FooTest : public testing::Test { ... };
468

Gennadiy Civil's avatar
Gennadiy Civil committed
469
using FooDeathTest = FooTest;
470
471
472
473
474
475
476
477
478
479

TEST_F(FooTest, DoesThis) {
  // normal test
}

TEST_F(FooDeathTest, DoesThat) {
  // death test
}
```

Gennadiy Civil's avatar
Gennadiy Civil committed
480
### Regular Expression Syntax
481

Gennadiy Civil's avatar
Gennadiy Civil committed
482
On POSIX systems (e.g. Linux, Cygwin, and Mac), googletest uses the
483
[POSIX extended regular expression](http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap09.html#tag_09_04)
Gennadiy Civil's avatar
Gennadiy Civil committed
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
syntax. To learn about this syntax, you may want to read this
[Wikipedia entry](http://en.wikipedia.org/wiki/Regular_expression#POSIX_Extended_Regular_Expressions).

On Windows, googletest uses its own simple regular expression implementation. It
lacks many features. For example, we don't support union (`"x|y"`), grouping
(`"(xy)"`), brackets (`"[xy]"`), and repetition count (`"x{5,7}"`), among
others. Below is what we do support (`A` denotes a literal character, period
(`.`), or a single `\\ ` escape sequence; `x` and `y` denote regular
expressions.):

Expression | Meaning
---------- | --------------------------------------------------------------
`c`        | matches any literal character `c`
`\\d`      | matches any decimal digit
`\\D`      | matches any character that's not a decimal digit
`\\f`      | matches `\f`
`\\n`      | matches `\n`
`\\r`      | matches `\r`
`\\s`      | matches any ASCII whitespace, including `\n`
`\\S`      | matches any character that's not a whitespace
`\\t`      | matches `\t`
`\\v`      | matches `\v`
`\\w`      | matches any letter, `_`, or decimal digit
`\\W`      | matches any character that `\\w` doesn't match
`\\c`      | matches any literal character `c`, which must be a punctuation
`.`        | matches any single character except `\n`
`A?`       | matches 0 or 1 occurrences of `A`
`A*`       | matches 0 or many occurrences of `A`
`A+`       | matches 1 or many occurrences of `A`
`^`        | matches the beginning of a string (not that of each line)
`$`        | matches the end of a string (not that of each line)
`xy`       | matches `x` followed by `y`

To help you determine which capability is available on your system, googletest
defines macros to govern which regular expression it is using. The macros are:
519
520
521
`GTEST_USES_SIMPLE_RE=1` or `GTEST_USES_POSIX_RE=1`. If you want your death
tests to work in all cases, you can either `#if` on these macros or use the more
limited syntax only.
Gennadiy Civil's avatar
Gennadiy Civil committed
522
523
524

### How It Works

Abseil Team's avatar
Abseil Team committed
525
526
See [Death Assertions](reference/assertions.md#death) in the Assertions
Reference.
Gennadiy Civil's avatar
Gennadiy Civil committed
527
528

### Death Tests And Threads
529
530
531
532
533
534
535
536

The reason for the two death test styles has to do with thread safety. Due to
well-known problems with forking in the presence of threads, death tests should
be run in a single-threaded context. Sometimes, however, it isn't feasible to
arrange that kind of environment. For example, statically-initialized modules
may start threads before main is ever reached. Once threads have been created,
it may be difficult or impossible to clean them up.

Gennadiy Civil's avatar
Gennadiy Civil committed
537
googletest has three features intended to raise awareness of threading issues.
538

Gennadiy Civil's avatar
Gennadiy Civil committed
539
540
1.  A warning is emitted if multiple threads are running when a death test is
    encountered.
541
542
2.  Test suites with a name ending in "DeathTest" are run before all other
    tests.
Gennadiy Civil's avatar
Gennadiy Civil committed
543
544
545
3.  It uses `clone()` instead of `fork()` to spawn the child process on Linux
    (`clone()` is not available on Cygwin and Mac), as `fork()` is more likely
    to cause the child to hang when the parent process has multiple threads.
546
547
548
549

It's perfectly fine to create threads inside a death test statement; they are
executed in a separate process and cannot affect the parent.

Gennadiy Civil's avatar
Gennadiy Civil committed
550
551
### Death Test Styles

552
553
554
555
The "threadsafe" death test style was introduced in order to help mitigate the
risks of testing in a possibly multithreaded environment. It trades increased
test execution time (potentially dramatically so) for improved thread safety.

Gennadiy Civil's avatar
Gennadiy Civil committed
556
557
The automated testing framework does not set the style flag. You can choose a
particular style of death tests by setting the flag programmatically:
558

Gennadiy Civil's avatar
Gennadiy Civil committed
559
560
```c++
testing::FLAGS_gtest_death_test_style="threadsafe"
561
562
```

Gennadiy Civil's avatar
Gennadiy Civil committed
563
564
565
566
567
568
You can do this in `main()` to set the style for all death tests in the binary,
or in individual tests. Recall that flags are saved before running each test and
restored afterwards, so you need not do that yourself. For example:

```c++
int main(int argc, char** argv) {
Abseil Team's avatar
Abseil Team committed
569
  testing::InitGoogleTest(&argc, argv);
Abseil Team's avatar
Abseil Team committed
570
  GTEST_FLAG_SET(gtest_death_test_style, "fast");
Gennadiy Civil's avatar
Gennadiy Civil committed
571
572
  return RUN_ALL_TESTS();
}
573
574

TEST(MyDeathTest, TestOne) {
Abseil Team's avatar
Abseil Team committed
575
  GTEST_FLAG_SET(gtest_death_test_style, "threadsafe");
576
577
578
579
580
581
582
583
584
585
  // This test is run in the "threadsafe" style:
  ASSERT_DEATH(ThisShouldDie(), "");
}

TEST(MyDeathTest, TestTwo) {
  // This test is run in the "fast" style:
  ASSERT_DEATH(ThisShouldDie(), "");
}
```

Gennadiy Civil's avatar
Gennadiy Civil committed
586
### Caveats
587

Gennadiy Civil's avatar
Gennadiy Civil committed
588
589
590
591
592
593
594
595
The `statement` argument of `ASSERT_EXIT()` can be any valid C++ statement. If
it leaves the current function via a `return` statement or by throwing an
exception, the death test is considered to have failed. Some googletest macros
may return from the current function (e.g. `ASSERT_TRUE()`), so be sure to avoid
them in `statement`.

Since `statement` runs in the child process, any in-memory side effect (e.g.
modifying a variable, releasing memory, etc) it causes will *not* be observable
596
597
598
599
in the parent process. In particular, if you release memory in a death test,
your program will fail the heap check as the parent process will never see the
memory reclaimed. To solve this problem, you can

Gennadiy Civil's avatar
Gennadiy Civil committed
600
601
602
1.  try not to free memory in a death test;
2.  free the memory again in the parent process; or
3.  do not use the heap checker in your program.
603

Gennadiy Civil's avatar
Gennadiy Civil committed
604
605
606
Due to an implementation detail, you cannot place multiple death test assertions
on the same line; otherwise, compilation will fail with an unobvious error
message.
607
608
609
610
611

Despite the improved thread safety afforded by the "threadsafe" style of death
test, thread problems such as deadlock are still possible in the presence of
handlers registered with `pthread_atfork(3)`.

Gennadiy Civil's avatar
Gennadiy Civil committed
612
613
## Using Assertions in Sub-routines

Abseil Team's avatar
Abseil Team committed
614
{: .callout .note}
krzysio's avatar
krzysio committed
615
616
Note: If you want to put a series of test assertions in a subroutine to check
for a complex condition, consider using
Abseil Team's avatar
Abseil Team committed
617
618
619
[a custom GMock matcher](gmock_cook_book.md#NewMatchers) instead. This lets you
provide a more readable error message in case of failure and avoid all of the
issues described below.
krzysio's avatar
krzysio committed
620

Gennadiy Civil's avatar
Gennadiy Civil committed
621
### Adding Traces to Assertions
622

Gennadiy Civil's avatar
Gennadiy Civil committed
623
624
If a test sub-routine is called from several places, when an assertion inside it
fails, it can be hard to tell which invocation of the sub-routine the failure is
625
626
627
from. You can alleviate this problem using extra logging or custom failure
messages, but that usually clutters up your tests. A better solution is to use
the `SCOPED_TRACE` macro or the `ScopedTrace` utility:
628

Gennadiy Civil's avatar
Gennadiy Civil committed
629
630
```c++
SCOPED_TRACE(message);
Abseil Team's avatar
Abseil Team committed
631
```
Abseil Team's avatar
Abseil Team committed
632

Abseil Team's avatar
Abseil Team committed
633
```c++
Gennadiy Civil's avatar
Gennadiy Civil committed
634
635
ScopedTrace trace("file_path", line_number, message);
```
636

Fedor Trushkin's avatar
Fedor Trushkin committed
637
638
639
640
641
where `message` can be anything streamable to `std::ostream`. `SCOPED_TRACE`
macro will cause the current file name, line number, and the given message to be
added in every failure message. `ScopedTrace` accepts explicit file name and
line number in arguments, which is useful for writing test helpers. The effect
will be undone when the control leaves the current lexical scope.
642
643
644

For example,

Gennadiy Civil's avatar
Gennadiy Civil committed
645
```c++
646
10: void Sub1(int n) {
647
648
11:   EXPECT_EQ(Bar(n), 1);
12:   EXPECT_EQ(Bar(n + 1), 2);
649
13: }
Caleb Morse's avatar
Caleb Morse committed
650
14:
651
652
653
654
655
656
657
658
659
660
661
662
663
15: TEST(FooTest, Bar) {
16:   {
17:     SCOPED_TRACE("A");  // This trace point will be included in
18:                         // every failure in this scope.
19:     Sub1(1);
20:   }
21:   // Now it won't.
22:   Sub1(9);
23: }
```

could result in messages like these:

Gennadiy Civil's avatar
Gennadiy Civil committed
664
```none
665
666
667
668
path/to/foo_test.cc:11: Failure
Value of: Bar(n)
Expected: 1
  Actual: 2
Abseil Team's avatar
Abseil Team committed
669
Google Test trace:
670
671
672
673
674
675
676
677
path/to/foo_test.cc:17: A

path/to/foo_test.cc:12: Failure
Value of: Bar(n + 1)
Expected: 2
  Actual: 3
```

Gennadiy Civil's avatar
Gennadiy Civil committed
678
Without the trace, it would've been difficult to know which invocation of
679
680
681
`Sub1()` the two failures come from respectively. (You could add an extra
message to each assertion in `Sub1()` to indicate the value of `n`, but that's
tedious.)
682
683
684

Some tips on using `SCOPED_TRACE`:

Gennadiy Civil's avatar
Gennadiy Civil committed
685
686
687
688
689
690
691
692
693
694
695
696
697
1.  With a suitable message, it's often enough to use `SCOPED_TRACE` at the
    beginning of a sub-routine, instead of at each call site.
2.  When calling sub-routines inside a loop, make the loop iterator part of the
    message in `SCOPED_TRACE` such that you can know which iteration the failure
    is from.
3.  Sometimes the line number of the trace point is enough for identifying the
    particular invocation of a sub-routine. In this case, you don't have to
    choose a unique message for `SCOPED_TRACE`. You can simply use `""`.
4.  You can use `SCOPED_TRACE` in an inner scope when there is one in the outer
    scope. In this case, all active trace points will be included in the failure
    messages, in reverse order they are encountered.
5.  The trace dump is clickable in Emacs - hit `return` on a line number and
    you'll be taken to that line in the source file!
698

Gennadiy Civil's avatar
Gennadiy Civil committed
699
### Propagating Fatal Failures
700
701
702
703

A common pitfall when using `ASSERT_*` and `FAIL*` is not understanding that
when they fail they only abort the _current function_, not the entire test. For
example, the following test will segfault:
Gennadiy Civil's avatar
Gennadiy Civil committed
704
705

```c++
706
707
708
void Subroutine() {
  // Generates a fatal failure and aborts the current function.
  ASSERT_EQ(1, 2);
Gennadiy Civil's avatar
Gennadiy Civil committed
709

710
711
712
713
714
  // The following won't be executed.
  ...
}

TEST(FooTest, Bar) {
Gennadiy Civil's avatar
Gennadiy Civil committed
715
716
717
  Subroutine();  // The intended behavior is for the fatal failure
                 // in Subroutine() to abort the entire test.

718
  // The actual behavior: the function goes on after Subroutine() returns.
Abseil Team's avatar
Abseil Team committed
719
  int* p = nullptr;
Gennadiy Civil's avatar
Gennadiy Civil committed
720
  *p = 3;  // Segfault!
721
722
723
}
```

Gennadiy Civil's avatar
Gennadiy Civil committed
724
To alleviate this, googletest provides three different solutions. You could use
725
726
either exceptions, the `(ASSERT|EXPECT)_NO_FATAL_FAILURE` assertions or the
`HasFatalFailure()` function. They are described in the following two
727
728
subsections.

729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
#### Asserting on Subroutines with an exception

The following code can turn ASSERT-failure into an exception:

```c++
class ThrowListener : public testing::EmptyTestEventListener {
  void OnTestPartResult(const testing::TestPartResult& result) override {
    if (result.type() == testing::TestPartResult::kFatalFailure) {
      throw testing::AssertionException(result);
    }
  }
};
int main(int argc, char** argv) {
  ...
  testing::UnitTest::GetInstance()->listeners().Append(new ThrowListener);
  return RUN_ALL_TESTS();
}
```

This listener should be added after other listeners if you have any, otherwise
they won't see failed `OnTestPartResult`.

Gennadiy Civil's avatar
Gennadiy Civil committed
751
#### Asserting on Subroutines
752

Gennadiy Civil's avatar
Gennadiy Civil committed
753
754
755
As shown above, if your test calls a subroutine that has an `ASSERT_*` failure
in it, the test will continue after the subroutine returns. This may not be what
you want.
756

Gennadiy Civil's avatar
Gennadiy Civil committed
757
758
Often people want fatal failures to propagate like exceptions. For that
googletest offers the following macros:
759

Gennadiy Civil's avatar
Gennadiy Civil committed
760
761
762
Fatal assertion                       | Nonfatal assertion                    | Verifies
------------------------------------- | ------------------------------------- | --------
`ASSERT_NO_FATAL_FAILURE(statement);` | `EXPECT_NO_FATAL_FAILURE(statement);` | `statement` doesn't generate any new fatal failures in the current thread.
763

Gennadiy Civil's avatar
Gennadiy Civil committed
764
765
766
Only failures in the thread that executes the assertion are checked to determine
the result of this type of assertions. If `statement` creates new threads,
failures in these threads are ignored.
767
768
769

Examples:

Gennadiy Civil's avatar
Gennadiy Civil committed
770
```c++
771
772
773
774
775
776
777
778
ASSERT_NO_FATAL_FAILURE(Foo());

int i;
EXPECT_NO_FATAL_FAILURE({
  i = Bar();
});
```

779
Assertions from multiple threads are currently not supported on Windows.
780

Gennadiy Civil's avatar
Gennadiy Civil committed
781
#### Checking for Failures in the Current Test
782
783

`HasFatalFailure()` in the `::testing::Test` class returns `true` if an
Gennadiy Civil's avatar
Gennadiy Civil committed
784
785
assertion in the current test has suffered a fatal failure. This allows
functions to catch fatal failures in a sub-routine and return early.
786

Gennadiy Civil's avatar
Gennadiy Civil committed
787
```c++
788
789
790
791
792
793
794
class Test {
 public:
  ...
  static bool HasFatalFailure();
};
```

Gennadiy Civil's avatar
Gennadiy Civil committed
795
796
The typical usage, which basically simulates the behavior of a thrown exception,
is:
797

Gennadiy Civil's avatar
Gennadiy Civil committed
798
```c++
799
800
801
TEST(FooTest, Bar) {
  Subroutine();
  // Aborts if Subroutine() had a fatal failure.
Gennadiy Civil's avatar
Gennadiy Civil committed
802
803
  if (HasFatalFailure()) return;

804
805
806
807
808
809
810
811
  // The following won't be executed.
  ...
}
```

If `HasFatalFailure()` is used outside of `TEST()` , `TEST_F()` , or a test
fixture, you must add the `::testing::Test::` prefix, as in:

Gennadiy Civil's avatar
Gennadiy Civil committed
812
```c++
Abseil Team's avatar
Abseil Team committed
813
if (testing::Test::HasFatalFailure()) return;
814
815
```

Gennadiy Civil's avatar
Gennadiy Civil committed
816
817
818
Similarly, `HasNonfatalFailure()` returns `true` if the current test has at
least one non-fatal failure, and `HasFailure()` returns `true` if the current
test has at least one failure of either kind.
819

Gennadiy Civil's avatar
Gennadiy Civil committed
820
## Logging Additional Information
821

Gennadiy Civil's avatar
Gennadiy Civil committed
822
823
In your test code, you can call `RecordProperty("key", value)` to log additional
information, where `value` can be either a string or an `int`. The *last* value
824
825
826
recorded for a key will be emitted to the
[XML output](#generating-an-xml-report) if you specify one. For example, the
test
827

Gennadiy Civil's avatar
Gennadiy Civil committed
828
```c++
829
830
831
832
833
834
835
836
TEST_F(WidgetUsageTest, MinAndMaxWidgets) {
  RecordProperty("MaximumWidgets", ComputeMaxUsage());
  RecordProperty("MinimumWidgets", ComputeMinUsage());
}
```

will output XML like this:

Gennadiy Civil's avatar
Gennadiy Civil committed
837
838
839
840
```xml
  ...
    <testcase name="MinAndMaxWidgets" status="run" time="0.006" classname="WidgetUsageTest" MaximumWidgets="12" MinimumWidgets="9" />
  ...
841
842
```

Abseil Team's avatar
Abseil Team committed
843
{: .callout .note}
Gennadiy Civil's avatar
Gennadiy Civil committed
844
845
846
847
848
> NOTE:
>
> *   `RecordProperty()` is a static member of the `Test` class. Therefore it
>     needs to be prefixed with `::testing::Test::` if used outside of the
>     `TEST` body and the test fixture class.
hyuk.myeong's avatar
hyuk.myeong committed
849
> *   *`key`* must be a valid XML attribute name, and cannot conflict with the
Gennadiy Civil's avatar
Gennadiy Civil committed
850
851
852
>     ones already used by googletest (`name`, `status`, `time`, `classname`,
>     `type_param`, and `value_param`).
> *   Calling `RecordProperty()` outside of the lifespan of a test is allowed.
853
>     If it's called outside of a test but between a test suite's
854
855
856
857
858
>     `SetUpTestSuite()` and `TearDownTestSuite()` methods, it will be
>     attributed to the XML element for the test suite. If it's called outside
>     of all test suites (e.g. in a test environment), it will be attributed to
>     the top-level XML element.

859
## Sharing Resources Between Tests in the Same Test Suite
860

Gennadiy Civil's avatar
Gennadiy Civil committed
861
googletest creates a new test fixture object for each test in order to make
862
863
864
865
tests independent and easier to debug. However, sometimes tests use resources
that are expensive to set up, making the one-copy-per-test model prohibitively
expensive.

Gennadiy Civil's avatar
Gennadiy Civil committed
866
867
If the tests don't change the resource, there's no harm in their sharing a
single resource copy. So, in addition to per-test set-up/tear-down, googletest
868
also supports per-test-suite set-up/tear-down. To use it:
869

Gennadiy Civil's avatar
Gennadiy Civil committed
870
871
1.  In your test fixture class (say `FooTest` ), declare as `static` some member
    variables to hold the shared resources.
872
2.  Outside your test fixture class (typically just below it), define those
Gennadiy Civil's avatar
Gennadiy Civil committed
873
    member variables, optionally giving them initial values.
874
3.  In the same test fixture class, define a `static void SetUpTestSuite()`
875
876
    function (remember not to spell it as **`SetupTestSuite`** with a small
    `u`!) to set up the shared resources and a `static void TearDownTestSuite()`
Gennadiy Civil's avatar
Gennadiy Civil committed
877
878
    function to tear them down.

879
880
881
That's it! googletest automatically calls `SetUpTestSuite()` before running the
*first test* in the `FooTest` test suite (i.e. before creating the first
`FooTest` object), and calls `TearDownTestSuite()` after running the *last test*
Gennadiy Civil's avatar
Gennadiy Civil committed
882
883
in it (i.e. after deleting the last `FooTest` object). In between, the tests can
use the shared resources.
884
885

Remember that the test order is undefined, so your code can't depend on a test
Gennadiy Civil's avatar
Gennadiy Civil committed
886
887
888
preceding or following another. Also, the tests must either not modify the state
of any shared resource, or, if they do modify the state, they must restore the
state to its original value before passing control to the next test.
889

890
Here's an example of per-test-suite set-up and tear-down:
Gennadiy Civil's avatar
Gennadiy Civil committed
891
892

```c++
Abseil Team's avatar
Abseil Team committed
893
class FooTest : public testing::Test {
894
 protected:
895
896
  // Per-test-suite set-up.
  // Called before the first test in this test suite.
897
  // Can be omitted if not needed.
898
  static void SetUpTestSuite() {
899
900
901
    shared_resource_ = new ...;
  }

902
903
  // Per-test-suite tear-down.
  // Called after the last test in this test suite.
904
  // Can be omitted if not needed.
905
  static void TearDownTestSuite() {
906
    delete shared_resource_;
Abseil Team's avatar
Abseil Team committed
907
    shared_resource_ = nullptr;
908
909
  }

Gennadiy Civil's avatar
Gennadiy Civil committed
910
  // You can define per-test set-up logic as usual.
Abseil Team's avatar
Abseil Team committed
911
  void SetUp() override { ... }
Gennadiy Civil's avatar
Gennadiy Civil committed
912
913

  // You can define per-test tear-down logic as usual.
Abseil Team's avatar
Abseil Team committed
914
  void TearDown() override { ... }
915
916
917
918
919

  // Some expensive resource shared by all tests.
  static T* shared_resource_;
};

Abseil Team's avatar
Abseil Team committed
920
T* FooTest::shared_resource_ = nullptr;
921
922

TEST_F(FooTest, Test1) {
Gennadiy Civil's avatar
Gennadiy Civil committed
923
  ... you can refer to shared_resource_ here ...
924
}
Gennadiy Civil's avatar
Gennadiy Civil committed
925

926
TEST_F(FooTest, Test2) {
Gennadiy Civil's avatar
Gennadiy Civil committed
927
  ... you can refer to shared_resource_ here ...
928
929
930
}
```

Abseil Team's avatar
Abseil Team committed
931
{: .callout .note}
932
NOTE: Though the above code declares `SetUpTestSuite()` protected, it may
Gennadiy Civil's avatar
Gennadiy Civil committed
933
934
935
936
sometimes be necessary to declare it public, such as when using it with
`TEST_P`.

## Global Set-Up and Tear-Down
937

938
Just as you can do set-up and tear-down at the test level and the test suite
939
940
941
942
943
level, you can also do it at the test program level. Here's how.

First, you subclass the `::testing::Environment` class to define a test
environment, which knows how to set-up and tear-down:

Gennadiy Civil's avatar
Gennadiy Civil committed
944
```c++
Abseil Team's avatar
Abseil Team committed
945
class Environment : public ::testing::Environment {
946
 public:
Abseil Team's avatar
Abseil Team committed
947
  ~Environment() override {}
Gennadiy Civil's avatar
Gennadiy Civil committed
948

949
  // Override this to define how to set up the environment.
950
  void SetUp() override {}
Gennadiy Civil's avatar
Gennadiy Civil committed
951

952
  // Override this to define how to tear down the environment.
953
  void TearDown() override {}
954
955
956
};
```

Gennadiy Civil's avatar
Gennadiy Civil committed
957
Then, you register an instance of your environment class with googletest by
958
959
calling the `::testing::AddGlobalTestEnvironment()` function:

Gennadiy Civil's avatar
Gennadiy Civil committed
960
```c++
961
962
963
964
Environment* AddGlobalTestEnvironment(Environment* env);
```

Now, when `RUN_ALL_TESTS()` is called, it first calls the `SetUp()` method of
965
966
each environment object, then runs the tests if none of the environments
reported fatal failures and `GTEST_SKIP()` was not called. `RUN_ALL_TESTS()`
967
968
always calls `TearDown()` with each environment object, regardless of whether or
not the tests were run.
969

970
It's OK to register multiple environment objects. In this suite, their `SetUp()`
971
972
973
will be called in the order they are registered, and their `TearDown()` will be
called in the reverse order.

Gennadiy Civil's avatar
Gennadiy Civil committed
974
Note that googletest takes ownership of the registered environment objects.
975
976
Therefore **do not delete them** by yourself.

Gennadiy Civil's avatar
Gennadiy Civil committed
977
978
979
980
You should call `AddGlobalTestEnvironment()` before `RUN_ALL_TESTS()` is called,
probably in `main()`. If you use `gtest_main`, you need to call this before
`main()` starts for it to take effect. One way to do this is to define a global
variable like this:
981

Gennadiy Civil's avatar
Gennadiy Civil committed
982
```c++
Abseil Team's avatar
Abseil Team committed
983
984
testing::Environment* const foo_env =
    testing::AddGlobalTestEnvironment(new FooEnvironment);
985
986
987
988
```

However, we strongly recommend you to write your own `main()` and call
`AddGlobalTestEnvironment()` there, as relying on initialization of global
Gennadiy Civil's avatar
Gennadiy Civil committed
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
variables makes the code harder to read and may cause problems when you register
multiple environments from different translation units and the environments have
dependencies among them (remember that the compiler doesn't guarantee the order
in which global variables from different translation units are initialized).

## Value-Parameterized Tests

*Value-parameterized tests* allow you to test your code with different
parameters without writing multiple copies of the same test. This is useful in a
number of situations, for example:

*   You have a piece of code whose behavior is affected by one or more
    command-line flags. You want to make sure your code performs correctly for
    various values of those flags.
*   You want to test different implementations of an OO interface.
*   You want to test your code over various inputs (a.k.a. data-driven testing).
    This feature is easy to abuse, so please exercise your good sense when doing
    it!

### How to Write Value-Parameterized Tests

To write value-parameterized tests, first you should define a fixture class. It
1011
1012
1013
1014
1015
1016
1017
must be derived from both `testing::Test` and `testing::WithParamInterface<T>`
(the latter is a pure interface), where `T` is the type of your parameter
values. For convenience, you can just derive the fixture class from
`testing::TestWithParam<T>`, which itself is derived from both `testing::Test`
and `testing::WithParamInterface<T>`. `T` can be any copyable type. If it's a
raw pointer, you are responsible for managing the lifespan of the pointed
values.
Gennadiy Civil's avatar
Gennadiy Civil committed
1018

Abseil Team's avatar
Abseil Team committed
1019
{: .callout .note}
1020
NOTE: If your test fixture defines `SetUpTestSuite()` or `TearDownTestSuite()`
Gennadiy Civil's avatar
Gennadiy Civil committed
1021
1022
they must be declared **public** rather than **protected** in order to use
`TEST_P`.
1023

Gennadiy Civil's avatar
Gennadiy Civil committed
1024
1025
```c++
class FooTest :
1026
    public testing::TestWithParam<const char*> {
1027
1028
1029
1030
1031
1032
  // You can implement all the usual fixture class members here.
  // To access the test parameter, call GetParam() from class
  // TestWithParam<T>.
};

// Or, when you want to add parameters to a pre-existing fixture class:
1033
class BaseTest : public testing::Test {
1034
1035
1036
  ...
};
class BarTest : public BaseTest,
1037
                public testing::WithParamInterface<const char*> {
1038
1039
1040
1041
  ...
};
```

Gennadiy Civil's avatar
Gennadiy Civil committed
1042
1043
1044
Then, use the `TEST_P` macro to define as many test patterns using this fixture
as you want. The `_P` suffix is for "parameterized" or "pattern", whichever you
prefer to think.
1045

Gennadiy Civil's avatar
Gennadiy Civil committed
1046
```c++
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
TEST_P(FooTest, DoesBlah) {
  // Inside a test, access the test parameter with the GetParam() method
  // of the TestWithParam<T> class:
  EXPECT_TRUE(foo.Blah(GetParam()));
  ...
}

TEST_P(FooTest, HasBlahBlah) {
  ...
}
```

Abseil Team's avatar
Abseil Team committed
1059
1060
1061
1062
1063
Finally, you can use the `INSTANTIATE_TEST_SUITE_P` macro to instantiate the
test suite with any set of parameters you want. GoogleTest defines a number of
functions for generating test parameters—see details at
[`INSTANTIATE_TEST_SUITE_P`](reference/testing.md#INSTANTIATE_TEST_SUITE_P) in
the Testing Reference.
1064

Abseil Team's avatar
Abseil Team committed
1065
1066
1067
For example, the following statement will instantiate tests from the `FooTest`
test suite each with parameter values `"meeny"`, `"miny"`, and `"moe"` using the
[`Values`](reference/testing.md#param-generators) parameter generator:
1068

Gennadiy Civil's avatar
Gennadiy Civil committed
1069
```c++
Abseil Team's avatar
Abseil Team committed
1070
INSTANTIATE_TEST_SUITE_P(MeenyMinyMoe,
1071
1072
                         FooTest,
                         testing::Values("meeny", "miny", "moe"));
1073
1074
```

Abseil Team's avatar
Abseil Team committed
1075
{: .callout .note}
Gennadiy Civil's avatar
Gennadiy Civil committed
1076
1077
NOTE: The code above must be placed at global or namespace scope, not at
function scope.
1078

Abseil Team's avatar
Abseil Team committed
1079
1080
The first argument to `INSTANTIATE_TEST_SUITE_P` is a unique name for the
instantiation of the test suite. The next argument is the name of the test
Abseil Team's avatar
Abseil Team committed
1081
1082
pattern, and the last is the
[parameter generator](reference/testing.md#param-generators).
Abseil Team's avatar
Abseil Team committed
1083

Abseil Team's avatar
Abseil Team committed
1084
1085
1086
1087
You can instantiate a test pattern more than once, so to distinguish different
instances of the pattern, the instantiation name is added as a prefix to the
actual test suite name. Remember to pick unique prefixes for different
instantiations. The tests from the instantiation above will have these names:
Abseil Team's avatar
Abseil Team committed
1088

Abseil Team's avatar
Abseil Team committed
1089
1090
1091
1092
1093
1094
*   `MeenyMinyMoe/FooTest.DoesBlah/0` for `"meeny"`
*   `MeenyMinyMoe/FooTest.DoesBlah/1` for `"miny"`
*   `MeenyMinyMoe/FooTest.DoesBlah/2` for `"moe"`
*   `MeenyMinyMoe/FooTest.HasBlahBlah/0` for `"meeny"`
*   `MeenyMinyMoe/FooTest.HasBlahBlah/1` for `"miny"`
*   `MeenyMinyMoe/FooTest.HasBlahBlah/2` for `"moe"`
1095

1096
You can use these names in [`--gtest_filter`](#running-a-subset-of-the-tests).
Gennadiy Civil's avatar
Gennadiy Civil committed
1097

Abseil Team's avatar
Abseil Team committed
1098
The following statement will instantiate all tests from `FooTest` again, each
Abseil Team's avatar
Abseil Team committed
1099
1100
with parameter values `"cat"` and `"dog"` using the
[`ValuesIn`](reference/testing.md#param-generators) parameter generator:
Gennadiy Civil's avatar
Gennadiy Civil committed
1101
1102

```c++
1103
const char* pets[] = {"cat", "dog"};
Abseil Team's avatar
Abseil Team committed
1104
INSTANTIATE_TEST_SUITE_P(Pets, FooTest, testing::ValuesIn(pets));
1105
1106
1107
1108
```

The tests from the instantiation above will have these names:

Abseil Team's avatar
Abseil Team committed
1109
1110
1111
1112
*   `Pets/FooTest.DoesBlah/0` for `"cat"`
*   `Pets/FooTest.DoesBlah/1` for `"dog"`
*   `Pets/FooTest.HasBlahBlah/0` for `"cat"`
*   `Pets/FooTest.HasBlahBlah/1` for `"dog"`
1113

1114
1115
1116
Please note that `INSTANTIATE_TEST_SUITE_P` will instantiate *all* tests in the
given test suite, whether their definitions come before or *after* the
`INSTANTIATE_TEST_SUITE_P` statement.
1117

Abseil Team's avatar
Abseil Team committed
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
Additionally, by default, every `TEST_P` without a corresponding
`INSTANTIATE_TEST_SUITE_P` causes a failing test in test suite
`GoogleTestVerification`. If you have a test suite where that omission is not an
error, for example it is in a library that may be linked in for other reasons or
where the list of test cases is dynamic and may be empty, then this check can be
suppressed by tagging the test suite:

```c++
GTEST_ALLOW_UNINSTANTIATED_PARAMETERIZED_TEST(FooTest);
```

Abseil Team's avatar
Abseil Team committed
1129
1130
You can see [sample7_unittest.cc] and [sample8_unittest.cc] for more examples.

Abseil Team's avatar
Abseil Team committed
1131
1132
[sample7_unittest.cc]: https://github.com/google/googletest/blob/master/googletest/samples/sample7_unittest.cc "Parameterized Test example"
[sample8_unittest.cc]: https://github.com/google/googletest/blob/master/googletest/samples/sample8_unittest.cc "Parameterized Test example with multiple parameters"
1133

Gennadiy Civil's avatar
Gennadiy Civil committed
1134
### Creating Value-Parameterized Abstract Tests
1135

Gennadiy Civil's avatar
Gennadiy Civil committed
1136
1137
1138
1139
1140
1141
1142
1143
In the above, we define and instantiate `FooTest` in the *same* source file.
Sometimes you may want to define value-parameterized tests in a library and let
other people instantiate them later. This pattern is known as *abstract tests*.
As an example of its application, when you are designing an interface you can
write a standard suite of abstract tests (perhaps using a factory function as
the test parameter) that all implementations of the interface are expected to
pass. When someone implements the interface, they can instantiate your suite to
get all the interface-conformance tests for free.
1144
1145
1146

To define abstract tests, you should organize your code like this:

Gennadiy Civil's avatar
Gennadiy Civil committed
1147
1148
1149
1.  Put the definition of the parameterized test fixture class (e.g. `FooTest`)
    in a header file, say `foo_param_test.h`. Think of this as *declaring* your
    abstract tests.
1150
2.  Put the `TEST_P` definitions in `foo_param_test.cc`, which includes
Gennadiy Civil's avatar
Gennadiy Civil committed
1151
1152
1153
    `foo_param_test.h`. Think of this as *implementing* your abstract tests.

Once they are defined, you can instantiate them by including `foo_param_test.h`,
1154
1155
invoking `INSTANTIATE_TEST_SUITE_P()`, and depending on the library target that
contains `foo_param_test.cc`. You can instantiate the same abstract test suite
Gennadiy Civil's avatar
Gennadiy Civil committed
1156
multiple times, possibly in different source files.
1157

Gennadiy Civil's avatar
Gennadiy Civil committed
1158
### Specifying Names for Value-Parameterized Test Parameters
1159

1160
The optional last argument to `INSTANTIATE_TEST_SUITE_P()` allows the user to
Gennadiy Civil's avatar
Gennadiy Civil committed
1161
1162
1163
specify a function or functor that generates custom test name suffixes based on
the test parameters. The function should accept one argument of type
`testing::TestParamInfo<class ParamType>`, and return `std::string`.
1164

Gennadiy Civil's avatar
Gennadiy Civil committed
1165
1166
1167
`testing::PrintToStringParamName` is a builtin test suffix generator that
returns the value of `testing::PrintToString(GetParam())`. It does not work for
`std::string` or C strings.
1168

Abseil Team's avatar
Abseil Team committed
1169
{: .callout .note}
Gennadiy Civil's avatar
Gennadiy Civil committed
1170
NOTE: test names must be non-empty, unique, and may only contain ASCII
1171
alphanumeric characters. In particular, they
Abseil Team's avatar
Abseil Team committed
1172
[should not contain underscores](faq.md#why-should-test-suite-names-and-test-names-not-contain-underscore)
1173

Gennadiy Civil's avatar
Gennadiy Civil committed
1174
```c++
1175
class MyTestSuite : public testing::TestWithParam<int> {};
1176

1177
TEST_P(MyTestSuite, MyTest)
Gennadiy Civil's avatar
Gennadiy Civil committed
1178
1179
1180
{
  std::cout << "Example Test Param: " << GetParam() << std::endl;
}
1181

1182
1183
INSTANTIATE_TEST_SUITE_P(MyGroup, MyTestSuite, testing::Range(0, 10),
                         testing::PrintToStringParamName());
1184
```
Gennadiy Civil's avatar
Gennadiy Civil committed
1185

1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
Providing a custom functor allows for more control over test parameter name
generation, especially for types where the automatic conversion does not
generate helpful parameter names (e.g. strings as demonstrated above). The
following example illustrates this for multiple parameters, an enumeration type
and a string, and also demonstrates how to combine generators. It uses a lambda
for conciseness:

```c++
enum class MyType { MY_FOO = 0, MY_BAR = 1 };

Abseil Team's avatar
Abseil Team committed
1196
class MyTestSuite : public testing::TestWithParam<std::tuple<MyType, std::string>> {
1197
1198
1199
1200
1201
};

INSTANTIATE_TEST_SUITE_P(
    MyGroup, MyTestSuite,
    testing::Combine(
Abseil Team's avatar
Abseil Team committed
1202
        testing::Values(MyType::MY_FOO, MyType::MY_BAR),
Abseil Team's avatar
Abseil Team committed
1203
        testing::Values("A", "B")),
1204
    [](const testing::TestParamInfo<MyTestSuite::ParamType>& info) {
Abseil Team's avatar
Abseil Team committed
1205
      std::string name = absl::StrCat(
Abseil Team's avatar
Abseil Team committed
1206
          std::get<0>(info.param) == MyType::MY_FOO ? "Foo" : "Bar",
1207
          std::get<1>(info.param));
Abseil Team's avatar
Abseil Team committed
1208
      absl::c_replace_if(name, [](char c) { return !std::isalnum(c); }, '_');
1209
1210
1211
1212
1213
      return name;
    });
```

## Typed Tests
Gennadiy Civil's avatar
Gennadiy Civil committed
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233

Suppose you have multiple implementations of the same interface and want to make
sure that all of them satisfy some common requirements. Or, you may have defined
several types that are supposed to conform to the same "concept" and you want to
verify it. In both cases, you want the same test logic repeated for different
types.

While you can write one `TEST` or `TEST_F` for each type you want to test (and
you may even factor the test logic into a function template that you invoke from
the `TEST`), it's tedious and doesn't scale: if you want `m` tests over `n`
types, you'll end up writing `m*n` `TEST`s.

*Typed tests* allow you to repeat the same test logic over a list of types. You
only need to write the test logic once, although you must know the type list
when writing typed tests. Here's how you do it:

First, define a fixture class template. It should be parameterized by a type.
Remember to derive it from `::testing::Test`:

```c++
1234
template <typename T>
Abseil Team's avatar
Abseil Team committed
1235
class FooTest : public testing::Test {
1236
1237
 public:
  ...
Abseil Team's avatar
Abseil Team committed
1238
  using List = std::list<T>;
1239
1240
1241
1242
1243
  static T shared_;
  T value_;
};
```

1244
Next, associate a list of types with the test suite, which will be repeated for
Gennadiy Civil's avatar
Gennadiy Civil committed
1245
each type in the list:
1246

Gennadiy Civil's avatar
Gennadiy Civil committed
1247
1248
```c++
using MyTypes = ::testing::Types<char, int, unsigned int>;
1249
TYPED_TEST_SUITE(FooTest, MyTypes);
1250
1251
```

1252
The type alias (`using` or `typedef`) is necessary for the `TYPED_TEST_SUITE`
Gennadiy Civil's avatar
Gennadiy Civil committed
1253
1254
macro to parse correctly. Otherwise the compiler will think that each comma in
the type list introduces a new macro argument.
1255

Gennadiy Civil's avatar
Gennadiy Civil committed
1256
Then, use `TYPED_TEST()` instead of `TEST_F()` to define a typed test for this
1257
test suite. You can repeat this as many times as you want:
1258

Gennadiy Civil's avatar
Gennadiy Civil committed
1259
```c++
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
TYPED_TEST(FooTest, DoesBlah) {
  // Inside a test, refer to the special name TypeParam to get the type
  // parameter.  Since we are inside a derived class template, C++ requires
  // us to visit the members of FooTest via 'this'.
  TypeParam n = this->value_;

  // To visit static members of the fixture, add the 'TestFixture::'
  // prefix.
  n += TestFixture::shared_;

  // To refer to typedefs in the fixture, add the 'typename TestFixture::'
  // prefix.  The 'typename' is required to satisfy the compiler.
  typename TestFixture::List values;
Gennadiy Civil's avatar
Gennadiy Civil committed
1273

1274
1275
1276
1277
1278
1279
1280
  values.push_back(n);
  ...
}

TYPED_TEST(FooTest, HasPropertyA) { ... }
```

Abseil Team's avatar
Abseil Team committed
1281
1282
You can see [sample6_unittest.cc] for a complete example.

Abseil Team's avatar
Abseil Team committed
1283
[sample6_unittest.cc]: https://github.com/google/googletest/blob/master/googletest/samples/sample6_unittest.cc "Typed Test example"
1284

Gennadiy Civil's avatar
Gennadiy Civil committed
1285
## Type-Parameterized Tests
1286

Gennadiy Civil's avatar
Gennadiy Civil committed
1287
1288
1289
1290
*Type-parameterized tests* are like typed tests, except that they don't require
you to know the list of types ahead of time. Instead, you can define the test
logic first and instantiate it with different type lists later. You can even
instantiate it more than once in the same program.
1291

Gennadiy Civil's avatar
Gennadiy Civil committed
1292
1293
1294
1295
1296
1297
If you are designing an interface or concept, you can define a suite of
type-parameterized tests to verify properties that any valid implementation of
the interface/concept should have. Then, the author of each implementation can
just instantiate the test suite with their type to verify that it conforms to
the requirements, without having to write similar tests repeatedly. Here's an
example:
1298
1299
1300

First, define a fixture class template, as we did with typed tests:

Gennadiy Civil's avatar
Gennadiy Civil committed
1301
```c++
1302
template <typename T>
Abseil Team's avatar
Abseil Team committed
1303
class FooTest : public testing::Test {
1304
1305
1306
1307
  ...
};
```

1308
Next, declare that you will define a type-parameterized test suite:
1309

Gennadiy Civil's avatar
Gennadiy Civil committed
1310
```c++
1311
TYPED_TEST_SUITE_P(FooTest);
1312
1313
```

Gennadiy Civil's avatar
Gennadiy Civil committed
1314
1315
Then, use `TYPED_TEST_P()` to define a type-parameterized test. You can repeat
this as many times as you want:
1316

Gennadiy Civil's avatar
Gennadiy Civil committed
1317
```c++
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
TYPED_TEST_P(FooTest, DoesBlah) {
  // Inside a test, refer to TypeParam to get the type parameter.
  TypeParam n = 0;
  ...
}

TYPED_TEST_P(FooTest, HasPropertyA) { ... }
```

Now the tricky part: you need to register all test patterns using the
1328
`REGISTER_TYPED_TEST_SUITE_P` macro before you can instantiate them. The first
1329
1330
argument of the macro is the test suite name; the rest are the names of the
tests in this test suite:
1331

Gennadiy Civil's avatar
Gennadiy Civil committed
1332
```c++
1333
REGISTER_TYPED_TEST_SUITE_P(FooTest,
1334
                            DoesBlah, HasPropertyA);
1335
1336
```

Gennadiy Civil's avatar
Gennadiy Civil committed
1337
1338
1339
Finally, you are free to instantiate the pattern with the types you want. If you
put the above code in a header file, you can `#include` it in multiple C++
source files and instantiate it multiple times.
1340

Gennadiy Civil's avatar
Gennadiy Civil committed
1341
```c++
Abseil Team's avatar
Abseil Team committed
1342
using MyTypes = ::testing::Types<char, int, unsigned int>;
1343
INSTANTIATE_TYPED_TEST_SUITE_P(My, FooTest, MyTypes);
1344
1345
```

Gennadiy Civil's avatar
Gennadiy Civil committed
1346
To distinguish different instances of the pattern, the first argument to the
1347
`INSTANTIATE_TYPED_TEST_SUITE_P` macro is a prefix that will be added to the
1348
1349
actual test suite name. Remember to pick unique prefixes for different
instances.
1350

Gennadiy Civil's avatar
Gennadiy Civil committed
1351
1352
In the special case where the type list contains only one type, you can write
that type directly without `::testing::Types<...>`, like this:
1353

Gennadiy Civil's avatar
Gennadiy Civil committed
1354
```c++
1355
INSTANTIATE_TYPED_TEST_SUITE_P(My, FooTest, int);
1356
1357
```

Abseil Team's avatar
Abseil Team committed
1358
You can see [sample6_unittest.cc] for a complete example.
1359

Gennadiy Civil's avatar
Gennadiy Civil committed
1360
## Testing Private Code
1361
1362

If you change your software's internal implementation, your tests should not
Gennadiy Civil's avatar
Gennadiy Civil committed
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
break as long as the change is not observable by users. Therefore, **per the
black-box testing principle, most of the time you should test your code through
its public interfaces.**

**If you still find yourself needing to test internal implementation code,
consider if there's a better design.** The desire to test internal
implementation is often a sign that the class is doing too much. Consider
extracting an implementation class, and testing it. Then use that implementation
class in the original class.

If you absolutely have to test non-public interface code though, you can. There
are two cases to consider:

*   Static functions ( *not* the same as static member functions!) or unnamed
    namespaces, and
*   Private or protected class members

To test them, we use the following special techniques:

*   Both static functions and definitions/declarations in an unnamed namespace
    are only visible within the same translation unit. To test them, you can
    `#include` the entire `.cc` file being tested in your `*_test.cc` file.
1385
    (#including `.cc` files is not a good way to reuse code - you should not do
Gennadiy Civil's avatar
Gennadiy Civil committed
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
    this in production code!)

    However, a better approach is to move the private code into the
    `foo::internal` namespace, where `foo` is the namespace your project
    normally uses, and put the private declarations in a `*-internal.h` file.
    Your production `.cc` files and your tests are allowed to include this
    internal header, but your clients are not. This way, you can fully test your
    internal implementation without leaking it to your clients.

*   Private class members are only accessible from within the class or by
    friends. To access a class' private members, you can declare your test
    fixture as a friend to the class and define accessors in your fixture. Tests
    using the fixture can then access the private members of your production
    class via the accessors in the fixture. Note that even though your fixture
    is a friend to your production class, your tests are not automatically
    friends to it, as they are technically defined in sub-classes of the
    fixture.

    Another way to test private members is to refactor them into an
    implementation class, which is then declared in a `*-internal.h` file. Your
    clients aren't allowed to include this header but your tests can. Such is
    called the
    [Pimpl](https://www.gamedev.net/articles/programming/general-and-gameplay-programming/the-c-pimpl-r1794/)
    (Private Implementation) idiom.

    Or, you can declare an individual test as a friend of your class by adding
    this line in the class body:

    ```c++
1415
        FRIEND_TEST(TestSuiteName, TestName);
Gennadiy Civil's avatar
Gennadiy Civil committed
1416
1417
1418
1419
1420
1421
1422
1423
    ```

    For example,

    ```c++
    // foo.h
    class Foo {
      ...
1424
     private:
Gennadiy Civil's avatar
Gennadiy Civil committed
1425
      FRIEND_TEST(FooTest, BarReturnsZeroOnNull);
1426

Gennadiy Civil's avatar
Gennadiy Civil committed
1427
1428
      int Bar(void* x);
    };
1429

Gennadiy Civil's avatar
Gennadiy Civil committed
1430
1431
1432
1433
    // foo_test.cc
    ...
    TEST(FooTest, BarReturnsZeroOnNull) {
      Foo foo;
1434
      EXPECT_EQ(foo.Bar(NULL), 0);  // Uses Foo's private member Bar().
Gennadiy Civil's avatar
Gennadiy Civil committed
1435
1436
    }
    ```
1437

Abseil Team's avatar
Abseil Team committed
1438
1439
1440
1441
1442
    Pay special attention when your class is defined in a namespace. If you want
    your test fixtures and tests to be friends of your class, then they must be
    defined in the exact same namespace (no anonymous or inline namespaces).

    For example, if the code to be tested looks like:
1443

Gennadiy Civil's avatar
Gennadiy Civil committed
1444
1445
    ```c++
    namespace my_namespace {
1446

Gennadiy Civil's avatar
Gennadiy Civil committed
1447
1448
1449
1450
1451
1452
    class Foo {
      friend class FooTest;
      FRIEND_TEST(FooTest, Bar);
      FRIEND_TEST(FooTest, Baz);
      ... definition of the class Foo ...
    };
1453

Gennadiy Civil's avatar
Gennadiy Civil committed
1454
1455
    }  // namespace my_namespace
    ```
1456

Gennadiy Civil's avatar
Gennadiy Civil committed
1457
    Your test code should be something like:
1458

Gennadiy Civil's avatar
Gennadiy Civil committed
1459
1460
    ```c++
    namespace my_namespace {
1461

Abseil Team's avatar
Abseil Team committed
1462
    class FooTest : public testing::Test {
Gennadiy Civil's avatar
Gennadiy Civil committed
1463
1464
1465
     protected:
      ...
    };
1466

Gennadiy Civil's avatar
Gennadiy Civil committed
1467
1468
    TEST_F(FooTest, Bar) { ... }
    TEST_F(FooTest, Baz) { ... }
1469

Gennadiy Civil's avatar
Gennadiy Civil committed
1470
1471
    }  // namespace my_namespace
    ```
1472

Yi Zheng's avatar
Yi Zheng committed
1473
## "Catching" Failures
1474

Gennadiy Civil's avatar
Gennadiy Civil committed
1475
1476
If you are building a testing utility on top of googletest, you'll want to test
your utility. What framework would you use to test it? googletest, of course.
1477

Gennadiy Civil's avatar
Gennadiy Civil committed
1478
1479
1480
1481
The challenge is to verify that your testing utility reports failures correctly.
In frameworks that report a failure by throwing an exception, you could catch
the exception and assert on it. But googletest doesn't use exceptions, so how do
we test that a piece of code generates an expected failure?
1482

Abseil Team's avatar
Abseil Team committed
1483
1484
`"gtest/gtest-spi.h"` contains some constructs to do this.
After #including this header, you can use
1485

Gennadiy Civil's avatar
Gennadiy Civil committed
1486
1487
```c++
  EXPECT_FATAL_FAILURE(statement, substring);
1488
1489
```

Gennadiy Civil's avatar
Gennadiy Civil committed
1490
1491
to assert that `statement` generates a fatal (e.g. `ASSERT_*`) failure in the
current thread whose message contains the given `substring`, or use
1492

Gennadiy Civil's avatar
Gennadiy Civil committed
1493
1494
```c++
  EXPECT_NONFATAL_FAILURE(statement, substring);
1495
1496
```

Gennadiy Civil's avatar
Gennadiy Civil committed
1497
if you are expecting a non-fatal (e.g. `EXPECT_*`) failure.
1498

Gennadiy Civil's avatar
Gennadiy Civil committed
1499
1500
1501
1502
Only failures in the current thread are checked to determine the result of this
type of expectations. If `statement` creates new threads, failures in these
threads are also ignored. If you want to catch failures in other threads as
well, use one of the following macros instead:
1503

Gennadiy Civil's avatar
Gennadiy Civil committed
1504
1505
1506
1507
```c++
  EXPECT_FATAL_FAILURE_ON_ALL_THREADS(statement, substring);
  EXPECT_NONFATAL_FAILURE_ON_ALL_THREADS(statement, substring);
```
1508

Abseil Team's avatar
Abseil Team committed
1509
{: .callout .note}
Gennadiy Civil's avatar
Gennadiy Civil committed
1510
NOTE: Assertions from multiple threads are currently not supported on Windows.
1511
1512
1513

For technical reasons, there are some caveats:

Gennadiy Civil's avatar
Gennadiy Civil committed
1514
1515
1.  You cannot stream a failure message to either macro.

1516
2.  `statement` in `EXPECT_FATAL_FAILURE{_ON_ALL_THREADS}()` cannot reference
Gennadiy Civil's avatar
Gennadiy Civil committed
1517
    local non-static variables or non-static members of `this` object.
1518

1519
3.  `statement` in `EXPECT_FATAL_FAILURE{_ON_ALL_THREADS}()` cannot return a
Gennadiy Civil's avatar
Gennadiy Civil committed
1520
    value.
1521

1522
1523
## Registering tests programmatically

1524
The `TEST` macros handle the vast majority of all use cases, but there are few
Abseil Team's avatar
Abseil Team committed
1525
where runtime registration logic is required. For those cases, the framework
1526
1527
provides the `::testing::RegisterTest` that allows callers to register arbitrary
tests dynamically.
1528
1529

This is an advanced API only to be used when the `TEST` macros are insufficient.
1530
1531
The macros should be preferred when possible, as they avoid most of the
complexity of calling this function.
1532
1533
1534
1535

It provides the following signature:

```c++
1536
template <typename Factory>
1537
TestInfo* RegisterTest(const char* test_suite_name, const char* test_name,
1538
1539
1540
                       const char* type_param, const char* value_param,
                       const char* file, int line, Factory factory);
```
1541
1542

The `factory` argument is a factory callable (move-constructible) object or
1543
1544
1545
function pointer that creates a new instance of the Test object. It handles
ownership to the caller. The signature of the callable is `Fixture*()`, where
`Fixture` is the test fixture class for the test. All tests registered with the
1546
same `test_suite_name` must return the same fixture type. This is checked at
1547
runtime.
1548
1549
1550
1551
1552

The framework will infer the fixture class from the factory and will call the
`SetUpTestSuite` and `TearDownTestSuite` for it.

Must be called before `RUN_ALL_TESTS()` is invoked, otherwise behavior is
1553
undefined.
1554
1555
1556
1557

Use case example:

```c++
Abseil Team's avatar
Abseil Team committed
1558
class MyFixture : public testing::Test {
1559
1560
 public:
  // All of these optional, just like in regular macro usage.
1561
1562
  static void SetUpTestSuite() { ... }
  static void TearDownTestSuite() { ... }
1563
1564
1565
  void SetUp() override { ... }
  void TearDown() override { ... }
};
1566
1567

class MyTest : public MyFixture {
1568
1569
1570
 public:
  explicit MyTest(int data) : data_(data) {}
  void TestBody() override { ... }
1571
1572

 private:
1573
1574
  int data_;
};
1575
1576

void RegisterMyTests(const std::vector<int>& values) {
1577
  for (int v : values) {
Abseil Team's avatar
Abseil Team committed
1578
    testing::RegisterTest(
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592
        "MyFixture", ("Test" + std::to_string(v)).c_str(), nullptr,
        std::to_string(v).c_str(),
        __FILE__, __LINE__,
        // Important to use the fixture type as the return type here.
        [=]() -> MyFixture* { return new MyTest(v); });
  }
}
...
int main(int argc, char** argv) {
  std::vector<int> values_to_test = LoadValuesFromConfig();
  RegisterMyTests(values_to_test);
  ...
  return RUN_ALL_TESTS();
}
Gennadiy Civil's avatar
Gennadiy Civil committed
1593
```
Abseil Team's avatar
Abseil Team committed
1594

Gennadiy Civil's avatar
Gennadiy Civil committed
1595
## Getting the Current Test's Name
1596
1597
1598

Sometimes a function may need to know the name of the currently running test.
For example, you may be using the `SetUp()` method of your test fixture to set
Abseil Team's avatar
Abseil Team committed
1599
1600
the golden file name based on which test is running. The
[`TestInfo`](reference/testing.md#TestInfo) class has this information.
1601

Gennadiy Civil's avatar
Gennadiy Civil committed
1602
To obtain a `TestInfo` object for the currently running test, call
Abseil Team's avatar
Abseil Team committed
1603
1604
`current_test_info()` on the [`UnitTest`](reference/testing.md#UnitTest)
singleton object:
1605

Gennadiy Civil's avatar
Gennadiy Civil committed
1606
1607
1608
```c++
  // Gets information about the currently running test.
  // Do NOT delete the returned object - it's managed by the UnitTest class.
Abseil Team's avatar
Abseil Team committed
1609
1610
  const testing::TestInfo* const test_info =
      testing::UnitTest::GetInstance()->current_test_info();
Gennadiy Civil's avatar
Gennadiy Civil committed
1611

1612
  printf("We are in test %s of test suite %s.\n",
Gennadiy Civil's avatar
Gennadiy Civil committed
1613
         test_info->name(),
1614
         test_info->test_suite_name());
1615
1616
1617
```

`current_test_info()` returns a null pointer if no test is running. In
Abseil Team's avatar
Abseil Team committed
1618
1619
particular, you cannot find the test suite name in `SetUpTestSuite()`,
`TearDownTestSuite()` (where you know the test suite name implicitly), or
1620
1621
functions called from them.

Gennadiy Civil's avatar
Gennadiy Civil committed
1622
## Extending googletest by Handling Test Events
1623

Gennadiy Civil's avatar
Gennadiy Civil committed
1624
1625
googletest provides an **event listener API** to let you receive notifications
about the progress of a test program and test failures. The events you can
1626
listen to include the start and end of the test program, a test suite, or a test
Gennadiy Civil's avatar
Gennadiy Civil committed
1627
1628
1629
method, among others. You may use this API to augment or replace the standard
console output, replace the XML output, or provide a completely different form
of output, such as a GUI or a database. You can also use test events as
1630
1631
checkpoints to implement a resource leak checker, for example.

Gennadiy Civil's avatar
Gennadiy Civil committed
1632
### Defining Event Listeners
1633

Abseil Team's avatar
Abseil Team committed
1634
1635
1636
1637
1638
1639
1640
1641
To define a event listener, you subclass either
[`testing::TestEventListener`](reference/testing.md#TestEventListener) or
[`testing::EmptyTestEventListener`](reference/testing.md#EmptyTestEventListener)
The former is an (abstract) interface, where *each pure virtual method can be
overridden to handle a test event* (For example, when a test starts, the
`OnTestStart()` method will be called.). The latter provides an empty
implementation of all methods in the interface, such that a subclass only needs
to override the methods it cares about.
1642

Gennadiy Civil's avatar
Gennadiy Civil committed
1643
1644
When an event is fired, its context is passed to the handler function as an
argument. The following argument types are used:
1645

Gennadiy Civil's avatar
Gennadiy Civil committed
1646
*   UnitTest reflects the state of the entire test program,
1647
*   TestSuite has information about a test suite, which can contain one or more
Gennadiy Civil's avatar
Gennadiy Civil committed
1648
1649
1650
    tests,
*   TestInfo contains the state of a test, and
*   TestPartResult represents the result of a test assertion.
1651

Gennadiy Civil's avatar
Gennadiy Civil committed
1652
1653
1654
1655
1656
1657
An event handler function can examine the argument it receives to find out
interesting information about the event and the test program's state.

Here's an example:

```c++
Abseil Team's avatar
Abseil Team committed
1658
  class MinimalistPrinter : public testing::EmptyTestEventListener {
1659
    // Called before a test starts.
Abseil Team's avatar
Abseil Team committed
1660
    void OnTestStart(const testing::TestInfo& test_info) override {
1661
      printf("*** Test %s.%s starting.\n",
1662
             test_info.test_suite_name(), test_info.name());
1663
1664
    }

Gennadiy Civil's avatar
Gennadiy Civil committed
1665
    // Called after a failed assertion or a SUCCESS().
Abseil Team's avatar
Abseil Team committed
1666
    void OnTestPartResult(const testing::TestPartResult& test_part_result) override {
1667
1668
1669
1670
1671
1672
1673
1674
      printf("%s in %s:%d\n%s\n",
             test_part_result.failed() ? "*** Failure" : "Success",
             test_part_result.file_name(),
             test_part_result.line_number(),
             test_part_result.summary());
    }

    // Called after a test ends.
Abseil Team's avatar
Abseil Team committed
1675
    void OnTestEnd(const testing::TestInfo& test_info) override {
1676
      printf("*** Test %s.%s ending.\n",
1677
             test_info.test_suite_name(), test_info.name());
1678
1679
1680
1681
    }
  };
```

Gennadiy Civil's avatar
Gennadiy Civil committed
1682
### Using Event Listeners
1683

Gennadiy Civil's avatar
Gennadiy Civil committed
1684
To use the event listener you have defined, add an instance of it to the
Abseil Team's avatar
Abseil Team committed
1685
1686
1687
googletest event listener list (represented by class
[`TestEventListeners`](reference/testing.md#TestEventListeners) - note the "s"
at the end of the name) in your `main()` function, before calling
Gennadiy Civil's avatar
Gennadiy Civil committed
1688
1689
1690
`RUN_ALL_TESTS()`:

```c++
1691
int main(int argc, char** argv) {
Abseil Team's avatar
Abseil Team committed
1692
  testing::InitGoogleTest(&argc, argv);
1693
  // Gets hold of the event listener list.
Abseil Team's avatar
Abseil Team committed
1694
1695
  testing::TestEventListeners& listeners =
      testing::UnitTest::GetInstance()->listeners();
Gennadiy Civil's avatar
Gennadiy Civil committed
1696
  // Adds a listener to the end.  googletest takes the ownership.
1697
1698
1699
1700
1701
  listeners.Append(new MinimalistPrinter);
  return RUN_ALL_TESTS();
}
```

Gennadiy Civil's avatar
Gennadiy Civil committed
1702
1703
1704
1705
1706
1707
There's only one problem: the default test result printer is still in effect, so
its output will mingle with the output from your minimalist printer. To suppress
the default printer, just release it from the event listener list and delete it.
You can do so by adding one line:

```c++
1708
1709
1710
1711
1712
1713
  ...
  delete listeners.Release(listeners.default_result_printer());
  listeners.Append(new MinimalistPrinter);
  return RUN_ALL_TESTS();
```

Gennadiy Civil's avatar
Gennadiy Civil committed
1714
Now, sit back and enjoy a completely different output from your tests. For more
Abseil Team's avatar
Abseil Team committed
1715
1716
details, see [sample9_unittest.cc].

Abseil Team's avatar
Abseil Team committed
1717
[sample9_unittest.cc]: https://github.com/google/googletest/blob/master/googletest/samples/sample9_unittest.cc "Event listener example"
1718

Gennadiy Civil's avatar
Gennadiy Civil committed
1719
1720
1721
1722
1723
1724
1725
You may append more than one listener to the list. When an `On*Start()` or
`OnTestPartResult()` event is fired, the listeners will receive it in the order
they appear in the list (since new listeners are added to the end of the list,
the default text printer and the default XML generator will receive the event
first). An `On*End()` event will be received by the listeners in the *reverse*
order. This allows output by listeners added later to be framed by output from
listeners added earlier.
1726

Gennadiy Civil's avatar
Gennadiy Civil committed
1727
### Generating Failures in Listeners
1728

Gennadiy Civil's avatar
Gennadiy Civil committed
1729
1730
You may use failure-raising macros (`EXPECT_*()`, `ASSERT_*()`, `FAIL()`, etc)
when processing an event. There are some restrictions:
1731

Gennadiy Civil's avatar
Gennadiy Civil committed
1732
1733
1.  You cannot generate any failure in `OnTestPartResult()` (otherwise it will
    cause `OnTestPartResult()` to be called recursively).
1734
2.  A listener that handles `OnTestPartResult()` is not allowed to generate any
Gennadiy Civil's avatar
Gennadiy Civil committed
1735
    failure.
1736

Gennadiy Civil's avatar
Gennadiy Civil committed
1737
1738
1739
1740
When you add listeners to the listener list, you should put listeners that
handle `OnTestPartResult()` *before* listeners that can generate failures. This
ensures that failures generated by the latter are attributed to the right test
by the former.
1741

Abseil Team's avatar
Abseil Team committed
1742
1743
See [sample10_unittest.cc] for an example of a failure-raising listener.

Abseil Team's avatar
Abseil Team committed
1744
[sample10_unittest.cc]: https://github.com/google/googletest/blob/master/googletest/samples/sample10_unittest.cc "Failure-raising listener example"
1745

Gennadiy Civil's avatar
Gennadiy Civil committed
1746
## Running Test Programs: Advanced Options
1747

Gennadiy Civil's avatar
Gennadiy Civil committed
1748
1749
googletest test programs are ordinary executables. Once built, you can run them
directly and affect their behavior via the following environment variables
1750
1751
1752
and/or command line flags. For the flags to work, your programs must call
`::testing::InitGoogleTest()` before calling `RUN_ALL_TESTS()`.

Gennadiy Civil's avatar
Gennadiy Civil committed
1753
1754
To see a list of supported flags and their usage, please run your test program
with the `--help` flag. You can also use `-h`, `-?`, or `/?` for short.
1755

Gennadiy Civil's avatar
Gennadiy Civil committed
1756
1757
If an option is specified both by an environment variable and by a flag, the
latter takes precedence.
1758

Gennadiy Civil's avatar
Gennadiy Civil committed
1759
### Selecting Tests
1760

Gennadiy Civil's avatar
Gennadiy Civil committed
1761
#### Listing Test Names
1762
1763
1764
1765
1766

Sometimes it is necessary to list the available tests in a program before
running them so that a filter may be applied if needed. Including the flag
`--gtest_list_tests` overrides all other flags and lists tests in the following
format:
Gennadiy Civil's avatar
Gennadiy Civil committed
1767
1768

```none
1769
TestSuite1.
1770
1771
  TestName1
  TestName2
1772
TestSuite2.
1773
1774
1775
1776
1777
1778
  TestName
```

None of the tests listed are actually run if the flag is provided. There is no
corresponding environment variable for this flag.

Gennadiy Civil's avatar
Gennadiy Civil committed
1779
#### Running a Subset of the Tests
1780

Gennadiy Civil's avatar
Gennadiy Civil committed
1781
1782
1783
1784
By default, a googletest program runs all tests the user has defined. Sometimes,
you want to run only a subset of the tests (e.g. for debugging or quickly
verifying a change). If you set the `GTEST_FILTER` environment variable or the
`--gtest_filter` flag to a filter string, googletest will only run the tests
1785
whose full names (in the form of `TestSuiteName.TestName`) match the filter.
1786
1787

The format of a filter is a '`:`'-separated list of wildcard patterns (called
Gennadiy Civil's avatar
Gennadiy Civil committed
1788
1789
1790
the *positive patterns*) optionally followed by a '`-`' and another
'`:`'-separated pattern list (called the *negative patterns*). A test matches
the filter if and only if it matches any of the positive patterns but does not
1791
1792
1793
match any of the negative patterns.

A pattern may contain `'*'` (matches any string) or `'?'` (matches any single
1794
1795
character). For convenience, the filter `'*-NegativePatterns'` can be also
written as `'-NegativePatterns'`.
1796

Gennadiy Civil's avatar
Gennadiy Civil committed
1797
For example:
1798

Gennadiy Civil's avatar
Gennadiy Civil committed
1799
1800
1801
*   `./foo_test` Has no flag, and thus runs all its tests.
*   `./foo_test --gtest_filter=*` Also runs everything, due to the single
    match-everything `*` value.
1802
1803
*   `./foo_test --gtest_filter=FooTest.*` Runs everything in test suite
    `FooTest` .
Gennadiy Civil's avatar
Gennadiy Civil committed
1804
1805
1806
1807
*   `./foo_test --gtest_filter=*Null*:*Constructor*` Runs any test whose full
    name contains either `"Null"` or `"Constructor"` .
*   `./foo_test --gtest_filter=-*DeathTest.*` Runs all non-death tests.
*   `./foo_test --gtest_filter=FooTest.*-FooTest.Bar` Runs everything in test
1808
    suite `FooTest` except `FooTest.Bar`.
Gennadiy Civil's avatar
Gennadiy Civil committed
1809
*   `./foo_test --gtest_filter=FooTest.*:BarTest.*-FooTest.Bar:BarTest.Foo` Runs
1810
1811
1812
    everything in test suite `FooTest` except `FooTest.Bar` and everything in
    test suite `BarTest` except `BarTest.Foo`.

Abseil Team's avatar
Abseil Team committed
1813
1814
1815
1816
1817
1818
#### Stop test execution upon first failure

By default, a googletest program runs all tests the user has defined. In some
cases (e.g. iterative test development & execution) it may be desirable stop
test execution upon first failure (trading improved latency for completeness).
If `GTEST_FAIL_FAST` environment variable or `--gtest_fail_fast` flag is set,
Abseil Team's avatar
Abseil Team committed
1819
the test runner will stop execution as soon as the first test failure is found.
Abseil Team's avatar
Abseil Team committed
1820

Gennadiy Civil's avatar
Gennadiy Civil committed
1821
#### Temporarily Disabling Tests
1822
1823
1824
1825
1826
1827

If you have a broken test that you cannot fix right away, you can add the
`DISABLED_` prefix to its name. This will exclude it from execution. This is
better than commenting out the code or using `#if 0`, as disabled tests are
still compiled (and thus won't rot).

1828
If you need to disable all tests in a test suite, you can either add `DISABLED_`
1829
to the front of the name of each test, or alternatively add it to the front of
1830
the test suite name.
1831

Gennadiy Civil's avatar
Gennadiy Civil committed
1832
For example, the following tests won't be run by googletest, even though they
1833
1834
will still be compiled:

Gennadiy Civil's avatar
Gennadiy Civil committed
1835
```c++
1836
1837
1838
// Tests that Foo does Abc.
TEST(FooTest, DISABLED_DoesAbc) { ... }

Abseil Team's avatar
Abseil Team committed
1839
class DISABLED_BarTest : public testing::Test { ... };
1840
1841
1842
1843
1844

// Tests that Bar does Xyz.
TEST_F(DISABLED_BarTest, DoesXyz) { ... }
```

Abseil Team's avatar
Abseil Team committed
1845
{: .callout .note}
Gennadiy Civil's avatar
Gennadiy Civil committed
1846
1847
1848
NOTE: This feature should only be used for temporary pain-relief. You still have
to fix the disabled tests at a later date. As a reminder, googletest will print
a banner warning you if a test program contains any disabled tests.
1849

Abseil Team's avatar
Abseil Team committed
1850
{: .callout .tip}
Abseil Team's avatar
Abseil Team committed
1851
1852
1853
TIP: You can easily count the number of disabled tests you have using
`grep`. This number can be used as a metric for
improving your test quality.
1854

Gennadiy Civil's avatar
Gennadiy Civil committed
1855
#### Temporarily Enabling Disabled Tests
1856

Gennadiy Civil's avatar
Gennadiy Civil committed
1857
1858
1859
1860
1861
To include disabled tests in test execution, just invoke the test program with
the `--gtest_also_run_disabled_tests` flag or set the
`GTEST_ALSO_RUN_DISABLED_TESTS` environment variable to a value other than `0`.
You can combine this with the `--gtest_filter` flag to further select which
disabled tests to run.
1862

Gennadiy Civil's avatar
Gennadiy Civil committed
1863
### Repeating the Tests
1864
1865
1866
1867
1868

Once in a while you'll run into a test whose result is hit-or-miss. Perhaps it
will fail only 1% of the time, making it rather hard to reproduce the bug under
a debugger. This can be a major source of frustration.

Gennadiy Civil's avatar
Gennadiy Civil committed
1869
1870
1871
The `--gtest_repeat` flag allows you to repeat all (or selected) test methods in
a program many times. Hopefully, a flaky test will eventually fail and give you
a chance to debug. Here's how to use it:
1872

Gennadiy Civil's avatar
Gennadiy Civil committed
1873
1874
1875
```none
$ foo_test --gtest_repeat=1000
Repeat foo_test 1000 times and don't stop at failures.
1876

Gennadiy Civil's avatar
Gennadiy Civil committed
1877
1878
$ foo_test --gtest_repeat=-1
A negative count means repeating forever.
1879

Gennadiy Civil's avatar
Gennadiy Civil committed
1880
1881
1882
1883
1884
$ foo_test --gtest_repeat=1000 --gtest_break_on_failure
Repeat foo_test 1000 times, stopping at the first failure.  This
is especially useful when running under a debugger: when the test
fails, it will drop into the debugger and you can then inspect
variables and stacks.
1885

Gennadiy Civil's avatar
Gennadiy Civil committed
1886
1887
1888
1889
$ foo_test --gtest_repeat=1000 --gtest_filter=FooBar.*
Repeat the tests whose name matches the filter 1000 times.
```

1890
1891
1892
1893
If your test program contains
[global set-up/tear-down](#global-set-up-and-tear-down) code, it will be
repeated in each iteration as well, as the flakiness may be in it. You can also
specify the repeat count by setting the `GTEST_REPEAT` environment variable.
Gennadiy Civil's avatar
Gennadiy Civil committed
1894
1895

### Shuffling the Tests
1896
1897

You can specify the `--gtest_shuffle` flag (or set the `GTEST_SHUFFLE`
Gennadiy Civil's avatar
Gennadiy Civil committed
1898
1899
1900
1901
1902
1903
1904
1905
1906
1907
environment variable to `1`) to run the tests in a program in a random order.
This helps to reveal bad dependencies between tests.

By default, googletest uses a random seed calculated from the current time.
Therefore you'll get a different order every time. The console output includes
the random seed value, such that you can reproduce an order-related test failure
later. To specify the random seed explicitly, use the `--gtest_random_seed=SEED`
flag (or set the `GTEST_RANDOM_SEED` environment variable), where `SEED` is an
integer in the range [0, 99999]. The seed value 0 is special: it tells
googletest to do the default behavior of calculating the seed from the current
1908
1909
time.

Gennadiy Civil's avatar
Gennadiy Civil committed
1910
1911
1912
1913
If you combine this with `--gtest_repeat=N`, googletest will pick a different
random seed and re-shuffle the tests in each iteration.

### Controlling Test Output
1914

Gennadiy Civil's avatar
Gennadiy Civil committed
1915
#### Colored Terminal Output
1916

Gennadiy Civil's avatar
Gennadiy Civil committed
1917
1918
googletest can use colors in its terminal output to make it easier to spot the
important information:
1919

Abseil Team's avatar
Abseil Team committed
1920
1921
1922
1923
1924
1925
1926
1927
1928
1929
1930
1931
1932
1933
1934
1935
1936
1937
1938
<pre>...
<font color="green">[----------]</font> 1 test from FooTest
<font color="green">[ RUN      ]</font> FooTest.DoesAbc
<font color="green">[       OK ]</font> FooTest.DoesAbc
<font color="green">[----------]</font> 2 tests from BarTest
<font color="green">[ RUN      ]</font> BarTest.HasXyzProperty
<font color="green">[       OK ]</font> BarTest.HasXyzProperty
<font color="green">[ RUN      ]</font> BarTest.ReturnsTrueOnSuccess
... some error messages ...
<font color="red">[   FAILED ]</font> BarTest.ReturnsTrueOnSuccess
...
<font color="green">[==========]</font> 30 tests from 14 test suites ran.
<font color="green">[   PASSED ]</font> 28 tests.
<font color="red">[   FAILED ]</font> 2 tests, listed below:
<font color="red">[   FAILED ]</font> BarTest.ReturnsTrueOnSuccess
<font color="red">[   FAILED ]</font> AnotherTest.DoesXyz

 2 FAILED TESTS
</pre>
1939

Gennadiy Civil's avatar
Gennadiy Civil committed
1940
You can set the `GTEST_COLOR` environment variable or the `--gtest_color`
1941
command line flag to `yes`, `no`, or `auto` (the default) to enable colors,
Gennadiy Civil's avatar
Gennadiy Civil committed
1942
1943
1944
disable colors, or let googletest decide. When the value is `auto`, googletest
will use colors if and only if the output goes to a terminal and (on non-Windows
platforms) the `TERM` environment variable is set to `xterm` or `xterm-color`.
1945

Calum Robinson's avatar
Calum Robinson committed
1946
1947
1948
1949
1950
1951
#### Suppressing test passes

By default, googletest prints 1 line of output for each test, indicating if it
passed or failed. To show only test failures, run the test program with
`--gtest_brief=1`, or set the GTEST_BRIEF environment variable to `1`.

Gennadiy Civil's avatar
Gennadiy Civil committed
1952
#### Suppressing the Elapsed Time
1953

Gennadiy Civil's avatar
Gennadiy Civil committed
1954
1955
1956
By default, googletest prints the time it takes to run each test. To disable
that, run the test program with the `--gtest_print_time=0` command line flag, or
set the GTEST_PRINT_TIME environment variable to `0`.
1957

Gennadiy Civil's avatar
Gennadiy Civil committed
1958
1959
#### Suppressing UTF-8 Text Output

Gennadiy Civil's avatar
Gennadiy Civil committed
1960
1961
1962
1963
1964
In case of assertion failures, googletest prints expected and actual values of
type `string` both as hex-encoded strings as well as in readable UTF-8 text if
they contain valid non-ASCII UTF-8 characters. If you want to suppress the UTF-8
text because, for example, you don't have an UTF-8 compatible output medium, run
the test program with `--gtest_print_utf8=0` or set the `GTEST_PRINT_UTF8`
Gennadiy Civil's avatar
Gennadiy Civil committed
1965
1966
environment variable to `0`.

Gennadiy Civil's avatar
Gennadiy Civil committed
1967
1968
1969
1970
#### Generating an XML Report

googletest can emit a detailed XML report to a file in addition to its normal
textual output. The report contains the duration of each test, and thus can help
Abseil Team's avatar
Abseil Team committed
1971
you identify slow tests.
1972
1973

To generate the XML report, set the `GTEST_OUTPUT` environment variable or the
Gennadiy Civil's avatar
Gennadiy Civil committed
1974
1975
1976
1977
`--gtest_output` flag to the string `"xml:path_to_output_file"`, which will
create the file at the given location. You can also just use the string `"xml"`,
in which case the output can be found in the `test_detail.xml` file in the
current directory.
1978
1979

If you specify a directory (for example, `"xml:output/directory/"` on Linux or
Gennadiy Civil's avatar
Gennadiy Civil committed
1980
`"xml:output\directory\"` on Windows), googletest will create the XML file in
1981
1982
that directory, named after the test executable (e.g. `foo_test.xml` for test
program `foo_test` or `foo_test.exe`). If the file already exists (perhaps left
Gennadiy Civil's avatar
Gennadiy Civil committed
1983
over from a previous run), googletest will pick a different name (e.g.
1984
1985
`foo_test_1.xml`) to avoid overwriting it.

Gennadiy Civil's avatar
Gennadiy Civil committed
1986
1987
1988
1989
1990
The report is based on the `junitreport` Ant task. Since that format was
originally intended for Java, a little interpretation is required to make it
apply to googletest tests, as shown here:

```xml
1991
<testsuites name="AllTests" ...>
1992
  <testsuite name="test_case_name" ...>
Gennadiy Civil's avatar
Gennadiy Civil committed
1993
    <testcase    name="test_name" ...>
1994
1995
1996
1997
1998
1999
2000
2001
      <failure message="..."/>
      <failure message="..."/>
      <failure message="..."/>
    </testcase>
  </testsuite>
</testsuites>
```

Gennadiy Civil's avatar
Gennadiy Civil committed
2002
*   The root `<testsuites>` element corresponds to the entire test program.
2003
*   `<testsuite>` elements correspond to googletest test suites.
Gennadiy Civil's avatar
Gennadiy Civil committed
2004
*   `<testcase>` elements correspond to googletest test functions.
2005
2006
2007

For instance, the following program

Gennadiy Civil's avatar
Gennadiy Civil committed
2008
```c++
2009
2010
2011
2012
2013
2014
2015
TEST(MathTest, Addition) { ... }
TEST(MathTest, Subtraction) { ... }
TEST(LogicTest, NonContradiction) { ... }
```

could generate this report:

Gennadiy Civil's avatar
Gennadiy Civil committed
2016
```xml
2017
<?xml version="1.0" encoding="UTF-8"?>
Gennadiy Civil's avatar
Gennadiy Civil committed
2018
2019
2020
2021
2022
<testsuites tests="3" failures="1" errors="0" time="0.035" timestamp="2011-10-31T18:52:42" name="AllTests">
  <testsuite name="MathTest" tests="2" failures="1" errors="0" time="0.015">
    <testcase name="Addition" status="run" time="0.007" classname="">
      <failure message="Value of: add(1, 1)&#x0A;  Actual: 3&#x0A;Expected: 2" type="">...</failure>
      <failure message="Value of: add(1, -1)&#x0A;  Actual: 1&#x0A;Expected: 0" type="">...</failure>
2023
    </testcase>
Gennadiy Civil's avatar
Gennadiy Civil committed
2024
    <testcase name="Subtraction" status="run" time="0.005" classname="">
2025
2026
    </testcase>
  </testsuite>
Gennadiy Civil's avatar
Gennadiy Civil committed
2027
2028
  <testsuite name="LogicTest" tests="1" failures="0" errors="0" time="0.005">
    <testcase name="NonContradiction" status="run" time="0.005" classname="">
2029
2030
2031
2032
2033
2034
2035
    </testcase>
  </testsuite>
</testsuites>
```

Things to note:

Gennadiy Civil's avatar
Gennadiy Civil committed
2036
*   The `tests` attribute of a `<testsuites>` or `<testsuite>` element tells how
2037
    many test functions the googletest program or test suite contains, while the
Gennadiy Civil's avatar
Gennadiy Civil committed
2038
2039
    `failures` attribute tells how many of them failed.

2040
*   The `time` attribute expresses the duration of the test, test suite, or
Gennadiy Civil's avatar
Gennadiy Civil committed
2041
2042
2043
2044
    entire test program in seconds.

*   The `timestamp` attribute records the local date and time of the test
    execution.
2045

Gennadiy Civil's avatar
Gennadiy Civil committed
2046
2047
*   Each `<failure>` element corresponds to a single failed googletest
    assertion.
2048

2049
#### Generating a JSON Report
2050

Gennadiy Civil's avatar
Gennadiy Civil committed
2051
2052
2053
googletest can also emit a JSON report as an alternative format to XML. To
generate the JSON report, set the `GTEST_OUTPUT` environment variable or the
`--gtest_output` flag to the string `"json:path_to_output_file"`, which will
2054
2055
2056
2057
2058
2059
2060
2061
2062
2063
2064
create the file at the given location. You can also just use the string
`"json"`, in which case the output can be found in the `test_detail.json` file
in the current directory.

The report format conforms to the following JSON Schema:

```json
{
  "$schema": "http://json-schema.org/schema#",
  "type": "object",
  "definitions": {
2065
    "TestCase": {
2066
2067
2068
2069
2070
2071
2072
2073
2074
2075
2076
2077
2078
2079
2080
2081
2082
2083
2084
2085
2086
2087
2088
2089
2090
2091
2092
2093
2094
2095
2096
2097
2098
2099
2100
2101
2102
2103
2104
2105
2106
2107
2108
2109
2110
2111
2112
2113
2114
2115
2116
2117
2118
2119
2120
      "type": "object",
      "properties": {
        "name": { "type": "string" },
        "tests": { "type": "integer" },
        "failures": { "type": "integer" },
        "disabled": { "type": "integer" },
        "time": { "type": "string" },
        "testsuite": {
          "type": "array",
          "items": {
            "$ref": "#/definitions/TestInfo"
          }
        }
      }
    },
    "TestInfo": {
      "type": "object",
      "properties": {
        "name": { "type": "string" },
        "status": {
          "type": "string",
          "enum": ["RUN", "NOTRUN"]
        },
        "time": { "type": "string" },
        "classname": { "type": "string" },
        "failures": {
          "type": "array",
          "items": {
            "$ref": "#/definitions/Failure"
          }
        }
      }
    },
    "Failure": {
      "type": "object",
      "properties": {
        "failures": { "type": "string" },
        "type": { "type": "string" }
      }
    }
  },
  "properties": {
    "tests": { "type": "integer" },
    "failures": { "type": "integer" },
    "disabled": { "type": "integer" },
    "errors": { "type": "integer" },
    "timestamp": {
      "type": "string",
      "format": "date-time"
    },
    "time": { "type": "string" },
    "name": { "type": "string" },
    "testsuites": {
      "type": "array",
      "items": {
2121
        "$ref": "#/definitions/TestCase"
2122
2123
2124
2125
2126
2127
      }
    }
  }
}
```

2128
2129
The report uses the format that conforms to the following Proto3 using the
[JSON encoding](https://developers.google.com/protocol-buffers/docs/proto3#json):
2130
2131
2132
2133
2134
2135
2136
2137
2138
2139
2140
2141
2142
2143
2144
2145
2146

```proto
syntax = "proto3";

package googletest;

import "google/protobuf/timestamp.proto";
import "google/protobuf/duration.proto";

message UnitTest {
  int32 tests = 1;
  int32 failures = 2;
  int32 disabled = 3;
  int32 errors = 4;
  google.protobuf.Timestamp timestamp = 5;
  google.protobuf.Duration time = 6;
  string name = 7;
2147
  repeated TestCase testsuites = 8;
2148
2149
2150
2151
2152
2153
2154
2155
2156
2157
2158
2159
2160
2161
2162
2163
2164
2165
2166
2167
2168
2169
2170
2171
2172
2173
2174
2175
2176
2177
2178
2179
2180
2181
2182
2183
2184
2185
2186
2187
2188
2189
2190
2191
2192
}

message TestCase {
  string name = 1;
  int32 tests = 2;
  int32 failures = 3;
  int32 disabled = 4;
  int32 errors = 5;
  google.protobuf.Duration time = 6;
  repeated TestInfo testsuite = 7;
}

message TestInfo {
  string name = 1;
  enum Status {
    RUN = 0;
    NOTRUN = 1;
  }
  Status status = 2;
  google.protobuf.Duration time = 3;
  string classname = 4;
  message Failure {
    string failures = 1;
    string type = 2;
  }
  repeated Failure failures = 5;
}
```

For instance, the following program

```c++
TEST(MathTest, Addition) { ... }
TEST(MathTest, Subtraction) { ... }
TEST(LogicTest, NonContradiction) { ... }
```

could generate this report:

```json
{
  "tests": 3,
  "failures": 1,
  "errors": 0,
  "time": "0.035s",
2193
  "timestamp": "2011-10-31T18:52:42Z",
2194
2195
2196
2197
2198
2199
2200
2201
2202
2203
2204
2205
2206
2207
2208
2209
  "name": "AllTests",
  "testsuites": [
    {
      "name": "MathTest",
      "tests": 2,
      "failures": 1,
      "errors": 0,
      "time": "0.015s",
      "testsuite": [
        {
          "name": "Addition",
          "status": "RUN",
          "time": "0.007s",
          "classname": "",
          "failures": [
            {
2210
              "message": "Value of: add(1, 1)\n  Actual: 3\nExpected: 2",
2211
2212
2213
              "type": ""
            },
            {
2214
              "message": "Value of: add(1, -1)\n  Actual: 1\nExpected: 0",
2215
2216
2217
2218
2219
2220
2221
2222
2223
2224
2225
              "type": ""
            }
          ]
        },
        {
          "name": "Subtraction",
          "status": "RUN",
          "time": "0.005s",
          "classname": ""
        }
      ]
2226
    },
2227
2228
2229
2230
2231
2232
2233
2234
2235
2236
2237
2238
2239
2240
2241
2242
2243
2244
2245
    {
      "name": "LogicTest",
      "tests": 1,
      "failures": 0,
      "errors": 0,
      "time": "0.005s",
      "testsuite": [
        {
          "name": "NonContradiction",
          "status": "RUN",
          "time": "0.005s",
          "classname": ""
        }
      ]
    }
  ]
}
```

Abseil Team's avatar
Abseil Team committed
2246
{: .callout .important}
2247
2248
IMPORTANT: The exact format of the JSON document is subject to change.

Gennadiy Civil's avatar
Gennadiy Civil committed
2249
### Controlling How Failures Are Reported
2250

2251
2252
#### Detecting Test Premature Exit

Abseil Team's avatar
Abseil Team committed
2253
2254
2255
2256
2257
Google Test implements the _premature-exit-file_ protocol for test runners to
catch any kind of unexpected exits of test programs. Upon start, Google Test
creates the file which will be automatically deleted after all work has been
finished. Then, the test runner can check if this file exists. In case the file
remains undeleted, the inspected test has exited prematurely.
2258
2259
2260
2261

This feature is enabled only if the `TEST_PREMATURE_EXIT_FILE` environment
variable has been set.

Gennadiy Civil's avatar
Gennadiy Civil committed
2262
#### Turning Assertion Failures into Break-Points
2263
2264
2265

When running test programs under a debugger, it's very convenient if the
debugger can catch an assertion failure and automatically drop into interactive
Gennadiy Civil's avatar
Gennadiy Civil committed
2266
mode. googletest's *break-on-failure* mode supports this behavior.
2267
2268

To enable it, set the `GTEST_BREAK_ON_FAILURE` environment variable to a value
2269
other than `0`. Alternatively, you can use the `--gtest_break_on_failure`
2270
2271
command line flag.

Gennadiy Civil's avatar
Gennadiy Civil committed
2272
#### Disabling Catching Test-Thrown Exceptions
2273

Gennadiy Civil's avatar
Gennadiy Civil committed
2274
2275
2276
2277
2278
2279
googletest can be used either with or without exceptions enabled. If a test
throws a C++ exception or (on Windows) a structured exception (SEH), by default
googletest catches it, reports it as a test failure, and continues with the next
test method. This maximizes the coverage of a test run. Also, on Windows an
uncaught exception will cause a pop-up window, so catching the exceptions allows
you to run the tests automatically.
2280

Gennadiy Civil's avatar
Gennadiy Civil committed
2281
2282
2283
2284
2285
When debugging the test failures, however, you may instead want the exceptions
to be handled by the debugger, such that you can examine the call stack when an
exception is thrown. To achieve that, set the `GTEST_CATCH_EXCEPTIONS`
environment variable to `0`, or use the `--gtest_catch_exceptions=0` flag when
running the tests.
2286
2287
2288
2289
2290
2291
2292
2293
2294
2295
2296
2297
2298
2299
2300
2301
2302
2303
2304
2305
2306
2307
2308
2309
2310
2311
2312
2313
2314

### Sanitizer Integration

The
[Undefined Behavior Sanitizer](https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html),
[Address Sanitizer](https://github.com/google/sanitizers/wiki/AddressSanitizer),
and
[Thread Sanitizer](https://github.com/google/sanitizers/wiki/ThreadSanitizerCppManual)
all provide weak functions that you can override to trigger explicit failures
when they detect sanitizer errors, such as creating a reference from `nullptr`.
To override these functions, place definitions for them in a source file that
you compile as part of your main binary:

```
extern "C" {
void __ubsan_on_report() {
  FAIL() << "Encountered an undefined behavior sanitizer error";
}
void __asan_on_error() {
  FAIL() << "Encountered an address sanitizer error";
}
void __tsan_on_report() {
  FAIL() << "Encountered a thread sanitizer error";
}
}  // extern "C"
```

After compiling your project with one of the sanitizers enabled, if a particular
test triggers a sanitizer error, googletest will report that it failed.