3 <!-- GOOGLETEST_CM0014 DO NOT DELETE -->
5 <!-- GOOGLETEST_CM0035 DO NOT DELETE -->
7 ## Why should test suite names and test names not contain underscore?
9 Note: Googletest reserves underscore (`_`) for special purpose keywords, such as
10 [the `DISABLED_` prefix](advanced.md#temporarily-disabling-tests), in addition
11 to the following rationale.
13 Underscore (`_`) is special, as C++ reserves the following to be used by the
14 compiler and the standard library:
16 1. any identifier that starts with an `_` followed by an upper-case letter, and
17 2. any identifier that contains two consecutive underscores (i.e. `__`)
18 *anywhere* in its name.
20 User code is *prohibited* from using such identifiers.
22 Now let's look at what this means for `TEST` and `TEST_F`.
24 Currently `TEST(TestSuiteName, TestName)` generates a class named
25 `TestSuiteName_TestName_Test`. What happens if `TestSuiteName` or `TestName`
28 1. If `TestSuiteName` starts with an `_` followed by an upper-case letter (say,
29 `_Foo`), we end up with `_Foo_TestName_Test`, which is reserved and thus
31 2. If `TestSuiteName` ends with an `_` (say, `Foo_`), we get
32 `Foo__TestName_Test`, which is invalid.
33 3. If `TestName` starts with an `_` (say, `_Bar`), we get
34 `TestSuiteName__Bar_Test`, which is invalid.
35 4. If `TestName` ends with an `_` (say, `Bar_`), we get
36 `TestSuiteName_Bar__Test`, which is invalid.
38 So clearly `TestSuiteName` and `TestName` cannot start or end with `_`
39 (Actually, `TestSuiteName` can start with `_` -- as long as the `_` isn't
40 followed by an upper-case letter. But that's getting complicated. So for
41 simplicity we just say that it cannot start with `_`.).
43 It may seem fine for `TestSuiteName` and `TestName` to contain `_` in the
44 middle. However, consider this:
47 TEST(Time, Flies_Like_An_Arrow) { ... }
48 TEST(Time_Flies, Like_An_Arrow) { ... }
51 Now, the two `TEST`s will both generate the same class
52 (`Time_Flies_Like_An_Arrow_Test`). That's not good.
54 So for simplicity, we just ask the users to avoid `_` in `TestSuiteName` and
55 `TestName`. The rule is more constraining than necessary, but it's simple and
56 easy to remember. It also gives googletest some wiggle room in case its
57 implementation needs to change in the future.
59 If you violate the rule, there may not be immediate consequences, but your test
60 may (just may) break with a new compiler (or a new version of the compiler you
61 are using) or with a new version of googletest. Therefore it's best to follow
64 ## Why does googletest support `EXPECT_EQ(NULL, ptr)` and `ASSERT_EQ(NULL, ptr)` but not `EXPECT_NE(NULL, ptr)` and `ASSERT_NE(NULL, ptr)`?
66 First of all you can use `EXPECT_NE(nullptr, ptr)` and `ASSERT_NE(nullptr,
67 ptr)`. This is the preferred syntax in the style guide because nullptr does not
68 have the type problems that NULL does. Which is why NULL does not work.
70 Due to some peculiarity of C++, it requires some non-trivial template meta
71 programming tricks to support using `NULL` as an argument of the `EXPECT_XX()`
72 and `ASSERT_XX()` macros. Therefore we only do it where it's most needed
73 (otherwise we make the implementation of googletest harder to maintain and more
74 error-prone than necessary).
76 The `EXPECT_EQ()` macro takes the *expected* value as its first argument and the
77 *actual* value as the second. It's reasonable that someone wants to write
78 `EXPECT_EQ(NULL, some_expression)`, and this indeed was requested several times.
79 Therefore we implemented it.
81 The need for `EXPECT_NE(NULL, ptr)` isn't nearly as strong. When the assertion
82 fails, you already know that `ptr` must be `NULL`, so it doesn't add any
83 information to print `ptr` in this case. That means `EXPECT_TRUE(ptr != NULL)`
86 If we were to support `EXPECT_NE(NULL, ptr)`, for consistency we'll have to
87 support `EXPECT_NE(ptr, NULL)` as well, as unlike `EXPECT_EQ`, we don't have a
88 convention on the order of the two arguments for `EXPECT_NE`. This means using
89 the template meta programming tricks twice in the implementation, making it even
90 harder to understand and maintain. We believe the benefit doesn't justify the
93 Finally, with the growth of the gMock matcher library, we are encouraging people
94 to use the unified `EXPECT_THAT(value, matcher)` syntax more often in tests. One
95 significant advantage of the matcher approach is that matchers can be easily
96 combined to form new matchers, while the `EXPECT_NE`, etc, macros cannot be
97 easily combined. Therefore we want to invest more in the matchers than in the
100 ## I need to test that different implementations of an interface satisfy some common requirements. Should I use typed tests or value-parameterized tests?
102 For testing various implementations of the same interface, either typed tests or
103 value-parameterized tests can get it done. It's really up to you the user to
104 decide which is more convenient for you, depending on your particular case. Some
107 * Typed tests can be easier to write if instances of the different
108 implementations can be created the same way, modulo the type. For example,
109 if all these implementations have a public default constructor (such that
110 you can write `new TypeParam`), or if their factory functions have the same
111 form (e.g. `CreateInstance<TypeParam>()`).
112 * Value-parameterized tests can be easier to write if you need different code
113 patterns to create different implementations' instances, e.g. `new Foo` vs
114 `new Bar(5)`. To accommodate for the differences, you can write factory
115 function wrappers and pass these function pointers to the tests as their
117 * When a typed test fails, the default output includes the name of the type,
118 which can help you quickly identify which implementation is wrong.
119 Value-parameterized tests only show the number of the failed iteration by
120 default. You will need to define a function that returns the iteration name
121 and pass it as the third parameter to INSTANTIATE_TEST_SUITE_P to have more
123 * When using typed tests, you need to make sure you are testing against the
124 interface type, not the concrete types (in other words, you want to make
125 sure `implicit_cast<MyInterface*>(my_concrete_impl)` works, not just that
126 `my_concrete_impl` works). It's less likely to make mistakes in this area
127 when using value-parameterized tests.
129 I hope I didn't confuse you more. :-) If you don't mind, I'd suggest you to give
130 both approaches a try. Practice is a much better way to grasp the subtle
131 differences between the two tools. Once you have some concrete experience, you
132 can much more easily decide which one to use the next time.
134 ## I got some run-time errors about invalid proto descriptors when using `ProtocolMessageEquals`. Help!
136 **Note:** `ProtocolMessageEquals` and `ProtocolMessageEquiv` are *deprecated*
137 now. Please use `EqualsProto`, etc instead.
139 `ProtocolMessageEquals` and `ProtocolMessageEquiv` were redefined recently and
140 are now less tolerant of invalid protocol buffer definitions. In particular, if
141 you have a `foo.proto` that doesn't fully qualify the type of a protocol message
142 it references (e.g. `message<Bar>` where it should be `message<blah.Bar>`), you
143 will now get run-time errors like:
146 ... descriptor.cc:...] Invalid proto descriptor for file "path/to/foo.proto":
147 ... descriptor.cc:...] blah.MyMessage.my_field: ".Bar" is not defined.
150 If you see this, your `.proto` file is broken and needs to be fixed by making
151 the types fully qualified. The new definition of `ProtocolMessageEquals` and
152 `ProtocolMessageEquiv` just happen to reveal your bug.
154 ## My death test modifies some state, but the change seems lost after the death test finishes. Why?
156 Death tests (`EXPECT_DEATH`, etc) are executed in a sub-process s.t. the
157 expected crash won't kill the test program (i.e. the parent process). As a
158 result, any in-memory side effects they incur are observable in their respective
159 sub-processes, but not in the parent process. You can think of them as running
160 in a parallel universe, more or less.
162 In particular, if you use mocking and the death test statement invokes some mock
163 methods, the parent process will think the calls have never occurred. Therefore,
164 you may want to move your `EXPECT_CALL` statements inside the `EXPECT_DEATH`
167 ## EXPECT_EQ(htonl(blah), blah_blah) generates weird compiler errors in opt mode. Is this a googletest bug?
169 Actually, the bug is in `htonl()`.
171 According to `'man htonl'`, `htonl()` is a *function*, which means it's valid to
172 use `htonl` as a function pointer. However, in opt mode `htonl()` is defined as
173 a *macro*, which breaks this usage.
175 Worse, the macro definition of `htonl()` uses a `gcc` extension and is *not*
176 standard C++. That hacky implementation has some ad hoc limitations. In
177 particular, it prevents you from writing `Foo<sizeof(htonl(x))>()`, where `Foo`
178 is a template that has an integral argument.
180 The implementation of `EXPECT_EQ(a, b)` uses `sizeof(... a ...)` inside a
181 template argument, and thus doesn't compile in opt mode when `a` contains a call
182 to `htonl()`. It is difficult to make `EXPECT_EQ` bypass the `htonl()` bug, as
183 the solution must work with different compilers on various platforms.
185 `htonl()` has some other problems as described in `//util/endian/endian.h`,
186 which defines `ghtonl()` to replace it. `ghtonl()` does the same thing `htonl()`
187 does, only without its problems. We suggest you to use `ghtonl()` instead of
188 `htonl()`, both in your tests and production code.
190 `//util/endian/endian.h` also defines `ghtons()`, which solves similar problems
193 Don't forget to add `//util/endian` to the list of dependencies in the `BUILD`
194 file wherever `ghtonl()` and `ghtons()` are used. The library consists of a
195 single header file and will not bloat your binary.
197 ## The compiler complains about "undefined references" to some static const member variables, but I did define them in the class body. What's wrong?
199 If your class has a static data member:
205 static const int kBar = 100;
209 You also need to define it *outside* of the class body in `foo.cc`:
212 const int Foo::kBar; // No initializer here.
215 Otherwise your code is **invalid C++**, and may break in unexpected ways. In
216 particular, using it in googletest comparison assertions (`EXPECT_EQ`, etc) will
217 generate an "undefined reference" linker error. The fact that "it used to work"
218 doesn't mean it's valid. It just means that you were lucky. :-)
220 ## Can I derive a test fixture from another?
224 Each test fixture has a corresponding and same named test suite. This means only
225 one test suite can use a particular fixture. Sometimes, however, multiple test
226 cases may want to use the same or slightly different fixtures. For example, you
227 may want to make sure that all of a GUI library's test suites don't leak
228 important system resources like fonts and brushes.
230 In googletest, you share a fixture among test suites by putting the shared logic
231 in a base test fixture, then deriving from that base a separate fixture for each
232 test suite that wants to use this common logic. You then use `TEST_F()` to write
233 tests using each derived fixture.
235 Typically, your code looks like this:
238 // Defines a base test fixture.
239 class BaseTest : public ::testing::Test {
244 // Derives a fixture FooTest from BaseTest.
245 class FooTest : public BaseTest {
247 void SetUp() override {
248 BaseTest::SetUp(); // Sets up the base fixture first.
249 ... additional set-up work ...
252 void TearDown() override {
253 ... clean-up work for FooTest ...
254 BaseTest::TearDown(); // Remember to tear down the base fixture
255 // after cleaning up FooTest!
258 ... functions and variables for FooTest ...
261 // Tests that use the fixture FooTest.
262 TEST_F(FooTest, Bar) { ... }
263 TEST_F(FooTest, Baz) { ... }
265 ... additional fixtures derived from BaseTest ...
268 If necessary, you can continue to derive test fixtures from a derived fixture.
269 googletest has no limit on how deep the hierarchy can be.
271 For a complete example using derived test fixtures, see
272 [sample5_unittest.cc](../samples/sample5_unittest.cc).
274 ## My compiler complains "void value not ignored as it ought to be." What does this mean?
276 You're probably using an `ASSERT_*()` in a function that doesn't return `void`.
277 `ASSERT_*()` can only be used in `void` functions, due to exceptions being
278 disabled by our build system. Please see more details
279 [here](advanced.md#assertion-placement).
281 ## My death test hangs (or seg-faults). How do I fix it?
283 In googletest, death tests are run in a child process and the way they work is
284 delicate. To write death tests you really need to understand how they work.
285 Please make sure you have read [this](advanced.md#how-it-works).
287 In particular, death tests don't like having multiple threads in the parent
288 process. So the first thing you can try is to eliminate creating threads outside
289 of `EXPECT_DEATH()`. For example, you may want to use mocks or fake objects
290 instead of real ones in your tests.
292 Sometimes this is impossible as some library you must use may be creating
293 threads before `main()` is even reached. In this case, you can try to minimize
294 the chance of conflicts by either moving as many activities as possible inside
295 `EXPECT_DEATH()` (in the extreme case, you want to move everything inside), or
296 leaving as few things as possible in it. Also, you can try to set the death test
297 style to `"threadsafe"`, which is safer but slower, and see if it helps.
299 If you go with thread-safe death tests, remember that they rerun the test
300 program from the beginning in the child process. Therefore make sure your
301 program can run side-by-side with itself and is deterministic.
303 In the end, this boils down to good concurrent programming. You have to make
304 sure that there are no race conditions or deadlocks in your program. No silver
307 ## Should I use the constructor/destructor of the test fixture or SetUp()/TearDown()? {#CtorVsSetUp}
309 The first thing to remember is that googletest does **not** reuse the same test
310 fixture object across multiple tests. For each `TEST_F`, googletest will create
311 a **fresh** test fixture object, immediately call `SetUp()`, run the test body,
312 call `TearDown()`, and then delete the test fixture object.
314 When you need to write per-test set-up and tear-down logic, you have the choice
315 between using the test fixture constructor/destructor or `SetUp()/TearDown()`.
316 The former is usually preferred, as it has the following benefits:
318 * By initializing a member variable in the constructor, we have the option to
319 make it `const`, which helps prevent accidental changes to its value and
320 makes the tests more obviously correct.
321 * In case we need to subclass the test fixture class, the subclass'
322 constructor is guaranteed to call the base class' constructor *first*, and
323 the subclass' destructor is guaranteed to call the base class' destructor
324 *afterward*. With `SetUp()/TearDown()`, a subclass may make the mistake of
325 forgetting to call the base class' `SetUp()/TearDown()` or call them at the
328 You may still want to use `SetUp()/TearDown()` in the following cases:
330 * C++ does not allow virtual function calls in constructors and destructors.
331 You can call a method declared as virtual, but it will not use dynamic
332 dispatch, it will use the definition from the class the constructor of which
333 is currently executing. This is because calling a virtual method before the
334 derived class constructor has a chance to run is very dangerous - the
335 virtual method might operate on uninitialized data. Therefore, if you need
336 to call a method that will be overridden in a derived class, you have to use
337 `SetUp()/TearDown()`.
338 * In the body of a constructor (or destructor), it's not possible to use the
339 `ASSERT_xx` macros. Therefore, if the set-up operation could cause a fatal
340 test failure that should prevent the test from running, it's necessary to
341 use `abort` <!-- GOOGLETEST_CM0015 DO NOT DELETE --> and abort the whole test executable,
342 or to use `SetUp()` instead of a constructor.
343 * If the tear-down operation could throw an exception, you must use
344 `TearDown()` as opposed to the destructor, as throwing in a destructor leads
345 to undefined behavior and usually will kill your program right away. Note
346 that many standard libraries (like STL) may throw when exceptions are
347 enabled in the compiler. Therefore you should prefer `TearDown()` if you
348 want to write portable tests that work with or without exceptions.
349 * The googletest team is considering making the assertion macros throw on
350 platforms where exceptions are enabled (e.g. Windows, Mac OS, and Linux
351 client-side), which will eliminate the need for the user to propagate
352 failures from a subroutine to its caller. Therefore, you shouldn't use
353 googletest assertions in a destructor if your code could run on such a
356 ## The compiler complains "no matching function to call" when I use ASSERT_PRED*. How do I fix it?
358 If the predicate function you use in `ASSERT_PRED*` or `EXPECT_PRED*` is
359 overloaded or a template, the compiler will have trouble figuring out which
360 overloaded version it should use. `ASSERT_PRED_FORMAT*` and
361 `EXPECT_PRED_FORMAT*` don't have this problem.
363 If you see this error, you might want to switch to
364 `(ASSERT|EXPECT)_PRED_FORMAT*`, which will also give you a better failure
365 message. If, however, that is not an option, you can resolve the problem by
366 explicitly telling the compiler which version to pick.
368 For example, suppose you have
371 bool IsPositive(int n) {
375 bool IsPositive(double x) {
380 you will get a compiler error if you write
383 EXPECT_PRED1(IsPositive, 5);
386 However, this will work:
389 EXPECT_PRED1(static_cast<bool (*)(int)>(IsPositive), 5);
392 (The stuff inside the angled brackets for the `static_cast` operator is the type
393 of the function pointer for the `int`-version of `IsPositive()`.)
395 As another example, when you have a template function
398 template <typename T>
399 bool IsNegative(T x) {
404 you can use it in a predicate assertion like this:
407 ASSERT_PRED1(IsNegative<int>, -5);
410 Things are more interesting if your template has more than one parameter. The
411 following won't compile:
414 ASSERT_PRED2(GreaterThan<int, int>, 5, 0);
417 as the C++ pre-processor thinks you are giving `ASSERT_PRED2` 4 arguments, which
418 is one more than expected. The workaround is to wrap the predicate function in
422 ASSERT_PRED2((GreaterThan<int, int>), 5, 0);
425 ## My compiler complains about "ignoring return value" when I call RUN_ALL_TESTS(). Why?
427 Some people had been ignoring the return value of `RUN_ALL_TESTS()`. That is,
431 return RUN_ALL_TESTS();
440 This is **wrong and dangerous**. The testing services needs to see the return
441 value of `RUN_ALL_TESTS()` in order to determine if a test has passed. If your
442 `main()` function ignores it, your test will be considered successful even if it
443 has a googletest assertion failure. Very bad.
445 We have decided to fix this (thanks to Michael Chastain for the idea). Now, your
446 code will no longer be able to ignore `RUN_ALL_TESTS()` when compiled with
447 `gcc`. If you do so, you'll get a compiler error.
449 If you see the compiler complaining about you ignoring the return value of
450 `RUN_ALL_TESTS()`, the fix is simple: just make sure its value is used as the
451 return value of `main()`.
453 But how could we introduce a change that breaks existing tests? Well, in this
454 case, the code was already broken in the first place, so we didn't break it. :-)
456 ## My compiler complains that a constructor (or destructor) cannot return a value. What's going on?
458 Due to a peculiarity of C++, in order to support the syntax for streaming
459 messages to an `ASSERT_*`, e.g.
462 ASSERT_EQ(1, Foo()) << "blah blah" << foo;
465 we had to give up using `ASSERT*` and `FAIL*` (but not `EXPECT*` and
466 `ADD_FAILURE*`) in constructors and destructors. The workaround is to move the
467 content of your constructor/destructor to a private void member function, or
468 switch to `EXPECT_*()` if that works. This
469 [section](advanced.md#assertion-placement) in the user's guide explains it.
471 ## My SetUp() function is not called. Why?
473 C++ is case-sensitive. Did you spell it as `Setup()`?
475 Similarly, sometimes people spell `SetUpTestSuite()` as `SetupTestSuite()` and
476 wonder why it's never called.
479 ## I have several test suites which share the same test fixture logic, do I have to define a new test fixture class for each of them? This seems pretty tedious.
481 You don't have to. Instead of
484 class FooTest : public BaseTest {};
486 TEST_F(FooTest, Abc) { ... }
487 TEST_F(FooTest, Def) { ... }
489 class BarTest : public BaseTest {};
491 TEST_F(BarTest, Abc) { ... }
492 TEST_F(BarTest, Def) { ... }
495 you can simply `typedef` the test fixtures:
498 typedef BaseTest FooTest;
500 TEST_F(FooTest, Abc) { ... }
501 TEST_F(FooTest, Def) { ... }
503 typedef BaseTest BarTest;
505 TEST_F(BarTest, Abc) { ... }
506 TEST_F(BarTest, Def) { ... }
509 ## googletest output is buried in a whole bunch of LOG messages. What do I do?
511 The googletest output is meant to be a concise and human-friendly report. If
512 your test generates textual output itself, it will mix with the googletest
513 output, making it hard to read. However, there is an easy solution to this
516 Since `LOG` messages go to stderr, we decided to let googletest output go to
517 stdout. This way, you can easily separate the two using redirection. For
521 $ ./my_test > gtest_output.txt
524 ## Why should I prefer test fixtures over global variables?
526 There are several good reasons:
528 1. It's likely your test needs to change the states of its global variables.
529 This makes it difficult to keep side effects from escaping one test and
530 contaminating others, making debugging difficult. By using fixtures, each
531 test has a fresh set of variables that's different (but with the same
532 names). Thus, tests are kept independent of each other.
533 2. Global variables pollute the global namespace.
534 3. Test fixtures can be reused via subclassing, which cannot be done easily
535 with global variables. This is useful if many test suites have something in
538 ## What can the statement argument in ASSERT_DEATH() be?
540 `ASSERT_DEATH(statement, matcher)` (or any death assertion macro) can be used
541 wherever *`statement`* is valid. So basically *`statement`* can be any C++
542 statement that makes sense in the current context. In particular, it can
543 reference global and/or local variables, and can be:
545 * a simple function call (often the case),
546 * a complex expression, or
547 * a compound statement.
549 Some examples are shown here:
552 // A death test can be a simple function call.
553 TEST(MyDeathTest, FunctionCall) {
554 ASSERT_DEATH(Xyz(5), "Xyz failed");
557 // Or a complex expression that references variables and functions.
558 TEST(MyDeathTest, ComplexExpression) {
559 const bool c = Condition();
560 ASSERT_DEATH((c ? Func1(0) : object2.Method("test")),
561 "(Func1|Method) failed");
564 // Death assertions can be used anywhere in a function. In
565 // particular, they can be inside a loop.
566 TEST(MyDeathTest, InsideLoop) {
567 // Verifies that Foo(0), Foo(1), ..., and Foo(4) all die.
568 for (int i = 0; i < 5; i++) {
569 EXPECT_DEATH_M(Foo(i), "Foo has \\d+ errors",
570 ::testing::Message() << "where i is " << i);
574 // A death assertion can contain a compound statement.
575 TEST(MyDeathTest, CompoundStatement) {
576 // Verifies that at lease one of Bar(0), Bar(1), ..., and
579 for (int i = 0; i < 5; i++) {
583 "Bar has \\d+ errors");
587 gtest-death-test_test.cc contains more examples if you are interested.
589 ## I have a fixture class `FooTest`, but `TEST_F(FooTest, Bar)` gives me error ``"no matching function for call to `FooTest::FooTest()'"``. Why?
591 Googletest needs to be able to create objects of your test fixture class, so it
592 must have a default constructor. Normally the compiler will define one for you.
593 However, there are cases where you have to define your own:
595 * If you explicitly declare a non-default constructor for class `FooTest`
596 (`DISALLOW_EVIL_CONSTRUCTORS()` does this), then you need to define a
597 default constructor, even if it would be empty.
598 * If `FooTest` has a const non-static data member, then you have to define the
599 default constructor *and* initialize the const member in the initializer
600 list of the constructor. (Early versions of `gcc` doesn't force you to
601 initialize the const member. It's a bug that has been fixed in `gcc 4`.)
603 ## Why does ASSERT_DEATH complain about previous threads that were already joined?
605 With the Linux pthread library, there is no turning back once you cross the line
606 from a single thread to multiple threads. The first time you create a thread, a
607 manager thread is created in addition, so you get 3, not 2, threads. Later when
608 the thread you create joins the main thread, the thread count decrements by 1,
609 but the manager thread will never be killed, so you still have 2 threads, which
610 means you cannot safely run a death test.
612 The new NPTL thread library doesn't suffer from this problem, as it doesn't
613 create a manager thread. However, if you don't control which machine your test
614 runs on, you shouldn't depend on this.
616 ## Why does googletest require the entire test suite, instead of individual tests, to be named *DeathTest when it uses ASSERT_DEATH?
618 googletest does not interleave tests from different test suites. That is, it
619 runs all tests in one test suite first, and then runs all tests in the next test
620 suite, and so on. googletest does this because it needs to set up a test suite
621 before the first test in it is run, and tear it down afterwards. Splitting up
622 the test case would require multiple set-up and tear-down processes, which is
623 inefficient and makes the semantics unclean.
625 If we were to determine the order of tests based on test name instead of test
626 case name, then we would have a problem with the following situation:
629 TEST_F(FooTest, AbcDeathTest) { ... }
630 TEST_F(FooTest, Uvw) { ... }
632 TEST_F(BarTest, DefDeathTest) { ... }
633 TEST_F(BarTest, Xyz) { ... }
636 Since `FooTest.AbcDeathTest` needs to run before `BarTest.Xyz`, and we don't
637 interleave tests from different test suites, we need to run all tests in the
638 `FooTest` case before running any test in the `BarTest` case. This contradicts
639 with the requirement to run `BarTest.DefDeathTest` before `FooTest.Uvw`.
641 ## But I don't like calling my entire test suite \*DeathTest when it contains both death tests and non-death tests. What do I do?
643 You don't have to, but if you like, you may split up the test suite into
644 `FooTest` and `FooDeathTest`, where the names make it clear that they are
648 class FooTest : public ::testing::Test { ... };
650 TEST_F(FooTest, Abc) { ... }
651 TEST_F(FooTest, Def) { ... }
653 using FooDeathTest = FooTest;
655 TEST_F(FooDeathTest, Uvw) { ... EXPECT_DEATH(...) ... }
656 TEST_F(FooDeathTest, Xyz) { ... ASSERT_DEATH(...) ... }
659 ## googletest prints the LOG messages in a death test's child process only when the test fails. How can I see the LOG messages when the death test succeeds?
661 Printing the LOG messages generated by the statement inside `EXPECT_DEATH()`
662 makes it harder to search for real problems in the parent's log. Therefore,
663 googletest only prints them when the death test has failed.
665 If you really need to see such LOG messages, a workaround is to temporarily
666 break the death test (e.g. by changing the regex pattern it is expected to
667 match). Admittedly, this is a hack. We'll consider a more permanent solution
668 after the fork-and-exec-style death tests are implemented.
670 ## The compiler complains about "no match for 'operator<<'" when I use an assertion. What gives?
672 If you use a user-defined type `FooType` in an assertion, you must make sure
673 there is an `std::ostream& operator<<(std::ostream&, const FooType&)` function
674 defined such that we can print a value of `FooType`.
676 In addition, if `FooType` is declared in a name space, the `<<` operator also
677 needs to be defined in the *same* name space. See https://abseil.io/tips/49 for details.
679 ## How do I suppress the memory leak messages on Windows?
681 Since the statically initialized googletest singleton requires allocations on
682 the heap, the Visual C++ memory leak detector will report memory leaks at the
683 end of the program run. The easiest way to avoid this is to use the
684 `_CrtMemCheckpoint` and `_CrtMemDumpAllObjectsSince` calls to not report any
685 statically initialized heap objects. See MSDN for more details and additional
686 heap check/debug routines.
688 ## How can my code detect if it is running in a test?
690 If you write code that sniffs whether it's running in a test and does different
691 things accordingly, you are leaking test-only logic into production code and
692 there is no easy way to ensure that the test-only code paths aren't run by
693 mistake in production. Such cleverness also leads to
694 [Heisenbugs](https://en.wikipedia.org/wiki/Heisenbug). Therefore we strongly
695 advise against the practice, and googletest doesn't provide a way to do it.
697 In general, the recommended way to cause the code to behave differently under
698 test is [Dependency Injection](https://en.wikipedia.org/wiki/Dependency_injection). You can inject
699 different functionality from the test and from the production code. Since your
700 production code doesn't link in the for-test logic at all (the
701 [`testonly`](https://docs.bazel.build/versions/master/be/common-definitions.html#common.testonly) attribute for BUILD targets helps to ensure
702 that), there is no danger in accidentally running it.
704 However, if you *really*, *really*, *really* have no choice, and if you follow
705 the rule of ending your test program names with `_test`, you can use the
706 *horrible* hack of sniffing your executable name (`argv[0]` in `main()`) to know
707 whether the code is under test.
709 ## How do I temporarily disable a test?
711 If you have a broken test that you cannot fix right away, you can add the
712 DISABLED_ prefix to its name. This will exclude it from execution. This is
713 better than commenting out the code or using #if 0, as disabled tests are still
714 compiled (and thus won't rot).
716 To include disabled tests in test execution, just invoke the test program with
717 the --gtest_also_run_disabled_tests flag.
719 ## Is it OK if I have two separate `TEST(Foo, Bar)` test methods defined in different namespaces?
723 The rule is **all test methods in the same test suite must use the same fixture
724 class.** This means that the following is **allowed** because both tests use the
725 same fixture class (`::testing::Test`).
729 TEST(CoolTest, DoSomething) {
735 TEST(CoolTest, DoSomething) {
741 However, the following code is **not allowed** and will produce a runtime error
742 from googletest because the test methods are using different test fixture
743 classes with the same test suite name.
747 class CoolTest : public ::testing::Test {}; // Fixture foo::CoolTest
748 TEST_F(CoolTest, DoSomething) {
754 class CoolTest : public ::testing::Test {}; // Fixture: bar::CoolTest
755 TEST_F(CoolTest, DoSomething) {