"Fossies" - the Fresh Open Source Software Archive  

Source code changes of the file "docs/faq.md" between
googletest-release-1.11.0.tar.gz and googletest-release-1.12.0.tar.gz

About: GoogleTest is Google's (unit) testing and mocking framework for C++ tests.

faq.md  (googletest-release-1.11.0)	:	faq.md  (googletest-release-1.12.0)
# Googletest FAQ		# GoogleTest FAQ
## Why should test suite names and test names not contain underscore?		## Why should test suite names and test names not contain underscore?
{: .callout .note}		{: .callout .note}
Note: Googletest reserves underscore (`_`) for special purpose keywords, such as		Note: GoogleTest reserves underscore (`_`) for special purpose keywords, such as
[the `DISABLED_` prefix](advanced.md#temporarily-disabling-tests), in addition		[the `DISABLED_` prefix](advanced.md#temporarily-disabling-tests), in addition
to the following rationale.		to the following rationale.
Underscore (`_`) is special, as C++ reserves the following to be used by the		Underscore (`_`) is special, as C++ reserves the following to be used by the
compiler and the standard library:		compiler and the standard library:
1. any identifier that starts with an `_` followed by an upper-case letter, and		1. any identifier that starts with an `_` followed by an upper-case letter, and
2. any identifier that contains two consecutive underscores (i.e. `__`)		2. any identifier that contains two consecutive underscores (i.e. `__`)
*anywhere* in its name.		*anywhere* in its name.
skipping to change at line 53		skipping to change at line 53
```c++		```c++
TEST(Time, Flies_Like_An_Arrow) { ... }		TEST(Time, Flies_Like_An_Arrow) { ... }
TEST(Time_Flies, Like_An_Arrow) { ... }		TEST(Time_Flies, Like_An_Arrow) { ... }
```		```
Now, the two `TEST`s will both generate the same class		Now, the two `TEST`s will both generate the same class
(`Time_Flies_Like_An_Arrow_Test`). That's not good.		(`Time_Flies_Like_An_Arrow_Test`). That's not good.
So for simplicity, we just ask the users to avoid `_` in `TestSuiteName` and		So for simplicity, we just ask the users to avoid `_` in `TestSuiteName` and
`TestName`. The rule is more constraining than necessary, but it's simple and		`TestName`. The rule is more constraining than necessary, but it's simple and
easy to remember. It also gives googletest some wiggle room in case its		easy to remember. It also gives GoogleTest some wiggle room in case its
implementation needs to change in the future.		implementation needs to change in the future.
If you violate the rule, there may not be immediate consequences, but your test		If you violate the rule, there may not be immediate consequences, but your test
may (just may) break with a new compiler (or a new version of the compiler you		may (just may) break with a new compiler (or a new version of the compiler you
are using) or with a new version of googletest. Therefore it's best to follow		are using) or with a new version of GoogleTest. Therefore it's best to follow
the rule.		the rule.
## Why does googletest support `EXPECT_EQ(NULL, ptr)` and `ASSERT_EQ(NULL, ptr)` but not `EXPECT_NE(NULL, ptr)` and `ASSERT_NE(NULL, ptr)`?		## Why does GoogleTest support `EXPECT_EQ(NULL, ptr)` and `ASSERT_EQ(NULL, ptr)` but not `EXPECT_NE(NULL, ptr)` and `ASSERT_NE(NULL, ptr)`?
First of all, you can use `nullptr` with each of these macros, e.g.		First of all, you can use `nullptr` with each of these macros, e.g.
`EXPECT_EQ(ptr, nullptr)`, `EXPECT_NE(ptr, nullptr)`, `ASSERT_EQ(ptr, nullptr)`,		`EXPECT_EQ(ptr, nullptr)`, `EXPECT_NE(ptr, nullptr)`, `ASSERT_EQ(ptr, nullptr)`,
`ASSERT_NE(ptr, nullptr)`. This is the preferred syntax in the style guide		`ASSERT_NE(ptr, nullptr)`. This is the preferred syntax in the style guide
because `nullptr` does not have the type problems that `NULL` does.		because `nullptr` does not have the type problems that `NULL` does.
Due to some peculiarity of C++, it requires some non-trivial template meta		Due to some peculiarity of C++, it requires some non-trivial template meta
programming tricks to support using `NULL` as an argument of the `EXPECT_XX()`		programming tricks to support using `NULL` as an argument of the `EXPECT_XX()`
and `ASSERT_XX()` macros. Therefore we only do it where it's most needed		and `ASSERT_XX()` macros. Therefore we only do it where it's most needed
(otherwise we make the implementation of googletest harder to maintain and more		(otherwise we make the implementation of GoogleTest harder to maintain and more
error-prone than necessary).		error-prone than necessary).
Historically, the `EXPECT_EQ()` macro took the *expected* value as its first		Historically, the `EXPECT_EQ()` macro took the *expected* value as its first
argument and the *actual* value as the second, though this argument order is now		argument and the *actual* value as the second, though this argument order is now
discouraged. It was reasonable that someone wanted		discouraged. It was reasonable that someone wanted
to write `EXPECT_EQ(NULL, some_expression)`, and this indeed was requested		to write `EXPECT_EQ(NULL, some_expression)`, and this indeed was requested
several times. Therefore we implemented it.		several times. Therefore we implemented it.
The need for `EXPECT_NE(NULL, ptr)` wasn't nearly as strong. When the assertion		The need for `EXPECT_NE(NULL, ptr)` wasn't nearly as strong. When the assertion
fails, you already know that `ptr` must be `NULL`, so it doesn't add any		fails, you already know that `ptr` must be `NULL`, so it doesn't add any
skipping to change at line 165		skipping to change at line 165
expected crash won't kill the test program (i.e. the parent process). As a		expected crash won't kill the test program (i.e. the parent process). As a
result, any in-memory side effects they incur are observable in their respective		result, any in-memory side effects they incur are observable in their respective
sub-processes, but not in the parent process. You can think of them as running		sub-processes, but not in the parent process. You can think of them as running
in a parallel universe, more or less.		in a parallel universe, more or less.
In particular, if you use mocking and the death test statement invokes some mock		In particular, if you use mocking and the death test statement invokes some mock
methods, the parent process will think the calls have never occurred. Therefore,		methods, the parent process will think the calls have never occurred. Therefore,
you may want to move your `EXPECT_CALL` statements inside the `EXPECT_DEATH`		you may want to move your `EXPECT_CALL` statements inside the `EXPECT_DEATH`
macro.		macro.
## EXPECT_EQ(htonl(blah), blah_blah) generates weird compiler errors in opt mode . Is this a googletest bug?		## EXPECT_EQ(htonl(blah), blah_blah) generates weird compiler errors in opt mode . Is this a GoogleTest bug?
Actually, the bug is in `htonl()`.		Actually, the bug is in `htonl()`.
According to `'man htonl'`, `htonl()` is a *function*, which means it's valid to		According to `'man htonl'`, `htonl()` is a *function*, which means it's valid to
use `htonl` as a function pointer. However, in opt mode `htonl()` is defined as		use `htonl` as a function pointer. However, in opt mode `htonl()` is defined as
a *macro*, which breaks this usage.		a *macro*, which breaks this usage.
Worse, the macro definition of `htonl()` uses a `gcc` extension and is *not*		Worse, the macro definition of `htonl()` uses a `gcc` extension and is *not*
standard C++. That hacky implementation has some ad hoc limitations. In		standard C++. That hacky implementation has some ad hoc limitations. In
particular, it prevents you from writing `Foo<sizeof(htonl(x))>()`, where `Foo`		particular, it prevents you from writing `Foo<sizeof(htonl(x))>()`, where `Foo`
skipping to change at line 202		skipping to change at line 202
};		};
```		```
You also need to define it *outside* of the class body in `foo.cc`:		You also need to define it *outside* of the class body in `foo.cc`:
```c++		```c++
const int Foo::kBar; // No initializer here.		const int Foo::kBar; // No initializer here.
```		```
Otherwise your code is **invalid C++**, and may break in unexpected ways. In		Otherwise your code is **invalid C++**, and may break in unexpected ways. In
particular, using it in googletest comparison assertions (`EXPECT_EQ`, etc) will		particular, using it in GoogleTest comparison assertions (`EXPECT_EQ`, etc) will
generate an "undefined reference" linker error. The fact that "it used to work"		generate an "undefined reference" linker error. The fact that "it used to work"
doesn't mean it's valid. It just means that you were lucky. :-)		doesn't mean it's valid. It just means that you were lucky. :-)
If the declaration of the static data member is `constexpr` then it is		If the declaration of the static data member is `constexpr` then it is
implicitly an `inline` definition, and a separate definition in `foo.cc` is not		implicitly an `inline` definition, and a separate definition in `foo.cc` is not
needed:		needed:
```c++		```c++
// foo.h		// foo.h
class Foo {		class Foo {
skipping to change at line 228		skipping to change at line 228
## Can I derive a test fixture from another?		## Can I derive a test fixture from another?
Yes.		Yes.
Each test fixture has a corresponding and same named test suite. This means only		Each test fixture has a corresponding and same named test suite. This means only
one test suite can use a particular fixture. Sometimes, however, multiple test		one test suite can use a particular fixture. Sometimes, however, multiple test
cases may want to use the same or slightly different fixtures. For example, you		cases may want to use the same or slightly different fixtures. For example, you
may want to make sure that all of a GUI library's test suites don't leak		may want to make sure that all of a GUI library's test suites don't leak
important system resources like fonts and brushes.		important system resources like fonts and brushes.
In googletest, you share a fixture among test suites by putting the shared logic		In GoogleTest, you share a fixture among test suites by putting the shared logic
in a base test fixture, then deriving from that base a separate fixture for each		in a base test fixture, then deriving from that base a separate fixture for each
test suite that wants to use this common logic. You then use `TEST_F()` to write		test suite that wants to use this common logic. You then use `TEST_F()` to write
tests using each derived fixture.		tests using each derived fixture.
Typically, your code looks like this:		Typically, your code looks like this:
```c++		```c++
// Defines a base test fixture.		// Defines a base test fixture.
class BaseTest : public ::testing::Test {		class BaseTest : public ::testing::Test {
protected:		protected:
skipping to change at line 267		skipping to change at line 267
};		};
// Tests that use the fixture FooTest.		// Tests that use the fixture FooTest.
TEST_F(FooTest, Bar) { ... }		TEST_F(FooTest, Bar) { ... }
TEST_F(FooTest, Baz) { ... }		TEST_F(FooTest, Baz) { ... }
... additional fixtures derived from BaseTest ...		... additional fixtures derived from BaseTest ...
```		```
If necessary, you can continue to derive test fixtures from a derived fixture.		If necessary, you can continue to derive test fixtures from a derived fixture.
googletest has no limit on how deep the hierarchy can be.		GoogleTest has no limit on how deep the hierarchy can be.
For a complete example using derived test fixtures, see		For a complete example using derived test fixtures, see
[sample5_unittest.cc](https://github.com/google/googletest/blob/master/googletes t/samples/sample5_unittest.cc).		[sample5_unittest.cc](https://github.com/google/googletest/blob/master/googletes t/samples/sample5_unittest.cc).
## My compiler complains "void value not ignored as it ought to be." What does t his mean?		## My compiler complains "void value not ignored as it ought to be." What does t his mean?
You're probably using an `ASSERT_*()` in a function that doesn't return `void`.		You're probably using an `ASSERT_*()` in a function that doesn't return `void`.
`ASSERT_*()` can only be used in `void` functions, due to exceptions being		`ASSERT_*()` can only be used in `void` functions, due to exceptions being
disabled by our build system. Please see more details		disabled by our build system. Please see more details
[here](advanced.md#assertion-placement).		[here](advanced.md#assertion-placement).
## My death test hangs (or seg-faults). How do I fix it?		## My death test hangs (or seg-faults). How do I fix it?
In googletest, death tests are run in a child process and the way they work is		In GoogleTest, death tests are run in a child process and the way they work is
delicate. To write death tests you really need to understand how they work—see		delicate. To write death tests you really need to understand how they work—see
the details at [Death Assertions](reference/assertions.md#death) in the		the details at [Death Assertions](reference/assertions.md#death) in the
Assertions Reference.		Assertions Reference.
In particular, death tests don't like having multiple threads in the parent		In particular, death tests don't like having multiple threads in the parent
process. So the first thing you can try is to eliminate creating threads outside		process. So the first thing you can try is to eliminate creating threads outside
of `EXPECT_DEATH()`. For example, you may want to use mocks or fake objects		of `EXPECT_DEATH()`. For example, you may want to use mocks or fake objects
instead of real ones in your tests.		instead of real ones in your tests.
Sometimes this is impossible as some library you must use may be creating		Sometimes this is impossible as some library you must use may be creating
skipping to change at line 308		skipping to change at line 308
If you go with thread-safe death tests, remember that they rerun the test		If you go with thread-safe death tests, remember that they rerun the test
program from the beginning in the child process. Therefore make sure your		program from the beginning in the child process. Therefore make sure your
program can run side-by-side with itself and is deterministic.		program can run side-by-side with itself and is deterministic.
In the end, this boils down to good concurrent programming. You have to make		In the end, this boils down to good concurrent programming. You have to make
sure that there are no race conditions or deadlocks in your program. No silver		sure that there are no race conditions or deadlocks in your program. No silver
bullet - sorry!		bullet - sorry!
## Should I use the constructor/destructor of the test fixture or SetUp()/TearDo wn()? {#CtorVsSetUp}		## Should I use the constructor/destructor of the test fixture or SetUp()/TearDo wn()? {#CtorVsSetUp}
The first thing to remember is that googletest does **not** reuse the same test		The first thing to remember is that GoogleTest does **not** reuse the same test
fixture object across multiple tests. For each `TEST_F`, googletest will create		fixture object across multiple tests. For each `TEST_F`, GoogleTest will create
a **fresh** test fixture object, immediately call `SetUp()`, run the test body,		a **fresh** test fixture object, immediately call `SetUp()`, run the test body,
call `TearDown()`, and then delete the test fixture object.		call `TearDown()`, and then delete the test fixture object.
When you need to write per-test set-up and tear-down logic, you have the choice		When you need to write per-test set-up and tear-down logic, you have the choice
between using the test fixture constructor/destructor or `SetUp()/TearDown()`.		between using the test fixture constructor/destructor or `SetUp()/TearDown()`.
The former is usually preferred, as it has the following benefits:		The former is usually preferred, as it has the following benefits:
* By initializing a member variable in the constructor, we have the option to		* By initializing a member variable in the constructor, we have the option to
make it `const`, which helps prevent accidental changes to its value and		make it `const`, which helps prevent accidental changes to its value and
makes the tests more obviously correct.		makes the tests more obviously correct.
skipping to change at line 331		skipping to change at line 331
constructor is guaranteed to call the base class' constructor *first*, and		constructor is guaranteed to call the base class' constructor *first*, and
the subclass' destructor is guaranteed to call the base class' destructor		the subclass' destructor is guaranteed to call the base class' destructor
*afterward*. With `SetUp()/TearDown()`, a subclass may make the mistake of		*afterward*. With `SetUp()/TearDown()`, a subclass may make the mistake of
forgetting to call the base class' `SetUp()/TearDown()` or call them at the		forgetting to call the base class' `SetUp()/TearDown()` or call them at the
wrong time.		wrong time.
You may still want to use `SetUp()/TearDown()` in the following cases:		You may still want to use `SetUp()/TearDown()` in the following cases:
* C++ does not allow virtual function calls in constructors and destructors.		* C++ does not allow virtual function calls in constructors and destructors.
You can call a method declared as virtual, but it will not use dynamic		You can call a method declared as virtual, but it will not use dynamic
dispatch, it will use the definition from the class the constructor of which		dispatch. It will use the definition from the class the constructor of which
is currently executing. This is because calling a virtual method before the		is currently executing. This is because calling a virtual method before the
derived class constructor has a chance to run is very dangerous - the		derived class constructor has a chance to run is very dangerous - the
virtual method might operate on uninitialized data. Therefore, if you need		virtual method might operate on uninitialized data. Therefore, if you need
to call a method that will be overridden in a derived class, you have to use		to call a method that will be overridden in a derived class, you have to use
`SetUp()/TearDown()`.		`SetUp()/TearDown()`.
* In the body of a constructor (or destructor), it's not possible to use the		* In the body of a constructor (or destructor), it's not possible to use the
`ASSERT_xx` macros. Therefore, if the set-up operation could cause a fatal		`ASSERT_xx` macros. Therefore, if the set-up operation could cause a fatal
test failure that should prevent the test from running, it's necessary to		test failure that should prevent the test from running, it's necessary to
use `abort` and abort the whole test		use `abort` and abort the whole test
executable, or to use `SetUp()` instead of a constructor.		executable, or to use `SetUp()` instead of a constructor.
* If the tear-down operation could throw an exception, you must use		* If the tear-down operation could throw an exception, you must use
`TearDown()` as opposed to the destructor, as throwing in a destructor leads		`TearDown()` as opposed to the destructor, as throwing in a destructor leads
to undefined behavior and usually will kill your program right away. Note		to undefined behavior and usually will kill your program right away. Note
that many standard libraries (like STL) may throw when exceptions are		that many standard libraries (like STL) may throw when exceptions are
enabled in the compiler. Therefore you should prefer `TearDown()` if you		enabled in the compiler. Therefore you should prefer `TearDown()` if you
want to write portable tests that work with or without exceptions.		want to write portable tests that work with or without exceptions.
* The googletest team is considering making the assertion macros throw on		* The GoogleTest team is considering making the assertion macros throw on
platforms where exceptions are enabled (e.g. Windows, Mac OS, and Linux		platforms where exceptions are enabled (e.g. Windows, Mac OS, and Linux
client-side), which will eliminate the need for the user to propagate		client-side), which will eliminate the need for the user to propagate
failures from a subroutine to its caller. Therefore, you shouldn't use		failures from a subroutine to its caller. Therefore, you shouldn't use
googletest assertions in a destructor if your code could run on such a		GoogleTest assertions in a destructor if your code could run on such a
platform.		platform.
## The compiler complains "no matching function to call" when I use ASSERT_PRED* . How do I fix it?		## The compiler complains "no matching function to call" when I use ASSERT_PRED* . How do I fix it?
See details for [`EXPECT_PRED*`](reference/assertions.md#EXPECT_PRED) in the		See details for [`EXPECT_PRED*`](reference/assertions.md#EXPECT_PRED) in the
Assertions Reference.		Assertions Reference.
## My compiler complains about "ignoring return value" when I call RUN_ALL_TESTS (). Why?		## My compiler complains about "ignoring return value" when I call RUN_ALL_TESTS (). Why?
Some people had been ignoring the return value of `RUN_ALL_TESTS()`. That is,		Some people had been ignoring the return value of `RUN_ALL_TESTS()`. That is,
skipping to change at line 378		skipping to change at line 378
they write		they write
```c++		```c++
RUN_ALL_TESTS();		RUN_ALL_TESTS();
```		```
This is **wrong and dangerous**. The testing services needs to see the return		This is **wrong and dangerous**. The testing services needs to see the return
value of `RUN_ALL_TESTS()` in order to determine if a test has passed. If your		value of `RUN_ALL_TESTS()` in order to determine if a test has passed. If your
`main()` function ignores it, your test will be considered successful even if it		`main()` function ignores it, your test will be considered successful even if it
has a googletest assertion failure. Very bad.		has a GoogleTest assertion failure. Very bad.
We have decided to fix this (thanks to Michael Chastain for the idea). Now, your		We have decided to fix this (thanks to Michael Chastain for the idea). Now, your
code will no longer be able to ignore `RUN_ALL_TESTS()` when compiled with		code will no longer be able to ignore `RUN_ALL_TESTS()` when compiled with
`gcc`. If you do so, you'll get a compiler error.		`gcc`. If you do so, you'll get a compiler error.
If you see the compiler complaining about you ignoring the return value of		If you see the compiler complaining about you ignoring the return value of
`RUN_ALL_TESTS()`, the fix is simple: just make sure its value is used as the		`RUN_ALL_TESTS()`, the fix is simple: just make sure its value is used as the
return value of `main()`.		return value of `main()`.
But how could we introduce a change that breaks existing tests? Well, in this		But how could we introduce a change that breaks existing tests? Well, in this
skipping to change at line 443		skipping to change at line 443
TEST_F(FooTest, Abc) { ... }		TEST_F(FooTest, Abc) { ... }
TEST_F(FooTest, Def) { ... }		TEST_F(FooTest, Def) { ... }
typedef BaseTest BarTest;		typedef BaseTest BarTest;
TEST_F(BarTest, Abc) { ... }		TEST_F(BarTest, Abc) { ... }
TEST_F(BarTest, Def) { ... }		TEST_F(BarTest, Def) { ... }
```		```
## googletest output is buried in a whole bunch of LOG messages. What do I do?		## GoogleTest output is buried in a whole bunch of LOG messages. What do I do?
The googletest output is meant to be a concise and human-friendly report. If		The GoogleTest output is meant to be a concise and human-friendly report. If
your test generates textual output itself, it will mix with the googletest		your test generates textual output itself, it will mix with the GoogleTest
output, making it hard to read. However, there is an easy solution to this		output, making it hard to read. However, there is an easy solution to this
problem.		problem.
Since `LOG` messages go to stderr, we decided to let googletest output go to		Since `LOG` messages go to stderr, we decided to let GoogleTest output go to
stdout. This way, you can easily separate the two using redirection. For		stdout. This way, you can easily separate the two using redirection. For
example:		example:
```shell		```shell
$ ./my_test > gtest_output.txt		$ ./my_test > gtest_output.txt
```		```
## Why should I prefer test fixtures over global variables?		## Why should I prefer test fixtures over global variables?
There are several good reasons:		There are several good reasons:
skipping to change at line 523		skipping to change at line 523
for (int i = 0; i < 5; i++) {		for (int i = 0; i < 5; i++) {
Bar(i);		Bar(i);
}		}
},		},
"Bar has \\d+ errors");		"Bar has \\d+ errors");
}		}
```		```
## I have a fixture class `FooTest`, but `TEST_F(FooTest, Bar)` gives me error ` `"no matching function for call to `FooTest::FooTest()'"``. Why?		## I have a fixture class `FooTest`, but `TEST_F(FooTest, Bar)` gives me error ` `"no matching function for call to `FooTest::FooTest()'"``. Why?
Googletest needs to be able to create objects of your test fixture class, so it		GoogleTest needs to be able to create objects of your test fixture class, so it
must have a default constructor. Normally the compiler will define one for you.		must have a default constructor. Normally the compiler will define one for you.
However, there are cases where you have to define your own:		However, there are cases where you have to define your own:
* If you explicitly declare a non-default constructor for class `FooTest`		* If you explicitly declare a non-default constructor for class `FooTest`
(`DISALLOW_EVIL_CONSTRUCTORS()` does this), then you need to define a		(`DISALLOW_EVIL_CONSTRUCTORS()` does this), then you need to define a
default constructor, even if it would be empty.		default constructor, even if it would be empty.
* If `FooTest` has a const non-static data member, then you have to define the		* If `FooTest` has a const non-static data member, then you have to define the
default constructor *and* initialize the const member in the initializer		default constructor *and* initialize the const member in the initializer
list of the constructor. (Early versions of `gcc` doesn't force you to		list of the constructor. (Early versions of `gcc` doesn't force you to
initialize the const member. It's a bug that has been fixed in `gcc 4`.)		initialize the const member. It's a bug that has been fixed in `gcc 4`.)
skipping to change at line 548		skipping to change at line 548
from a single thread to multiple threads. The first time you create a thread, a		from a single thread to multiple threads. The first time you create a thread, a
manager thread is created in addition, so you get 3, not 2, threads. Later when		manager thread is created in addition, so you get 3, not 2, threads. Later when
the thread you create joins the main thread, the thread count decrements by 1,		the thread you create joins the main thread, the thread count decrements by 1,
but the manager thread will never be killed, so you still have 2 threads, which		but the manager thread will never be killed, so you still have 2 threads, which
means you cannot safely run a death test.		means you cannot safely run a death test.
The new NPTL thread library doesn't suffer from this problem, as it doesn't		The new NPTL thread library doesn't suffer from this problem, as it doesn't
create a manager thread. However, if you don't control which machine your test		create a manager thread. However, if you don't control which machine your test
runs on, you shouldn't depend on this.		runs on, you shouldn't depend on this.
## Why does googletest require the entire test suite, instead of individual test s, to be named *DeathTest when it uses ASSERT_DEATH?		## Why does GoogleTest require the entire test suite, instead of individual test s, to be named *DeathTest when it uses ASSERT_DEATH?
googletest does not interleave tests from different test suites. That is, it		GoogleTest does not interleave tests from different test suites. That is, it
runs all tests in one test suite first, and then runs all tests in the next test		runs all tests in one test suite first, and then runs all tests in the next test
suite, and so on. googletest does this because it needs to set up a test suite		suite, and so on. GoogleTest does this because it needs to set up a test suite
before the first test in it is run, and tear it down afterwards. Splitting up		before the first test in it is run, and tear it down afterwards. Splitting up
the test case would require multiple set-up and tear-down processes, which is		the test case would require multiple set-up and tear-down processes, which is
inefficient and makes the semantics unclean.		inefficient and makes the semantics unclean.
If we were to determine the order of tests based on test name instead of test		If we were to determine the order of tests based on test name instead of test
case name, then we would have a problem with the following situation:		case name, then we would have a problem with the following situation:
```c++		```c++
TEST_F(FooTest, AbcDeathTest) { ... }		TEST_F(FooTest, AbcDeathTest) { ... }
TEST_F(FooTest, Uvw) { ... }		TEST_F(FooTest, Uvw) { ... }
skipping to change at line 591		skipping to change at line 591
TEST_F(FooTest, Abc) { ... }		TEST_F(FooTest, Abc) { ... }
TEST_F(FooTest, Def) { ... }		TEST_F(FooTest, Def) { ... }
using FooDeathTest = FooTest;		using FooDeathTest = FooTest;
TEST_F(FooDeathTest, Uvw) { ... EXPECT_DEATH(...) ... }		TEST_F(FooDeathTest, Uvw) { ... EXPECT_DEATH(...) ... }
TEST_F(FooDeathTest, Xyz) { ... ASSERT_DEATH(...) ... }		TEST_F(FooDeathTest, Xyz) { ... ASSERT_DEATH(...) ... }
```		```
## 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?		## 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?
Printing the LOG messages generated by the statement inside `EXPECT_DEATH()`		Printing the LOG messages generated by the statement inside `EXPECT_DEATH()`
makes it harder to search for real problems in the parent's log. Therefore,		makes it harder to search for real problems in the parent's log. Therefore,
googletest only prints them when the death test has failed.		GoogleTest only prints them when the death test has failed.
If you really need to see such LOG messages, a workaround is to temporarily		If you really need to see such LOG messages, a workaround is to temporarily
break the death test (e.g. by changing the regex pattern it is expected to		break the death test (e.g. by changing the regex pattern it is expected to
match). Admittedly, this is a hack. We'll consider a more permanent solution		match). Admittedly, this is a hack. We'll consider a more permanent solution
after the fork-and-exec-style death tests are implemented.		after the fork-and-exec-style death tests are implemented.
## The compiler complains about `no match for 'operator<<'` when I use an assert ion. What gives?		## The compiler complains about `no match for 'operator<<'` when I use an assert ion. What gives?
If you use a user-defined type `FooType` in an assertion, you must make sure		If you use a user-defined type `FooType` in an assertion, you must make sure
there is an `std::ostream& operator<<(std::ostream&, const FooType&)` function		there is an `std::ostream& operator<<(std::ostream&, const FooType&)` function
defined such that we can print a value of `FooType`.		defined such that we can print a value of `FooType`.
In addition, if `FooType` is declared in a name space, the `<<` operator also		In addition, if `FooType` is declared in a name space, the `<<` operator also
needs to be defined in the *same* name space. See		needs to be defined in the *same* name space. See
[Tip of the Week #49](http://abseil.io/tips/49) for details.		[Tip of the Week #49](http://abseil.io/tips/49) for details.
## How do I suppress the memory leak messages on Windows?		## How do I suppress the memory leak messages on Windows?
Since the statically initialized googletest singleton requires allocations on		Since the statically initialized GoogleTest singleton requires allocations on
the heap, the Visual C++ memory leak detector will report memory leaks at the		the heap, the Visual C++ memory leak detector will report memory leaks at the
end of the program run. The easiest way to avoid this is to use the		end of the program run. The easiest way to avoid this is to use the
`_CrtMemCheckpoint` and `_CrtMemDumpAllObjectsSince` calls to not report any		`_CrtMemCheckpoint` and `_CrtMemDumpAllObjectsSince` calls to not report any
statically initialized heap objects. See MSDN for more details and additional		statically initialized heap objects. See MSDN for more details and additional
heap check/debug routines.		heap check/debug routines.
## How can my code detect if it is running in a test?		## How can my code detect if it is running in a test?
If you write code that sniffs whether it's running in a test and does different		If you write code that sniffs whether it's running in a test and does different
things accordingly, you are leaking test-only logic into production code and		things accordingly, you are leaking test-only logic into production code and
there is no easy way to ensure that the test-only code paths aren't run by		there is no easy way to ensure that the test-only code paths aren't run by
mistake in production. Such cleverness also leads to		mistake in production. Such cleverness also leads to
[Heisenbugs](https://en.wikipedia.org/wiki/Heisenbug). Therefore we strongly		[Heisenbugs](https://en.wikipedia.org/wiki/Heisenbug). Therefore we strongly
advise against the practice, and googletest doesn't provide a way to do it.		advise against the practice, and GoogleTest doesn't provide a way to do it.
In general, the recommended way to cause the code to behave differently under		In general, the recommended way to cause the code to behave differently under
test is [Dependency Injection](http://en.wikipedia.org/wiki/Dependency_injection ). You can inject		test is [Dependency Injection](http://en.wikipedia.org/wiki/Dependency_injection ). You can inject
different functionality from the test and from the production code. Since your		different functionality from the test and from the production code. Since your
production code doesn't link in the for-test logic at all (the		production code doesn't link in the for-test logic at all (the
[`testonly`](http://docs.bazel.build/versions/master/be/common-definitions.html# common.testonly) attribute for BUILD targets helps to ensure		[`testonly`](http://docs.bazel.build/versions/master/be/common-definitions.html# common.testonly) attribute for BUILD targets helps to ensure
that), there is no danger in accidentally running it.		that), there is no danger in accidentally running it.
However, if you *really*, *really*, *really* have no choice, and if you follow		However, if you *really*, *really*, *really* have no choice, and if you follow
the rule of ending your test program names with `_test`, you can use the		the rule of ending your test program names with `_test`, you can use the
skipping to change at line 675		skipping to change at line 675
} // namespace foo		} // namespace foo
namespace bar {		namespace bar {
TEST(CoolTest, DoSomething) {		TEST(CoolTest, DoSomething) {
SUCCEED();		SUCCEED();
}		}
} // namespace bar		} // namespace bar
```		```
However, the following code is **not allowed** and will produce a runtime error		However, the following code is **not allowed** and will produce a runtime error
from googletest because the test methods are using different test fixture		from GoogleTest because the test methods are using different test fixture
classes with the same test suite name.		classes with the same test suite name.
```c++		```c++
namespace foo {		namespace foo {
class CoolTest : public ::testing::Test {}; // Fixture foo::CoolTest		class CoolTest : public ::testing::Test {}; // Fixture foo::CoolTest
TEST_F(CoolTest, DoSomething) {		TEST_F(CoolTest, DoSomething) {
SUCCEED();		SUCCEED();
}		}
} // namespace foo		} // namespace foo
End of changes. 28 change blocks.
30 lines changed or deleted		30 lines changed or added

---