]>
Commit | Line | Data |
---|---|---|
1e59de90 TL |
1 | # Googletest FAQ |
2 | ||
3 | ## Why should test suite names and test names not contain underscore? | |
4 | ||
5 | {: .callout .note} | |
6 | Note: Googletest reserves underscore (`_`) for special purpose keywords, such as | |
7 | [the `DISABLED_` prefix](advanced.md#temporarily-disabling-tests), in addition | |
8 | to the following rationale. | |
9 | ||
10 | Underscore (`_`) is special, as C++ reserves the following to be used by the | |
11 | compiler and the standard library: | |
12 | ||
13 | 1. any identifier that starts with an `_` followed by an upper-case letter, and | |
14 | 2. any identifier that contains two consecutive underscores (i.e. `__`) | |
15 | *anywhere* in its name. | |
16 | ||
17 | User code is *prohibited* from using such identifiers. | |
18 | ||
19 | Now let's look at what this means for `TEST` and `TEST_F`. | |
20 | ||
21 | Currently `TEST(TestSuiteName, TestName)` generates a class named | |
22 | `TestSuiteName_TestName_Test`. What happens if `TestSuiteName` or `TestName` | |
23 | contains `_`? | |
24 | ||
25 | 1. If `TestSuiteName` starts with an `_` followed by an upper-case letter (say, | |
26 | `_Foo`), we end up with `_Foo_TestName_Test`, which is reserved and thus | |
27 | invalid. | |
28 | 2. If `TestSuiteName` ends with an `_` (say, `Foo_`), we get | |
29 | `Foo__TestName_Test`, which is invalid. | |
30 | 3. If `TestName` starts with an `_` (say, `_Bar`), we get | |
31 | `TestSuiteName__Bar_Test`, which is invalid. | |
32 | 4. If `TestName` ends with an `_` (say, `Bar_`), we get | |
33 | `TestSuiteName_Bar__Test`, which is invalid. | |
34 | ||
35 | So clearly `TestSuiteName` and `TestName` cannot start or end with `_` | |
36 | (Actually, `TestSuiteName` can start with `_` -- as long as the `_` isn't | |
37 | followed by an upper-case letter. But that's getting complicated. So for | |
38 | simplicity we just say that it cannot start with `_`.). | |
39 | ||
40 | It may seem fine for `TestSuiteName` and `TestName` to contain `_` in the | |
41 | middle. However, consider this: | |
42 | ||
43 | ```c++ | |
44 | TEST(Time, Flies_Like_An_Arrow) { ... } | |
45 | TEST(Time_Flies, Like_An_Arrow) { ... } | |
46 | ``` | |
47 | ||
48 | Now, the two `TEST`s will both generate the same class | |
49 | (`Time_Flies_Like_An_Arrow_Test`). That's not good. | |
50 | ||
51 | So for simplicity, we just ask the users to avoid `_` in `TestSuiteName` and | |
52 | `TestName`. The rule is more constraining than necessary, but it's simple and | |
53 | easy to remember. It also gives googletest some wiggle room in case its | |
54 | implementation needs to change in the future. | |
55 | ||
56 | If you violate the rule, there may not be immediate consequences, but your test | |
57 | may (just may) break with a new compiler (or a new version of the compiler you | |
58 | are using) or with a new version of googletest. Therefore it's best to follow | |
59 | the rule. | |
60 | ||
61 | ## Why does googletest support `EXPECT_EQ(NULL, ptr)` and `ASSERT_EQ(NULL, ptr)` but not `EXPECT_NE(NULL, ptr)` and `ASSERT_NE(NULL, ptr)`? | |
62 | ||
63 | First of all, you can use `nullptr` with each of these macros, e.g. | |
64 | `EXPECT_EQ(ptr, nullptr)`, `EXPECT_NE(ptr, nullptr)`, `ASSERT_EQ(ptr, nullptr)`, | |
65 | `ASSERT_NE(ptr, nullptr)`. This is the preferred syntax in the style guide | |
66 | because `nullptr` does not have the type problems that `NULL` does. | |
67 | ||
68 | Due to some peculiarity of C++, it requires some non-trivial template meta | |
69 | programming tricks to support using `NULL` as an argument of the `EXPECT_XX()` | |
70 | and `ASSERT_XX()` macros. Therefore we only do it where it's most needed | |
71 | (otherwise we make the implementation of googletest harder to maintain and more | |
72 | error-prone than necessary). | |
73 | ||
74 | Historically, the `EXPECT_EQ()` macro took the *expected* value as its first | |
75 | argument and the *actual* value as the second, though this argument order is now | |
76 | discouraged. It was reasonable that someone wanted | |
77 | to write `EXPECT_EQ(NULL, some_expression)`, and this indeed was requested | |
78 | several times. Therefore we implemented it. | |
79 | ||
80 | The need for `EXPECT_NE(NULL, ptr)` wasn't nearly as strong. When the assertion | |
81 | fails, you already know that `ptr` must be `NULL`, so it doesn't add any | |
82 | information to print `ptr` in this case. That means `EXPECT_TRUE(ptr != NULL)` | |
83 | works just as well. | |
84 | ||
85 | If we were to support `EXPECT_NE(NULL, ptr)`, for consistency we'd have to | |
86 | support `EXPECT_NE(ptr, NULL)` as well. This means using the template meta | |
87 | programming tricks twice in the implementation, making it even harder to | |
88 | understand and maintain. We believe the benefit doesn't justify the cost. | |
89 | ||
90 | Finally, with the growth of the gMock matcher library, we are encouraging people | |
91 | to use the unified `EXPECT_THAT(value, matcher)` syntax more often in tests. One | |
92 | significant advantage of the matcher approach is that matchers can be easily | |
93 | combined to form new matchers, while the `EXPECT_NE`, etc, macros cannot be | |
94 | easily combined. Therefore we want to invest more in the matchers than in the | |
95 | `EXPECT_XX()` macros. | |
96 | ||
97 | ## I need to test that different implementations of an interface satisfy some common requirements. Should I use typed tests or value-parameterized tests? | |
98 | ||
99 | For testing various implementations of the same interface, either typed tests or | |
100 | value-parameterized tests can get it done. It's really up to you the user to | |
101 | decide which is more convenient for you, depending on your particular case. Some | |
102 | rough guidelines: | |
103 | ||
104 | * Typed tests can be easier to write if instances of the different | |
105 | implementations can be created the same way, modulo the type. For example, | |
106 | if all these implementations have a public default constructor (such that | |
107 | you can write `new TypeParam`), or if their factory functions have the same | |
108 | form (e.g. `CreateInstance<TypeParam>()`). | |
109 | * Value-parameterized tests can be easier to write if you need different code | |
110 | patterns to create different implementations' instances, e.g. `new Foo` vs | |
111 | `new Bar(5)`. To accommodate for the differences, you can write factory | |
112 | function wrappers and pass these function pointers to the tests as their | |
113 | parameters. | |
114 | * When a typed test fails, the default output includes the name of the type, | |
115 | which can help you quickly identify which implementation is wrong. | |
116 | Value-parameterized tests only show the number of the failed iteration by | |
117 | default. You will need to define a function that returns the iteration name | |
118 | and pass it as the third parameter to INSTANTIATE_TEST_SUITE_P to have more | |
119 | useful output. | |
120 | * When using typed tests, you need to make sure you are testing against the | |
121 | interface type, not the concrete types (in other words, you want to make | |
122 | sure `implicit_cast<MyInterface*>(my_concrete_impl)` works, not just that | |
123 | `my_concrete_impl` works). It's less likely to make mistakes in this area | |
124 | when using value-parameterized tests. | |
125 | ||
126 | I hope I didn't confuse you more. :-) If you don't mind, I'd suggest you to give | |
127 | both approaches a try. Practice is a much better way to grasp the subtle | |
128 | differences between the two tools. Once you have some concrete experience, you | |
129 | can much more easily decide which one to use the next time. | |
130 | ||
131 | ## I got some run-time errors about invalid proto descriptors when using `ProtocolMessageEquals`. Help! | |
132 | ||
133 | {: .callout .note} | |
134 | **Note:** `ProtocolMessageEquals` and `ProtocolMessageEquiv` are *deprecated* | |
135 | now. Please use `EqualsProto`, etc instead. | |
136 | ||
137 | `ProtocolMessageEquals` and `ProtocolMessageEquiv` were redefined recently and | |
138 | are now less tolerant of invalid protocol buffer definitions. In particular, if | |
139 | you have a `foo.proto` that doesn't fully qualify the type of a protocol message | |
140 | it references (e.g. `message<Bar>` where it should be `message<blah.Bar>`), you | |
141 | will now get run-time errors like: | |
142 | ||
143 | ``` | |
144 | ... descriptor.cc:...] Invalid proto descriptor for file "path/to/foo.proto": | |
145 | ... descriptor.cc:...] blah.MyMessage.my_field: ".Bar" is not defined. | |
146 | ``` | |
147 | ||
148 | If you see this, your `.proto` file is broken and needs to be fixed by making | |
149 | the types fully qualified. The new definition of `ProtocolMessageEquals` and | |
150 | `ProtocolMessageEquiv` just happen to reveal your bug. | |
151 | ||
152 | ## My death test modifies some state, but the change seems lost after the death test finishes. Why? | |
153 | ||
154 | Death tests (`EXPECT_DEATH`, etc) are executed in a sub-process s.t. the | |
155 | expected crash won't kill the test program (i.e. the parent process). As a | |
156 | result, any in-memory side effects they incur are observable in their respective | |
157 | sub-processes, but not in the parent process. You can think of them as running | |
158 | in a parallel universe, more or less. | |
159 | ||
160 | In particular, if you use mocking and the death test statement invokes some mock | |
161 | methods, the parent process will think the calls have never occurred. Therefore, | |
162 | you may want to move your `EXPECT_CALL` statements inside the `EXPECT_DEATH` | |
163 | macro. | |
164 | ||
165 | ## EXPECT_EQ(htonl(blah), blah_blah) generates weird compiler errors in opt mode. Is this a googletest bug? | |
166 | ||
167 | Actually, the bug is in `htonl()`. | |
168 | ||
169 | According to `'man htonl'`, `htonl()` is a *function*, which means it's valid to | |
170 | use `htonl` as a function pointer. However, in opt mode `htonl()` is defined as | |
171 | a *macro*, which breaks this usage. | |
172 | ||
173 | Worse, the macro definition of `htonl()` uses a `gcc` extension and is *not* | |
174 | standard C++. That hacky implementation has some ad hoc limitations. In | |
175 | particular, it prevents you from writing `Foo<sizeof(htonl(x))>()`, where `Foo` | |
176 | is a template that has an integral argument. | |
177 | ||
178 | The implementation of `EXPECT_EQ(a, b)` uses `sizeof(... a ...)` inside a | |
179 | template argument, and thus doesn't compile in opt mode when `a` contains a call | |
180 | to `htonl()`. It is difficult to make `EXPECT_EQ` bypass the `htonl()` bug, as | |
181 | the solution must work with different compilers on various platforms. | |
182 | ||
183 | ## The compiler complains about "undefined references" to some static const member variables, but I did define them in the class body. What's wrong? | |
184 | ||
185 | If your class has a static data member: | |
186 | ||
187 | ```c++ | |
188 | // foo.h | |
189 | class Foo { | |
190 | ... | |
191 | static const int kBar = 100; | |
192 | }; | |
193 | ``` | |
194 | ||
195 | You also need to define it *outside* of the class body in `foo.cc`: | |
196 | ||
197 | ```c++ | |
198 | const int Foo::kBar; // No initializer here. | |
199 | ``` | |
200 | ||
201 | Otherwise your code is **invalid C++**, and may break in unexpected ways. In | |
202 | particular, using it in googletest comparison assertions (`EXPECT_EQ`, etc) will | |
203 | generate an "undefined reference" linker error. The fact that "it used to work" | |
204 | doesn't mean it's valid. It just means that you were lucky. :-) | |
205 | ||
206 | If the declaration of the static data member is `constexpr` then it is | |
207 | implicitly an `inline` definition, and a separate definition in `foo.cc` is not | |
208 | needed: | |
209 | ||
210 | ```c++ | |
211 | // foo.h | |
212 | class Foo { | |
213 | ... | |
214 | static constexpr int kBar = 100; // Defines kBar, no need to do it in foo.cc. | |
215 | }; | |
216 | ``` | |
217 | ||
218 | ## Can I derive a test fixture from another? | |
219 | ||
220 | Yes. | |
221 | ||
222 | Each test fixture has a corresponding and same named test suite. This means only | |
223 | one test suite can use a particular fixture. Sometimes, however, multiple test | |
224 | cases may want to use the same or slightly different fixtures. For example, you | |
225 | may want to make sure that all of a GUI library's test suites don't leak | |
226 | important system resources like fonts and brushes. | |
227 | ||
228 | In googletest, you share a fixture among test suites by putting the shared logic | |
229 | in a base test fixture, then deriving from that base a separate fixture for each | |
230 | test suite that wants to use this common logic. You then use `TEST_F()` to write | |
231 | tests using each derived fixture. | |
232 | ||
233 | Typically, your code looks like this: | |
234 | ||
235 | ```c++ | |
236 | // Defines a base test fixture. | |
237 | class BaseTest : public ::testing::Test { | |
238 | protected: | |
239 | ... | |
240 | }; | |
241 | ||
242 | // Derives a fixture FooTest from BaseTest. | |
243 | class FooTest : public BaseTest { | |
244 | protected: | |
245 | void SetUp() override { | |
246 | BaseTest::SetUp(); // Sets up the base fixture first. | |
247 | ... additional set-up work ... | |
248 | } | |
249 | ||
250 | void TearDown() override { | |
251 | ... clean-up work for FooTest ... | |
252 | BaseTest::TearDown(); // Remember to tear down the base fixture | |
253 | // after cleaning up FooTest! | |
254 | } | |
255 | ||
256 | ... functions and variables for FooTest ... | |
257 | }; | |
258 | ||
259 | // Tests that use the fixture FooTest. | |
260 | TEST_F(FooTest, Bar) { ... } | |
261 | TEST_F(FooTest, Baz) { ... } | |
262 | ||
263 | ... additional fixtures derived from BaseTest ... | |
264 | ``` | |
265 | ||
266 | If necessary, you can continue to derive test fixtures from a derived fixture. | |
267 | googletest has no limit on how deep the hierarchy can be. | |
268 | ||
269 | For a complete example using derived test fixtures, see | |
270 | [sample5_unittest.cc](https://github.com/google/googletest/blob/master/googletest/samples/sample5_unittest.cc). | |
271 | ||
272 | ## My compiler complains "void value not ignored as it ought to be." What does this mean? | |
273 | ||
274 | You're probably using an `ASSERT_*()` in a function that doesn't return `void`. | |
275 | `ASSERT_*()` can only be used in `void` functions, due to exceptions being | |
276 | disabled by our build system. Please see more details | |
277 | [here](advanced.md#assertion-placement). | |
278 | ||
279 | ## My death test hangs (or seg-faults). How do I fix it? | |
280 | ||
281 | In googletest, death tests are run in a child process and the way they work is | |
282 | delicate. To write death tests you really need to understand how they work—see | |
283 | the details at [Death Assertions](reference/assertions.md#death) in the | |
284 | Assertions Reference. | |
285 | ||
286 | In particular, death tests don't like having multiple threads in the parent | |
287 | process. So the first thing you can try is to eliminate creating threads outside | |
288 | of `EXPECT_DEATH()`. For example, you may want to use mocks or fake objects | |
289 | instead of real ones in your tests. | |
290 | ||
291 | Sometimes this is impossible as some library you must use may be creating | |
292 | threads before `main()` is even reached. In this case, you can try to minimize | |
293 | the chance of conflicts by either moving as many activities as possible inside | |
294 | `EXPECT_DEATH()` (in the extreme case, you want to move everything inside), or | |
295 | leaving as few things as possible in it. Also, you can try to set the death test | |
296 | style to `"threadsafe"`, which is safer but slower, and see if it helps. | |
297 | ||
298 | If you go with thread-safe death tests, remember that they rerun the test | |
299 | program from the beginning in the child process. Therefore make sure your | |
300 | program can run side-by-side with itself and is deterministic. | |
301 | ||
302 | In the end, this boils down to good concurrent programming. You have to make | |
303 | sure that there are no race conditions or deadlocks in your program. No silver | |
304 | bullet - sorry! | |
305 | ||
306 | ## Should I use the constructor/destructor of the test fixture or SetUp()/TearDown()? {#CtorVsSetUp} | |
307 | ||
308 | The first thing to remember is that googletest does **not** reuse the same test | |
309 | fixture object across multiple tests. For each `TEST_F`, googletest will create | |
310 | a **fresh** test fixture object, immediately call `SetUp()`, run the test body, | |
311 | call `TearDown()`, and then delete the test fixture object. | |
312 | ||
313 | When you need to write per-test set-up and tear-down logic, you have the choice | |
314 | between using the test fixture constructor/destructor or `SetUp()/TearDown()`. | |
315 | The former is usually preferred, as it has the following benefits: | |
316 | ||
317 | * By initializing a member variable in the constructor, we have the option to | |
318 | make it `const`, which helps prevent accidental changes to its value and | |
319 | makes the tests more obviously correct. | |
320 | * In case we need to subclass the test fixture class, the subclass' | |
321 | constructor is guaranteed to call the base class' constructor *first*, and | |
322 | the subclass' destructor is guaranteed to call the base class' destructor | |
323 | *afterward*. With `SetUp()/TearDown()`, a subclass may make the mistake of | |
324 | forgetting to call the base class' `SetUp()/TearDown()` or call them at the | |
325 | wrong time. | |
326 | ||
327 | You may still want to use `SetUp()/TearDown()` in the following cases: | |
328 | ||
329 | * C++ does not allow virtual function calls in constructors and destructors. | |
330 | You can call a method declared as virtual, but it will not use dynamic | |
331 | dispatch, it will use the definition from the class the constructor of which | |
332 | is currently executing. This is because calling a virtual method before the | |
333 | derived class constructor has a chance to run is very dangerous - the | |
334 | virtual method might operate on uninitialized data. Therefore, if you need | |
335 | to call a method that will be overridden in a derived class, you have to use | |
336 | `SetUp()/TearDown()`. | |
337 | * In the body of a constructor (or destructor), it's not possible to use the | |
338 | `ASSERT_xx` macros. Therefore, if the set-up operation could cause a fatal | |
339 | test failure that should prevent the test from running, it's necessary to | |
340 | use `abort` and abort the whole test | |
341 | executable, or to use `SetUp()` instead of a constructor. | |
342 | * If the tear-down operation could throw an exception, you must use | |
343 | `TearDown()` as opposed to the destructor, as throwing in a destructor leads | |
344 | to undefined behavior and usually will kill your program right away. Note | |
345 | that many standard libraries (like STL) may throw when exceptions are | |
346 | enabled in the compiler. Therefore you should prefer `TearDown()` if you | |
347 | want to write portable tests that work with or without exceptions. | |
348 | * The googletest team is considering making the assertion macros throw on | |
349 | platforms where exceptions are enabled (e.g. Windows, Mac OS, and Linux | |
350 | client-side), which will eliminate the need for the user to propagate | |
351 | failures from a subroutine to its caller. Therefore, you shouldn't use | |
352 | googletest assertions in a destructor if your code could run on such a | |
353 | platform. | |
354 | ||
355 | ## The compiler complains "no matching function to call" when I use ASSERT_PRED*. How do I fix it? | |
356 | ||
357 | See details for [`EXPECT_PRED*`](reference/assertions.md#EXPECT_PRED) in the | |
358 | Assertions Reference. | |
359 | ||
360 | ## My compiler complains about "ignoring return value" when I call RUN_ALL_TESTS(). Why? | |
361 | ||
362 | Some people had been ignoring the return value of `RUN_ALL_TESTS()`. That is, | |
363 | instead of | |
364 | ||
365 | ```c++ | |
366 | return RUN_ALL_TESTS(); | |
367 | ``` | |
368 | ||
369 | they write | |
370 | ||
371 | ```c++ | |
372 | RUN_ALL_TESTS(); | |
373 | ``` | |
374 | ||
375 | This is **wrong and dangerous**. The testing services needs to see the return | |
376 | value of `RUN_ALL_TESTS()` in order to determine if a test has passed. If your | |
377 | `main()` function ignores it, your test will be considered successful even if it | |
378 | has a googletest assertion failure. Very bad. | |
379 | ||
380 | We have decided to fix this (thanks to Michael Chastain for the idea). Now, your | |
381 | code will no longer be able to ignore `RUN_ALL_TESTS()` when compiled with | |
382 | `gcc`. If you do so, you'll get a compiler error. | |
383 | ||
384 | If you see the compiler complaining about you ignoring the return value of | |
385 | `RUN_ALL_TESTS()`, the fix is simple: just make sure its value is used as the | |
386 | return value of `main()`. | |
387 | ||
388 | But how could we introduce a change that breaks existing tests? Well, in this | |
389 | case, the code was already broken in the first place, so we didn't break it. :-) | |
390 | ||
391 | ## My compiler complains that a constructor (or destructor) cannot return a value. What's going on? | |
392 | ||
393 | Due to a peculiarity of C++, in order to support the syntax for streaming | |
394 | messages to an `ASSERT_*`, e.g. | |
395 | ||
396 | ```c++ | |
397 | ASSERT_EQ(1, Foo()) << "blah blah" << foo; | |
398 | ``` | |
399 | ||
400 | we had to give up using `ASSERT*` and `FAIL*` (but not `EXPECT*` and | |
401 | `ADD_FAILURE*`) in constructors and destructors. The workaround is to move the | |
402 | content of your constructor/destructor to a private void member function, or | |
403 | switch to `EXPECT_*()` if that works. This | |
404 | [section](advanced.md#assertion-placement) in the user's guide explains it. | |
405 | ||
406 | ## My SetUp() function is not called. Why? | |
407 | ||
408 | C++ is case-sensitive. Did you spell it as `Setup()`? | |
409 | ||
410 | Similarly, sometimes people spell `SetUpTestSuite()` as `SetupTestSuite()` and | |
411 | wonder why it's never called. | |
412 | ||
413 | ||
414 | ## 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. | |
415 | ||
416 | You don't have to. Instead of | |
417 | ||
418 | ```c++ | |
419 | class FooTest : public BaseTest {}; | |
420 | ||
421 | TEST_F(FooTest, Abc) { ... } | |
422 | TEST_F(FooTest, Def) { ... } | |
423 | ||
424 | class BarTest : public BaseTest {}; | |
425 | ||
426 | TEST_F(BarTest, Abc) { ... } | |
427 | TEST_F(BarTest, Def) { ... } | |
428 | ``` | |
429 | ||
430 | you can simply `typedef` the test fixtures: | |
431 | ||
432 | ```c++ | |
433 | typedef BaseTest FooTest; | |
434 | ||
435 | TEST_F(FooTest, Abc) { ... } | |
436 | TEST_F(FooTest, Def) { ... } | |
437 | ||
438 | typedef BaseTest BarTest; | |
439 | ||
440 | TEST_F(BarTest, Abc) { ... } | |
441 | TEST_F(BarTest, Def) { ... } | |
442 | ``` | |
443 | ||
444 | ## googletest output is buried in a whole bunch of LOG messages. What do I do? | |
445 | ||
446 | The googletest output is meant to be a concise and human-friendly report. If | |
447 | your test generates textual output itself, it will mix with the googletest | |
448 | output, making it hard to read. However, there is an easy solution to this | |
449 | problem. | |
450 | ||
451 | Since `LOG` messages go to stderr, we decided to let googletest output go to | |
452 | stdout. This way, you can easily separate the two using redirection. For | |
453 | example: | |
454 | ||
455 | ```shell | |
456 | $ ./my_test > gtest_output.txt | |
457 | ``` | |
458 | ||
459 | ## Why should I prefer test fixtures over global variables? | |
460 | ||
461 | There are several good reasons: | |
462 | ||
463 | 1. It's likely your test needs to change the states of its global variables. | |
464 | This makes it difficult to keep side effects from escaping one test and | |
465 | contaminating others, making debugging difficult. By using fixtures, each | |
466 | test has a fresh set of variables that's different (but with the same | |
467 | names). Thus, tests are kept independent of each other. | |
468 | 2. Global variables pollute the global namespace. | |
469 | 3. Test fixtures can be reused via subclassing, which cannot be done easily | |
470 | with global variables. This is useful if many test suites have something in | |
471 | common. | |
472 | ||
473 | ## What can the statement argument in ASSERT_DEATH() be? | |
474 | ||
475 | `ASSERT_DEATH(statement, matcher)` (or any death assertion macro) can be used | |
476 | wherever *`statement`* is valid. So basically *`statement`* can be any C++ | |
477 | statement that makes sense in the current context. In particular, it can | |
478 | reference global and/or local variables, and can be: | |
479 | ||
480 | * a simple function call (often the case), | |
481 | * a complex expression, or | |
482 | * a compound statement. | |
483 | ||
484 | Some examples are shown here: | |
485 | ||
486 | ```c++ | |
487 | // A death test can be a simple function call. | |
488 | TEST(MyDeathTest, FunctionCall) { | |
489 | ASSERT_DEATH(Xyz(5), "Xyz failed"); | |
490 | } | |
491 | ||
492 | // Or a complex expression that references variables and functions. | |
493 | TEST(MyDeathTest, ComplexExpression) { | |
494 | const bool c = Condition(); | |
495 | ASSERT_DEATH((c ? Func1(0) : object2.Method("test")), | |
496 | "(Func1|Method) failed"); | |
497 | } | |
498 | ||
499 | // Death assertions can be used anywhere in a function. In | |
500 | // particular, they can be inside a loop. | |
501 | TEST(MyDeathTest, InsideLoop) { | |
502 | // Verifies that Foo(0), Foo(1), ..., and Foo(4) all die. | |
503 | for (int i = 0; i < 5; i++) { | |
504 | EXPECT_DEATH_M(Foo(i), "Foo has \\d+ errors", | |
505 | ::testing::Message() << "where i is " << i); | |
506 | } | |
507 | } | |
508 | ||
509 | // A death assertion can contain a compound statement. | |
510 | TEST(MyDeathTest, CompoundStatement) { | |
511 | // Verifies that at lease one of Bar(0), Bar(1), ..., and | |
512 | // Bar(4) dies. | |
513 | ASSERT_DEATH({ | |
514 | for (int i = 0; i < 5; i++) { | |
515 | Bar(i); | |
516 | } | |
517 | }, | |
518 | "Bar has \\d+ errors"); | |
519 | } | |
520 | ``` | |
521 | ||
522 | ## I have a fixture class `FooTest`, but `TEST_F(FooTest, Bar)` gives me error ``"no matching function for call to `FooTest::FooTest()'"``. Why? | |
523 | ||
524 | Googletest needs to be able to create objects of your test fixture class, so it | |
525 | must have a default constructor. Normally the compiler will define one for you. | |
526 | However, there are cases where you have to define your own: | |
527 | ||
528 | * If you explicitly declare a non-default constructor for class `FooTest` | |
529 | (`DISALLOW_EVIL_CONSTRUCTORS()` does this), then you need to define a | |
530 | default constructor, even if it would be empty. | |
531 | * If `FooTest` has a const non-static data member, then you have to define the | |
532 | default constructor *and* initialize the const member in the initializer | |
533 | list of the constructor. (Early versions of `gcc` doesn't force you to | |
534 | initialize the const member. It's a bug that has been fixed in `gcc 4`.) | |
535 | ||
536 | ## Why does ASSERT_DEATH complain about previous threads that were already joined? | |
537 | ||
538 | With the Linux pthread library, there is no turning back once you cross the line | |
539 | from a single thread to multiple threads. The first time you create a thread, a | |
540 | manager thread is created in addition, so you get 3, not 2, threads. Later when | |
541 | the thread you create joins the main thread, the thread count decrements by 1, | |
542 | but the manager thread will never be killed, so you still have 2 threads, which | |
543 | means you cannot safely run a death test. | |
544 | ||
545 | The new NPTL thread library doesn't suffer from this problem, as it doesn't | |
546 | create a manager thread. However, if you don't control which machine your test | |
547 | runs on, you shouldn't depend on this. | |
548 | ||
549 | ## Why does googletest require the entire test suite, instead of individual tests, to be named *DeathTest when it uses ASSERT_DEATH? | |
550 | ||
551 | googletest does not interleave tests from different test suites. That is, it | |
552 | runs all tests in one test suite first, and then runs all tests in the next test | |
553 | suite, and so on. googletest does this because it needs to set up a test suite | |
554 | before the first test in it is run, and tear it down afterwards. Splitting up | |
555 | the test case would require multiple set-up and tear-down processes, which is | |
556 | inefficient and makes the semantics unclean. | |
557 | ||
558 | If we were to determine the order of tests based on test name instead of test | |
559 | case name, then we would have a problem with the following situation: | |
560 | ||
561 | ```c++ | |
562 | TEST_F(FooTest, AbcDeathTest) { ... } | |
563 | TEST_F(FooTest, Uvw) { ... } | |
564 | ||
565 | TEST_F(BarTest, DefDeathTest) { ... } | |
566 | TEST_F(BarTest, Xyz) { ... } | |
567 | ``` | |
568 | ||
569 | Since `FooTest.AbcDeathTest` needs to run before `BarTest.Xyz`, and we don't | |
570 | interleave tests from different test suites, we need to run all tests in the | |
571 | `FooTest` case before running any test in the `BarTest` case. This contradicts | |
572 | with the requirement to run `BarTest.DefDeathTest` before `FooTest.Uvw`. | |
573 | ||
574 | ## 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? | |
575 | ||
576 | You don't have to, but if you like, you may split up the test suite into | |
577 | `FooTest` and `FooDeathTest`, where the names make it clear that they are | |
578 | related: | |
579 | ||
580 | ```c++ | |
581 | class FooTest : public ::testing::Test { ... }; | |
582 | ||
583 | TEST_F(FooTest, Abc) { ... } | |
584 | TEST_F(FooTest, Def) { ... } | |
585 | ||
586 | using FooDeathTest = FooTest; | |
587 | ||
588 | TEST_F(FooDeathTest, Uvw) { ... EXPECT_DEATH(...) ... } | |
589 | TEST_F(FooDeathTest, Xyz) { ... ASSERT_DEATH(...) ... } | |
590 | ``` | |
591 | ||
592 | ## 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? | |
593 | ||
594 | Printing the LOG messages generated by the statement inside `EXPECT_DEATH()` | |
595 | makes it harder to search for real problems in the parent's log. Therefore, | |
596 | googletest only prints them when the death test has failed. | |
597 | ||
598 | If you really need to see such LOG messages, a workaround is to temporarily | |
599 | break the death test (e.g. by changing the regex pattern it is expected to | |
600 | match). Admittedly, this is a hack. We'll consider a more permanent solution | |
601 | after the fork-and-exec-style death tests are implemented. | |
602 | ||
603 | ## The compiler complains about `no match for 'operator<<'` when I use an assertion. What gives? | |
604 | ||
605 | If you use a user-defined type `FooType` in an assertion, you must make sure | |
606 | there is an `std::ostream& operator<<(std::ostream&, const FooType&)` function | |
607 | defined such that we can print a value of `FooType`. | |
608 | ||
609 | In addition, if `FooType` is declared in a name space, the `<<` operator also | |
610 | needs to be defined in the *same* name space. See | |
611 | [Tip of the Week #49](http://abseil.io/tips/49) for details. | |
612 | ||
613 | ## How do I suppress the memory leak messages on Windows? | |
614 | ||
615 | Since the statically initialized googletest singleton requires allocations on | |
616 | the heap, the Visual C++ memory leak detector will report memory leaks at the | |
617 | end of the program run. The easiest way to avoid this is to use the | |
618 | `_CrtMemCheckpoint` and `_CrtMemDumpAllObjectsSince` calls to not report any | |
619 | statically initialized heap objects. See MSDN for more details and additional | |
620 | heap check/debug routines. | |
621 | ||
622 | ## How can my code detect if it is running in a test? | |
623 | ||
624 | If you write code that sniffs whether it's running in a test and does different | |
625 | things accordingly, you are leaking test-only logic into production code and | |
626 | there is no easy way to ensure that the test-only code paths aren't run by | |
627 | mistake in production. Such cleverness also leads to | |
628 | [Heisenbugs](https://en.wikipedia.org/wiki/Heisenbug). Therefore we strongly | |
629 | advise against the practice, and googletest doesn't provide a way to do it. | |
630 | ||
631 | In general, the recommended way to cause the code to behave differently under | |
632 | test is [Dependency Injection](http://en.wikipedia.org/wiki/Dependency_injection). You can inject | |
633 | different functionality from the test and from the production code. Since your | |
634 | production code doesn't link in the for-test logic at all (the | |
635 | [`testonly`](http://docs.bazel.build/versions/master/be/common-definitions.html#common.testonly) attribute for BUILD targets helps to ensure | |
636 | that), there is no danger in accidentally running it. | |
637 | ||
638 | However, if you *really*, *really*, *really* have no choice, and if you follow | |
639 | the rule of ending your test program names with `_test`, you can use the | |
640 | *horrible* hack of sniffing your executable name (`argv[0]` in `main()`) to know | |
641 | whether the code is under test. | |
642 | ||
643 | ## How do I temporarily disable a test? | |
644 | ||
645 | If you have a broken test that you cannot fix right away, you can add the | |
646 | `DISABLED_` prefix to its name. This will exclude it from execution. This is | |
647 | better than commenting out the code or using `#if 0`, as disabled tests are | |
648 | still compiled (and thus won't rot). | |
649 | ||
650 | To include disabled tests in test execution, just invoke the test program with | |
651 | the `--gtest_also_run_disabled_tests` flag. | |
652 | ||
653 | ## Is it OK if I have two separate `TEST(Foo, Bar)` test methods defined in different namespaces? | |
654 | ||
655 | Yes. | |
656 | ||
657 | The rule is **all test methods in the same test suite must use the same fixture | |
658 | class.** This means that the following is **allowed** because both tests use the | |
659 | same fixture class (`::testing::Test`). | |
660 | ||
661 | ```c++ | |
662 | namespace foo { | |
663 | TEST(CoolTest, DoSomething) { | |
664 | SUCCEED(); | |
665 | } | |
666 | } // namespace foo | |
667 | ||
668 | namespace bar { | |
669 | TEST(CoolTest, DoSomething) { | |
670 | SUCCEED(); | |
671 | } | |
672 | } // namespace bar | |
673 | ``` | |
674 | ||
675 | However, the following code is **not allowed** and will produce a runtime error | |
676 | from googletest because the test methods are using different test fixture | |
677 | classes with the same test suite name. | |
678 | ||
679 | ```c++ | |
680 | namespace foo { | |
681 | class CoolTest : public ::testing::Test {}; // Fixture foo::CoolTest | |
682 | TEST_F(CoolTest, DoSomething) { | |
683 | SUCCEED(); | |
684 | } | |
685 | } // namespace foo | |
686 | ||
687 | namespace bar { | |
688 | class CoolTest : public ::testing::Test {}; // Fixture: bar::CoolTest | |
689 | TEST_F(CoolTest, DoSomething) { | |
690 | SUCCEED(); | |
691 | } | |
692 | } // namespace bar | |
693 | ``` |