-| `IsFalse()` | `argument` evaluates to `false` in a Boolean context. |
-| `IsTrue()` | `argument` evaluates to `true` in a Boolean context. |
-| `IsNull()` | `argument` is a `NULL` pointer (raw or smart). |
-| `NotNull()` | `argument` is a non-null pointer (raw or smart). |
-| `Optional(m)` | `argument` is `optional<>` that contains a value matching `m`. (For testing whether an `optional<>` is set, check for equality with `nullopt`. You may need to use `Eq(nullopt)` if the inner type doesn't have `==`.)|
-| `VariantWith<T>(m)` | `argument` is `variant<>` that holds the alternative of type T with a value matching `m`. |
-| `Ref(variable)` | `argument` is a reference to `variable`. |
-| `TypedEq<type>(value)` | `argument` has type `type` and is equal to `value`. You may need to use this instead of `Eq(value)` when the mock function is overloaded. |
-<!-- mdformat on -->
-
-Except `Ref()`, these matchers make a *copy* of `value` in case it's modified or
-destructed later. If the compiler complains that `value` doesn't have a public
-copy constructor, try wrap it in `ByRef()`, e.g.
-`Eq(ByRef(non_copyable_value))`. If you do that, make sure `non_copyable_value`
-is not changed afterwards, or the meaning of your matcher will be changed.
-
-`IsTrue` and `IsFalse` are useful when you need to use a matcher, or for types
-that can be explicitly converted to Boolean, but are not implicitly converted to
-Boolean. In other cases, you can use the basic
-[`EXPECT_TRUE` and `EXPECT_FALSE`](../../googletest/docs/primer#basic-assertions)
-| `DoubleNear(a_double, max_abs_error)` | `argument` is a `double` value close to `a_double` (absolute error <= `max_abs_error`), treating two NaNs as unequal. |
-| `FloatNear(a_float, max_abs_error)` | `argument` is a `float` value close to `a_float` (absolute error <= `max_abs_error`), treating two NaNs as unequal. |
-| `NanSensitiveDoubleNear(a_double, max_abs_error)` | `argument` is a `double` value close to `a_double` (absolute error <= `max_abs_error`), treating two NaNs as equal. |
-| `NanSensitiveFloatNear(a_float, max_abs_error)` | `argument` is a `float` value close to `a_float` (absolute error <= `max_abs_error`), treating two NaNs as equal. |
-<!-- mdformat on -->
-
-#### String Matchers
-
-The `argument` can be either a C string or a C++ string object:
-| `ContainsRegex(string)` | `argument` matches the given regular expression. |
-| `EndsWith(suffix)` | `argument` ends with string `suffix`. |
-| `HasSubstr(string)` | `argument` contains `string` as a sub-string. |
-| `MatchesRegex(string)` | `argument` matches the given regular expression with the match starting at the first character and ending at the last character. |
-| `StartsWith(prefix)` | `argument` starts with string `prefix`. |
-| `StrCaseEq(string)` | `argument` is equal to `string`, ignoring case. |
-| `StrCaseNe(string)` | `argument` is not equal to `string`, ignoring case. |
-| `StrEq(string)` | `argument` is equal to `string`. |
-| `StrNe(string)` | `argument` is not equal to `string`. |
-<!-- mdformat on -->
-
-`ContainsRegex()` and `MatchesRegex()` take ownership of the `RE` object. They
-use the regular expression syntax defined
-[here](../../googletest/docs/advanced.md#regular-expression-syntax). All of
-these matchers, except `ContainsRegex()` and `MatchesRegex()` work for wide
-strings as well.
-
-#### Container Matchers
-
-Most STL-style containers support `==`, so you can use `Eq(expected_container)`
-or simply `expected_container` to match a container exactly. If you want to
-write the elements in-line, match them more flexibly, or get more informative
-| `BeginEndDistanceIs(m)` | `argument` is a container whose `begin()` and `end()` iterators are separated by a number of increments matching `m`. E.g. `BeginEndDistanceIs(2)` or `BeginEndDistanceIs(Lt(2))`. For containers that define a `size()` method, `SizeIs(m)` may be more efficient. |
-| `ContainerEq(container)` | The same as `Eq(container)` except that the failure message also includes which elements are in one container but not the other. |
-| `Contains(e)` | `argument` contains an element that matches `e`, which can be either a value or a matcher. |
-| `Each(e)` | `argument` is a container where *every* element matches `e`, which can be either a value or a matcher. |
-| `ElementsAre(e0, e1, ..., en)` | `argument` has `n + 1` elements, where the *i*-th element matches `ei`, which can be a value or a matcher. |
-| `ElementsAreArray({e0, e1, ..., en})`, `ElementsAreArray(a_container)`, `ElementsAreArray(begin, end)`, `ElementsAreArray(array)`, or `ElementsAreArray(array, count)` | The same as `ElementsAre()` except that the expected element values/matchers come from an initializer list, STL-style container, iterator range, or C-style array. |
-| `IsEmpty()` | `argument` is an empty container (`container.empty()`). |
-| `IsSubsetOf({e0, e1, ..., en})`, `IsSubsetOf(a_container)`, `IsSubsetOf(begin, end)`, `IsSubsetOf(array)`, or `IsSubsetOf(array, count)` | `argument` matches `UnorderedElementsAre(x0, x1, ..., xk)` for some subset `{x0, x1, ..., xk}` of the expected matchers. |
-| `IsSupersetOf({e0, e1, ..., en})`, `IsSupersetOf(a_container)`, `IsSupersetOf(begin, end)`, `IsSupersetOf(array)`, or `IsSupersetOf(array, count)` | Some subset of `argument` matches `UnorderedElementsAre(`expected matchers`)`. |
-| `Pointwise(m, container)`, `Pointwise(m, {e0, e1, ..., en})` | `argument` contains the same number of elements as in `container`, and for all i, (the i-th element in `argument`, the i-th element in `container`) match `m`, which is a matcher on 2-tuples. E.g. `Pointwise(Le(), upper_bounds)` verifies that each element in `argument` doesn't exceed the corresponding element in `upper_bounds`. See more detail below. |
-| `SizeIs(m)` | `argument` is a container whose size matches `m`. E.g. `SizeIs(2)` or `SizeIs(Lt(2))`. |
-| `UnorderedElementsAre(e0, e1, ..., en)` | `argument` has `n + 1` elements, and under *some* permutation of the elements, each element matches an `ei` (for a different `i`), which can be a value or a matcher. |
-| `UnorderedElementsAreArray({e0, e1, ..., en})`, `UnorderedElementsAreArray(a_container)`, `UnorderedElementsAreArray(begin, end)`, `UnorderedElementsAreArray(array)`, or `UnorderedElementsAreArray(array, count)` | The same as `UnorderedElementsAre()` except that the expected element values/matchers come from an initializer list, STL-style container, iterator range, or C-style array. |
-| `UnorderedPointwise(m, container)`, `UnorderedPointwise(m, {e0, e1, ..., en})` | Like `Pointwise(m, container)`, but ignores the order of elements. |
-| `WhenSorted(m)` | When `argument` is sorted using the `<` operator, it matches container matcher `m`. E.g. `WhenSorted(ElementsAre(1, 2, 3))` verifies that `argument` contains elements 1, 2, and 3, ignoring order. |
-| `WhenSortedBy(comparator, m)` | The same as `WhenSorted(m)`, except that the given comparator instead of `<` is used to sort `argument`. E.g. `WhenSortedBy(std::greater(), ElementsAre(3, 2, 1))`. |
-<!-- mdformat on -->
-
-**Notes:**
-
-* These matchers can also match:
- 1. a native array passed by reference (e.g. in `Foo(const int (&a)[5])`),
- and
- 2. an array passed as a pointer and a count (e.g. in `Bar(const T* buffer,
- int len)` -- see [Multi-argument Matchers](#MultiArgMatchers)).
-* The array being matched may be multi-dimensional (i.e. its elements can be
- arrays).
-* `m` in `Pointwise(m, ...)` should be a matcher for `::std::tuple<T, U>`
- where `T` and `U` are the element type of the actual container and the
- expected container, respectively. For example, to compare two `Foo`
- containers where `Foo` doesn't support `operator==`, one might write:
-| `Field(&class::field, m)` | `argument.field` (or `argument->field` when `argument` is a plain pointer) matches matcher `m`, where `argument` is an object of type _class_. |
-| `Key(e)` | `argument.first` matches `e`, which can be either a value or a matcher. E.g. `Contains(Key(Le(5)))` can verify that a `map` contains a key `<= 5`. |
-| `Pair(m1, m2)` | `argument` is an `std::pair` whose `first` field matches `m1` and `second` field matches `m2`. |
-| `Property(&class::property, m)` | `argument.property()` (or `argument->property()` when `argument` is a plain pointer) matches matcher `m`, where `argument` is an object of type _class_. |
-<!-- mdformat on -->
-
-#### Matching the Result of a Function, Functor, or Callback
-| `AllOf(m1, m2, ..., mn)` | `argument` matches all of the matchers `m1` to `mn`. |
-| `AllOfArray({m0, m1, ..., mn})`, `AllOfArray(a_container)`, `AllOfArray(begin, end)`, `AllOfArray(array)`, or `AllOfArray(array, count)` | The same as `AllOf()` except that the matchers come from an initializer list, STL-style container, iterator range, or C-style array. |
-| `AnyOf(m1, m2, ..., mn)` | `argument` matches at least one of the matchers `m1` to `mn`. |
-| `AnyOfArray({m0, m1, ..., mn})`, `AnyOfArray(a_container)`, `AnyOfArray(begin, end)`, `AnyOfArray(array)`, or `AnyOfArray(array, count)` | The same as `AnyOf()` except that the matchers come from an initializer list, STL-style container, iterator range, or C-style array. |
-| `Not(m)` | `argument` doesn't match matcher `m`. |
-| `MATCHER(IsEven, "") { return (arg % 2) == 0; }` | Defines a matcher `IsEven()` to match an even number. |
-| `MATCHER_P(IsDivisibleBy, n, "") { *result_listener << "where the remainder is " << (arg % n); return (arg % n) == 0; }` | Defines a macher `IsDivisibleBy(n)` to match a number divisible by `n`. |
-| `MATCHER_P2(IsBetween, a, b, std::string(negation ? "isn't" : "is") + " between " + PrintToString(a) + " and " + PrintToString(b)) { return a <= arg && arg <= b; }` | Defines a matcher `IsBetween(a, b)` to match a value in the range [`a`, `b`]. |
-<!-- mdformat on -->
-
-**Notes:**
-
-1. The `MATCHER*` macros cannot be used inside a function or class.
-2. The matcher body must be *purely functional* (i.e. it cannot have any side
- effect, and the result must not depend on anything other than the value
- being matched and the matcher parameters).
-3. You can use `PrintToString(x)` to convert a value `x` of any type to a
- string.
-
-### Actions {#ActionList}
-
-**Actions** specify what a mock function should do when invoked.
-| `Return()` | Return from a `void` mock function. |
-| `Return(value)` | Return `value`. If the type of `value` is different to the mock function's return type, `value` is converted to the latter type <i>at the time the expectation is set</i>, not when the action is executed. |
-| `ReturnArg<N>()` | Return the `N`-th (0-based) argument. |
-| `ReturnNew<T>(a1, ..., ak)` | Return `new T(a1, ..., ak)`; a different object is created each time. |
-| `ReturnNull()` | Return a null pointer. |
-| `ReturnPointee(ptr)` | Return the value pointed to by `ptr`. |
-| `ReturnRef(variable)` | Return a reference to `variable`. |
-| `ReturnRefOfCopy(value)` | Return a reference to a copy of `value`; the copy lives as long as the action. |
-| `ReturnRoundRobin({a1, ..., ak})` | Each call will return the next `ai` in the list, starting at the beginning when the end of the list is reached. |
-| `Assign(&variable, value)` | Assign `value` to variable. |
-| `DeleteArg<N>()` | Delete the `N`-th (0-based) argument, which must be a pointer. |
-| `SaveArg<N>(pointer)` | Save the `N`-th (0-based) argument to `*pointer`. |
-| `SaveArgPointee<N>(pointer)` | Save the value pointed to by the `N`-th (0-based) argument to `*pointer`. |
-| `SetArgReferee<N>(value)` | Assign value to the variable referenced by the `N`-th (0-based) argument. |
-| `SetArgPointee<N>(value)` | Assign `value` to the variable pointed by the `N`-th (0-based) argument. |
-| `SetArgumentPointee<N>(value)` | Same as `SetArgPointee<N>(value)`. Deprecated. Will be removed in v1.7.0. |
-| `SetArrayArgument<N>(first, last)` | Copies the elements in source range [`first`, `last`) to the array pointed to by the `N`-th (0-based) argument, which can be either a pointer or an iterator. The action does not take ownership of the elements in the source range. |
-| `SetErrnoAndReturn(error, value)` | Set `errno` to `error` and return `value`. |
-| `Throw(exception)` | Throws the given exception, which can be any copyable value. Available since v1.1.0. |
-<!-- mdformat on -->
-
-#### Using a Function, Functor, or Lambda as an Action
-
-In the following, by "callable" we mean a free function, `std::function`,
-| `f` | Invoke f with the arguments passed to the mock function, where f is a callable. |
-| `Invoke(f)` | Invoke `f` with the arguments passed to the mock function, where `f` can be a global/static function or a functor. |
-| `Invoke(object_pointer, &class::method)` | Invoke the method on the object with the arguments passed to the mock function. |
-| `InvokeWithoutArgs(f)` | Invoke `f`, which can be a global/static function or a functor. `f` must take no arguments. |
-| `InvokeWithoutArgs(object_pointer, &class::method)` | Invoke the method on the object, which takes no arguments. |
-| `InvokeArgument<N>(arg1, arg2, ..., argk)` | Invoke the mock function's `N`-th (0-based) argument, which must be a function or a functor, with the `k` arguments. |
-<!-- mdformat on -->
-
-The return value of the invoked function is used as the return value of the
-action.
-
-When defining a callable to be used with `Invoke*()`, you can declare any unused
-| `DoAll(a1, a2, ..., an)` | Do all actions `a1` to `an` and return the result of `an` in each invocation. The first `n - 1` sub-actions must return void. |
-| `IgnoreResult(a)` | Perform action `a` and ignore its result. `a` must not return void. |
-| `WithArg<N>(a)` | Pass the `N`-th (0-based) argument of the mock function to action `a` and perform it. |
-| `WithArgs<N1, N2, ..., Nk>(a)` | Pass the selected (0-based) arguments of the mock function to action `a` and perform it. |
-| `WithoutArgs(a)` | Perform action `a` without any arguments. |
-You cannot mock a variadic function (i.e. a function taking ellipsis (`...`)
-arguments) directly in gMock.
-
-The problem is that in general, there is *no way* for a mock object to know how
-many arguments are passed to the variadic method, and what the arguments' types
-are. Only the *author of the base class* knows the protocol, and we cannot look
-into his or her head.
-
-Therefore, to mock such a function, the *user* must teach the mock object how to
-figure out the number of arguments and their types. One way to do it is to
-provide overloaded versions of the function.
-
-Ellipsis arguments are inherited from C and not really a C++ feature. They are
-unsafe to use and don't work with arguments that have constructors or
-destructors. Therefore we recommend to avoid them in C++ as much as possible.
-
-### MSVC gives me warning C4301 or C4373 when I define a mock method with a const parameter. Why?
-
-If you compile this using Microsoft Visual C++ 2005 SP1:
-
-```cpp
-class Foo {
- ...
- virtual void Bar(const int i) = 0;
-};
-
-class MockFoo : public Foo {
- ...
- MOCK_METHOD(void, Bar, (const int i), (override));
-};
-```
-
-You may get the following warning:
-
-```shell
-warning C4301: 'MockFoo::Bar': overriding virtual function only differs from 'Foo::Bar' by const/volatile qualifier
-```
-
-This is a MSVC bug. The same code compiles fine with gcc, for example. If you
-use Visual C++ 2008 SP1, you would get the warning:
-
-```shell
-warning C4373: 'MockFoo::Bar': virtual function overrides 'Foo::Bar', previous versions of the compiler did not override when parameters only differed by const/volatile qualifiers
-```
-
-In C++, if you *declare* a function with a `const` parameter, the `const`
-modifier is ignored. Therefore, the `Foo` base class above is equivalent to:
-
-```cpp
-class Foo {
- ...
- virtual void Bar(int i) = 0; // int or const int? Makes no difference.
-};
-```
-
-In fact, you can *declare* `Bar()` with an `int` parameter, and define it with a
-`const int` parameter. The compiler will still match them up.
-
-Since making a parameter `const` is meaningless in the method declaration, we
-recommend to remove it in both `Foo` and `MockFoo`. That should workaround the
-VC bug.
-
-Note that we are talking about the *top-level* `const` modifier here. If the
-function parameter is passed by pointer or reference, declaring the pointee or
-referee as `const` is still meaningful. For example, the following two
-declarations are *not* equivalent:
-
-```cpp
-void Bar(int* p); // Neither p nor *p is const.
-void Bar(const int* p); // p is not const, but *p is.
-```
-
-<!-- GOOGLETEST_CM0030 DO NOT DELETE -->
-
-### I can't figure out why gMock thinks my expectations are not satisfied. What should I do?
-
-You might want to run your test with `--gmock_verbose=info`. This flag lets
-gMock print a trace of every mock function call it receives. By studying the
-trace, you'll gain insights on why the expectations you set are not met.
-
-If you see the message "The mock function has no default action set, and its
-return type has no default value set.", then try
-[adding a default action](for_dummies.md#DefaultValue). Due to a known issue,
-unexpected calls on mocks without default actions don't print out a detailed
-comparison between the actual arguments and the expected arguments.
-
-### My program crashed and `ScopedMockLog` spit out tons of messages. Is it a gMock bug?
-
-gMock and `ScopedMockLog` are likely doing the right thing here.
-
-When a test crashes, the failure signal handler will try to log a lot of
-information (the stack trace, and the address map, for example). The messages
-are compounded if you have many threads with depth stacks. When `ScopedMockLog`
-intercepts these messages and finds that they don't match any expectations, it
-prints an error for each of them.
-
-You can learn to ignore the errors, or you can rewrite your expectations to make
-your test more robust, for example, by adding something like:
-### How can I assert that a function is NEVER called?
-
-```cpp
-using ::testing::_;
-...
- EXPECT_CALL(foo, Bar(_))
- .Times(0);
-```
-
-<!-- GOOGLETEST_CM0031 DO NOT DELETE -->
-
-### I have a failed test where gMock tells me TWICE that a particular expectation is not satisfied. Isn't this redundant?
-
-When gMock detects a failure, it prints relevant information (the mock function
-arguments, the state of relevant expectations, and etc) to help the user debug.
-If another failure is detected, gMock will do the same, including printing the
-state of relevant expectations.
-
-Sometimes an expectation's state didn't change between two failures, and you'll
-see the same description of the state twice. They are however *not* redundant,
-as they refer to *different points in time*. The fact they are the same *is*
-interesting information.
-
-### I get a heapcheck failure when using a mock object, but using a real object is fine. What can be wrong?
-
-Does the class (hopefully a pure interface) you are mocking have a virtual
-destructor?
-
-Whenever you derive from a base class, make sure its destructor is virtual.
-Otherwise Bad Things will happen. Consider the following code:
-
-```cpp
-class Base {
- public:
- // Not virtual, but should be.
- ~Base() { ... }
- ...
-};
-
-class Derived : public Base {
- public:
- ...
- private:
- std::string value_;
-};
-
-...
- Base* p = new Derived;
- ...
- delete p; // Surprise! ~Base() will be called, but ~Derived() will not
- // - value_ is leaked.
-```
-
-By changing `~Base()` to virtual, `~Derived()` will be correctly called when
-`delete p` is executed, and the heap checker will be happy.
-
-### The "newer expectations override older ones" rule makes writing expectations awkward. Why does gMock do that?
-
-When people complain about this, often they are referring to code like:
-
-```cpp
-using ::testing::Return;
-...
- // foo.Bar() should be called twice, return 1 the first time, and return
- // 2 the second time. However, I have to write the expectations in the
- // reverse order. This sucks big time!!!
- EXPECT_CALL(foo, Bar())
- .WillOnce(Return(2))
- .RetiresOnSaturation();
- EXPECT_CALL(foo, Bar())
- .WillOnce(Return(1))
- .RetiresOnSaturation();
-```
-
-The problem, is that they didn't pick the **best** way to express the test's
-intent.
-
-By default, expectations don't have to be matched in *any* particular order. If
-you want them to match in a certain order, you need to be explicit. This is
-gMock's (and jMock's) fundamental philosophy: it's easy to accidentally
-over-specify your tests, and we want to make it harder to do so.
-
-There are two better ways to write the test spec. You could either put the
-expectations in sequence:
-
-```cpp
-using ::testing::Return;
-...
- // foo.Bar() should be called twice, return 1 the first time, and return
- // 2 the second time. Using a sequence, we can write the expectations
- // in their natural order.
- {
- InSequence s;
- EXPECT_CALL(foo, Bar())
- .WillOnce(Return(1))
- .RetiresOnSaturation();
- EXPECT_CALL(foo, Bar())
- .WillOnce(Return(2))
- .RetiresOnSaturation();
- }
-```
-
-or you can put the sequence of actions in the same expectation:
-
-```cpp
-using ::testing::Return;
-...
- // foo.Bar() should be called twice, return 1 the first time, and return
- // 2 the second time.
- EXPECT_CALL(foo, Bar())
- .WillOnce(Return(1))
- .WillOnce(Return(2))
- .RetiresOnSaturation();
-```
-
-Back to the original questions: why does gMock search the expectations (and
-`ON_CALL`s) from back to front? Because this allows a user to set up a mock's
-behavior for the common case early (e.g. in the mock's constructor or the test
-fixture's set-up phase) and customize it with more specific rules later. If
-gMock searches from front to back, this very useful pattern won't be possible.
-
-### gMock prints a warning when a function without EXPECT_CALL is called, even if I have set its behavior using ON_CALL. Would it be reasonable not to show the warning in this case?
-
-When choosing between being neat and being safe, we lean toward the latter. So
-the answer is that we think it's better to show the warning.
-
-Often people write `ON_CALL`s in the mock object's constructor or `SetUp()`, as
-the default behavior rarely changes from test to test. Then in the test body
-they set the expectations, which are often different for each test. Having an
-`ON_CALL` in the set-up part of a test doesn't mean that the calls are expected.
-If there's no `EXPECT_CALL` and the method is called, it's possibly an error. If
-we quietly let the call go through without notifying the user, bugs may creep in
-unnoticed.
-
-If, however, you are sure that the calls are OK, you can write
-
-```cpp
-using ::testing::_;
-...
- EXPECT_CALL(foo, Bar(_))
- .WillRepeatedly(...);
-```
-
-instead of
-
-```cpp
-using ::testing::_;
-...
- ON_CALL(foo, Bar(_))
- .WillByDefault(...);
-```
-
-This tells gMock that you do expect the calls and no warning should be printed.
-
-Also, you can control the verbosity by specifying `--gmock_verbose=error`. Other
-values are `info` and `warning`. If you find the output too noisy when
-debugging, just choose a less verbose level.
-
-### How can I delete the mock function's argument in an action?
-
-If your mock function takes a pointer argument and you want to delete that
-argument, you can use testing::DeleteArg<N>() to delete the N'th (zero-indexed)
-argument:
-
-```cpp
-using ::testing::_;
- ...
- MOCK_METHOD(void, Bar, (X* x, const Y& y));
- ...
- EXPECT_CALL(mock_foo_, Bar(_, _))
- .WillOnce(testing::DeleteArg<0>()));
-```
-
-### How can I perform an arbitrary action on a mock function's argument?
-
-If you find yourself needing to perform some action that's not supported by
-gMock directly, remember that you can define your own actions using
-[`MakeAction()`](#NewMonoActions) or
-[`MakePolymorphicAction()`](#NewPolyActions), or you can write a stub function
-and invoke it using [`Invoke()`](#FunctionsAsActions).
-
-```cpp
-using ::testing::_;
-using ::testing::Invoke;
- ...
- MOCK_METHOD(void, Bar, (X* p));
- ...
- EXPECT_CALL(mock_foo_, Bar(_))
- .WillOnce(Invoke(MyAction(...)));
-```
-
-### My code calls a static/global function. Can I mock it?
-
-You can, but you need to make some changes.
-
-In general, if you find yourself needing to mock a static function, it's a sign
-that your modules are too tightly coupled (and less flexible, less reusable,
-less testable, etc). You are probably better off defining a small interface and
-call the function through that interface, which then can be easily mocked. It's
-a bit of work initially, but usually pays for itself quickly.
-
-This Google Testing Blog
-[post](https://testing.googleblog.com/2008/06/defeat-static-cling.html) says it
-excellently. Check it out.
-
-### My mock object needs to do complex stuff. It's a lot of pain to specify the actions. gMock sucks!
-
-I know it's not a question, but you get an answer for free any way. :-)
-
-With gMock, you can create mocks in C++ easily. And people might be tempted to
-use them everywhere. Sometimes they work great, and sometimes you may find them,
-well, a pain to use. So, what's wrong in the latter case?
-
-When you write a test without using mocks, you exercise the code and assert that
-it returns the correct value or that the system is in an expected state. This is
-sometimes called "state-based testing".
-
-Mocks are great for what some call "interaction-based" testing: instead of
-checking the system state at the very end, mock objects verify that they are
-invoked the right way and report an error as soon as it arises, giving you a
-handle on the precise context in which the error was triggered. This is often
-more effective and economical to do than state-based testing.
-
-If you are doing state-based testing and using a test double just to simulate
-the real object, you are probably better off using a fake. Using a mock in this
-case causes pain, as it's not a strong point for mocks to perform complex
-actions. If you experience this and think that mocks suck, you are just not
-using the right tool for your problem. Or, you might be trying to solve the
-wrong problem. :-)
-
-### I got a warning "Uninteresting function call encountered - default action taken.." Should I panic?
-
-By all means, NO! It's just an FYI. :-)
-
-What it means is that you have a mock function, you haven't set any expectations
-on it (by gMock's rule this means that you are not interested in calls to this
-function and therefore it can be called any number of times), and it is called.
-That's OK - you didn't say it's not OK to call the function!
-
-What if you actually meant to disallow this function to be called, but forgot to
-write `EXPECT_CALL(foo, Bar()).Times(0)`? While one can argue that it's the
-user's fault, gMock tries to be nice and prints you a note.
-
-So, when you see the message and believe that there shouldn't be any
-uninteresting calls, you should investigate what's going on. To make your life
-easier, gMock dumps the stack trace when an uninteresting call is encountered.
-From that you can figure out which mock function it is, and how it is called.
-
-### I want to define a custom action. Should I use Invoke() or implement the ActionInterface interface?
-
-Either way is fine - you want to choose the one that's more convenient for your
-circumstance.
-
-Usually, if your action is for a particular function type, defining it using
-`Invoke()` should be easier; if your action can be used in functions of
-different types (e.g. if you are defining `Return(*value*)`),
-`MakePolymorphicAction()` is easiest. Sometimes you want precise control on what
-types of functions the action can be used in, and implementing `ActionInterface`
-is the way to go here. See the implementation of `Return()` in
-`testing/base/public/gmock-actions.h` for an example.
-
-### I use SetArgPointee() in WillOnce(), but gcc complains about "conflicting return type specified". What does it mean?
-
-You got this error as gMock has no idea what value it should return when the
-mock method is called. `SetArgPointee()` says what the side effect is, but
-doesn't say what the return value should be. You need `DoAll()` to chain a
-`SetArgPointee()` with a `Return()` that provides a value appropriate to the API
-being mocked.
-
-See this [recipe](cook_book.md#mocking-side-effects) for more details and an
-example.
-
-### I have a huge mock class, and Microsoft Visual C++ runs out of memory when compiling it. What can I do?
-
-We've noticed that when the `/clr` compiler flag is used, Visual C++ uses 5~6
-times as much memory when compiling a mock class. We suggest to avoid `/clr`
-Uninteresting mock function call - returning default value.
- Function call: Bar2(0, 1)
- Returns: false
-NOTE: You can safely ignore the above warning unless this call should not happen. Do not suppress it by blindly adding an EXPECT_CALL() if you don't mean to enforce the call. See https://github.com/google/googletest/blob/master/googlemock/docs/cook_book.md#knowing-when-to-expect for details.
-[ OK ] GMockOutputTest.UninterestingCall
-[ RUN ] GMockOutputTest.UninterestingCallToVoidFunction
-
-GMOCK WARNING:
-Uninteresting mock function call - returning directly.
- Function call: Bar3(0, 1)
-NOTE: You can safely ignore the above warning unless this call should not happen. Do not suppress it by blindly adding an EXPECT_CALL() if you don't mean to enforce the call. See https://github.com/google/googletest/blob/master/googlemock/docs/cook_book.md#knowing-when-to-expect for details.
-[ OK ] GMockOutputTest.UninterestingCallToVoidFunction
-[ RUN ] GMockOutputTest.RetiredExpectation
-unknown file: Failure
-
-Unexpected mock function call - returning default value.
- Function call: Bar2(1, 1)
- Returns: false
-Google Mock tried the following 2 expectations, but none matched:
-[ RUN ] GMockOutputTest.UninterestingCallWithDefaultAction
-
-GMOCK WARNING:
-Uninteresting mock function call - taking default action specified at:
-FILE:#:
- Function call: Bar2(2, 2)
- Returns: true
-NOTE: You can safely ignore the above warning unless this call should not happen. Do not suppress it by blindly adding an EXPECT_CALL() if you don't mean to enforce the call. See https://github.com/google/googletest/blob/master/googlemock/docs/cook_book.md#knowing-when-to-expect for details.
-
-GMOCK WARNING:
-Uninteresting mock function call - taking default action specified at:
-FILE:#:
- Function call: Bar2(1, 1)
- Returns: false
-NOTE: You can safely ignore the above warning unless this call should not happen. Do not suppress it by blindly adding an EXPECT_CALL() if you don't mean to enforce the call. See https://github.com/google/googletest/blob/master/googlemock/docs/cook_book.md#knowing-when-to-expect for details.
-[ OK ] GMockOutputTest.UninterestingCallWithDefaultAction
-[ RUN ] GMockOutputTest.ExplicitActionsRunOutWithDefaultAction
-
-GMOCK WARNING:
-FILE:#: Too few actions specified in EXPECT_CALL(foo_, Bar2(_, _))...
-Expected to be called twice, but has only 1 WillOnce().
-GMOCK WARNING:
-FILE:#: Actions ran out in EXPECT_CALL(foo_, Bar2(_, _))...
-Called 2 times, but only 1 WillOnce() is specified - taking default action specified at:
-FILE:#:
-Stack trace:
-[ OK ] GMockOutputTest.ExplicitActionsRunOutWithDefaultAction
-[ RUN ] GMockOutputTest.CatchesLeakedMocks
-[ OK ] GMockOutputTest.CatchesLeakedMocks
-[ RUN ] GMockOutputTest.PrintsMatcher
-FILE:#: Failure
-Value of: (std::pair<int, bool>(42, true))
-Expected: is pair (is >= 48, true)
- Actual: (42, true) (of type std::pair<int, bool>)
-FILE:#: ERROR: this mock object should be deleted but never is. Its address is @0x#.
-FILE:#: ERROR: this mock object should be deleted but never is. Its address is @0x#.
-FILE:#: ERROR: this mock object should be deleted but never is. Its address is @0x#.
-ERROR: 3 leaked mock objects found at program exit. Expectations on a mock object is verified when the object is destructed. Leaking a mock means that its expectations aren't verified, which is usually a test bug. If you really intend to leak a mock, you can suppress this error using testing::Mock::AllowLeak(mock_object), or you may use a fake or stub instead of a mock.
-| `ASSERT_NEAR(val1, val2, abs_error);` | `EXPECT_NEAR(val1, val2, abs_error);` | the difference between `val1` and `val2` doesn't exceed the given absolute error |
-
-<!-- mdformat on-->
-
-#### Floating-Point Predicate-Format Functions
-
-Some floating-point operations are useful, but not that often used. In order to
-avoid an explosion of new macros, we provide them as predicate-format functions
-that can be used in predicate assertion macros (e.g. `EXPECT_PRED_FORMAT2`,
-`ASSERT_DEATH(statement, matcher);` | `EXPECT_DEATH(statement, matcher);` | `statement` crashes with the given error
-`ASSERT_DEATH_IF_SUPPORTED(statement, matcher);` | `EXPECT_DEATH_IF_SUPPORTED(statement, matcher);` | if death tests are supported, verifies that `statement` crashes with the given error; otherwise verifies nothing
-`ASSERT_EXIT(statement, predicate, matcher);` | `EXPECT_EXIT(statement, predicate, matcher);` | `statement` exits with the given error, and its exit code matches `predicate`
-
-where `statement` is a statement that is expected to cause the process to die,
-`predicate` is a function or function object that evaluates an integer exit
-status, and `matcher` is either a gMock matcher matching a `const std::string&`
-or a (Perl) regular expression - either of which is matched against the stderr
-output of `statement`. For legacy reasons, a bare string (i.e. with no matcher)
-is interpreted as `ContainsRegex(str)`, **not** `Eq(str)`. Note that `statement`
-can be *any valid statement* (including *compound statement*) and doesn't have
-to be an expression.
-
-As usual, the `ASSERT` variants abort the current test function, while the
-`EXPECT` variants do not.
-
-> NOTE: We use the word "crash" here to mean that the process terminates with a
-> *non-zero* exit status code. There are two possibilities: either the process
-> has called `exit()` or `_exit()` with a non-zero value, or it may be killed by
-> a signal.
->
-> This means that if *`statement`* terminates the process with a 0 exit code, it
-> is *not* considered a crash by `EXPECT_DEATH`. Use `EXPECT_EXIT` instead if
-> this is the case, or if you want to restrict the exit code more precisely.
-
-A predicate here must accept an `int` and return a `bool`. The death test
-succeeds only if the predicate returns `true`. googletest defines a few
-predicates that handle the most common cases:
-
-```c++
-::testing::ExitedWithCode(exit_code)
-```
-
-This expression is `true` if the program exited normally with the given exit
-code.
-
-```c++
-::testing::KilledBySignal(signal_number) // Not available on Windows.
-```
-
-This expression is `true` if the program was killed by the given signal.
-
-The `*_DEATH` macros are convenient wrappers for `*_EXIT` that use a predicate
-that verifies the process' exit code is non-zero.
-
-Note that a death test only cares about three things:
-
-1. does `statement` abort or exit the process?
-2. (in the case of `ASSERT_EXIT` and `EXPECT_EXIT`) does the exit status
- satisfy `predicate`? Or (in the case of `ASSERT_DEATH` and `EXPECT_DEATH`)
- is the exit status non-zero? And
-3. does the stderr output match `matcher`?
-
-In particular, if `statement` generates an `ASSERT_*` or `EXPECT_*` failure, it
-will **not** cause the death test to fail, as googletest assertions don't abort
-the process.
-
-To write a death test, simply use one of the above macros inside your test
-`ASSERT_NO_FATAL_FAILURE(statement);` | `EXPECT_NO_FATAL_FAILURE(statement);` | `statement` doesn't generate any new fatal failures in the current thread.
-
-Only failures in the thread that executes the assertion are checked to determine
-the result of this type of assertions. If `statement` creates new threads,
-failures in these threads are ignored.
-
-Examples:
-
-```c++
-ASSERT_NO_FATAL_FAILURE(Foo());
-
-int i;
-EXPECT_NO_FATAL_FAILURE({
- i = Bar();
-});
-```
-
-Assertions from multiple threads are currently not supported on Windows.
-
-#### Checking for Failures in the Current Test
-
-`HasFatalFailure()` in the `::testing::Test` class returns `true` if an
-assertion in the current test has suffered a fatal failure. This allows
-functions to catch fatal failures in a sub-routine and return early.
-
-```c++
-class Test {
- public:
- ...
- static bool HasFatalFailure();
-};
-```
-
-The typical usage, which basically simulates the behavior of a thrown exception,
-is:
-
-```c++
-TEST(FooTest, Bar) {
- Subroutine();
- // Aborts if Subroutine() had a fatal failure.
- if (HasFatalFailure()) return;
-
- // The following won't be executed.
- ...
-}
-```
-
-If `HasFatalFailure()` is used outside of `TEST()` , `TEST_F()` , or a test
-fixture, you must add the `::testing::Test::` prefix, as in:
-
-```c++
-if (::testing::Test::HasFatalFailure()) return;
-```
-
-Similarly, `HasNonfatalFailure()` returns `true` if the current test has at
-least one non-fatal failure, and `HasFailure()` returns `true` if the current
-test has at least one failure of either kind.
-
-## Logging Additional Information
-
-In your test code, you can call `RecordProperty("key", value)` to log additional
-information, where `value` can be either a string or an `int`. The *last* value
-recorded for a key will be emitted to the
-[XML output](#generating-an-xml-report) if you specify one. For example, the
-## Why should test suite names and test names not contain underscore?
-
-Underscore (`_`) is special, as C++ reserves the following to be used by the
-compiler and the standard library:
-
-1. any identifier that starts with an `_` followed by an upper-case letter, and
-2. any identifier that contains two consecutive underscores (i.e. `__`)
- *anywhere* in its name.
-
-User code is *prohibited* from using such identifiers.
-
-Now let's look at what this means for `TEST` and `TEST_F`.
-
-Currently `TEST(TestSuiteName, TestName)` generates a class named
-`TestSuiteName_TestName_Test`. What happens if `TestSuiteName` or `TestName`
-contains `_`?
-
-1. If `TestSuiteName` starts with an `_` followed by an upper-case letter (say,
- `_Foo`), we end up with `_Foo_TestName_Test`, which is reserved and thus
- invalid.
-2. If `TestSuiteName` ends with an `_` (say, `Foo_`), we get
- `Foo__TestName_Test`, which is invalid.
-3. If `TestName` starts with an `_` (say, `_Bar`), we get
- `TestSuiteName__Bar_Test`, which is invalid.
-4. If `TestName` ends with an `_` (say, `Bar_`), we get
- `TestSuiteName_Bar__Test`, which is invalid.
-
-So clearly `TestSuiteName` and `TestName` cannot start or end with `_`
-(Actually, `TestSuiteName` can start with `_` -- as long as the `_` isn't
-followed by an upper-case letter. But that's getting complicated. So for
-simplicity we just say that it cannot start with `_`.).
-
-It may seem fine for `TestSuiteName` and `TestName` to contain `_` in the
-middle. However, consider this:
-
-```c++
-TEST(Time, Flies_Like_An_Arrow) { ... }
-TEST(Time_Flies, Like_An_Arrow) { ... }
-```
-
-Now, the two `TEST`s will both generate the same class
-(`Time_Flies_Like_An_Arrow_Test`). That's not good.
-
-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
-easy to remember. It also gives googletest some wiggle room in case its
-implementation needs to change in the future.
-
-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
-are using) or with a new version of googletest. Therefore it's best to follow
-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)`?
-
-First of all you can use `EXPECT_NE(nullptr, ptr)` and `ASSERT_NE(nullptr,
-ptr)`. This is the preferred syntax in the style guide because nullptr does not
-have the type problems that NULL does. Which is why NULL does not work.
-
-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()`
-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
-error-prone than necessary).
-
-The `EXPECT_EQ()` macro takes the *expected* value as its first argument and the
-*actual* value as the second. It's reasonable that someone wants to write
-`EXPECT_EQ(NULL, some_expression)`, and this indeed was requested several times.
-Therefore we implemented it.
-
-The need for `EXPECT_NE(NULL, ptr)` isn't nearly as strong. When the assertion
-fails, you already know that `ptr` must be `NULL`, so it doesn't add any
-information to print `ptr` in this case. That means `EXPECT_TRUE(ptr != NULL)`
-works just as well.
-
-If we were to support `EXPECT_NE(NULL, ptr)`, for consistency we'll have to
-support `EXPECT_NE(ptr, NULL)` as well, as unlike `EXPECT_EQ`, we don't have a
-convention on the order of the two arguments for `EXPECT_NE`. This means using
-the template meta programming tricks twice in the implementation, making it even
-harder to understand and maintain. We believe the benefit doesn't justify the
-cost.
-
-Finally, with the growth of the gMock matcher library, we are encouraging people
-to use the unified `EXPECT_THAT(value, matcher)` syntax more often in tests. One
-significant advantage of the matcher approach is that matchers can be easily
-combined to form new matchers, while the `EXPECT_NE`, etc, macros cannot be
-easily combined. Therefore we want to invest more in the matchers than in the
-`EXPECT_XX()` macros.
-
-## I need to test that different implementations of an interface satisfy some common requirements. Should I use typed tests or value-parameterized tests?
-
-For testing various implementations of the same interface, either typed tests or
-value-parameterized tests can get it done. It's really up to you the user to
-decide which is more convenient for you, depending on your particular case. Some
-rough guidelines:
-
-* Typed tests can be easier to write if instances of the different
- implementations can be created the same way, modulo the type. For example,
- if all these implementations have a public default constructor (such that
- you can write `new TypeParam`), or if their factory functions have the same
- form (e.g. `CreateInstance<TypeParam>()`).
-* Value-parameterized tests can be easier to write if you need different code
- patterns to create different implementations' instances, e.g. `new Foo` vs
- `new Bar(5)`. To accommodate for the differences, you can write factory
- function wrappers and pass these function pointers to the tests as their
- parameters.
-* When a typed test fails, the default output includes the name of the type,
- which can help you quickly identify which implementation is wrong.
- Value-parameterized tests only show the number of the failed iteration by
- default. You will need to define a function that returns the iteration name
- and pass it as the third parameter to INSTANTIATE_TEST_SUITE_P to have more
- useful output.
-* When using typed tests, you need to make sure you are testing against the
- interface type, not the concrete types (in other words, you want to make
- sure `implicit_cast<MyInterface*>(my_concrete_impl)` works, not just that
- `my_concrete_impl` works). It's less likely to make mistakes in this area
- when using value-parameterized tests.
-
-I hope I didn't confuse you more. :-) If you don't mind, I'd suggest you to give
-both approaches a try. Practice is a much better way to grasp the subtle
-differences between the two tools. Once you have some concrete experience, you
-can much more easily decide which one to use the next time.
-
-## I got some run-time errors about invalid proto descriptors when using `ProtocolMessageEquals`. Help!
-
-**Note:** `ProtocolMessageEquals` and `ProtocolMessageEquiv` are *deprecated*
-now. Please use `EqualsProto`, etc instead.
-
-`ProtocolMessageEquals` and `ProtocolMessageEquiv` were redefined recently and
-are now less tolerant of invalid protocol buffer definitions. In particular, if
-you have a `foo.proto` that doesn't fully qualify the type of a protocol message
-it references (e.g. `message<Bar>` where it should be `message<blah.Bar>`), you
-will now get run-time errors like:
-
-```
-... descriptor.cc:...] Invalid proto descriptor for file "path/to/foo.proto":
-... descriptor.cc:...] blah.MyMessage.my_field: ".Bar" is not defined.
-```
-
-If you see this, your `.proto` file is broken and needs to be fixed by making
-the types fully qualified. The new definition of `ProtocolMessageEquals` and
-`ProtocolMessageEquiv` just happen to reveal your bug.
-
-## My death test modifies some state, but the change seems lost after the death test finishes. Why?
-
-Death tests (`EXPECT_DEATH`, etc) are executed in a sub-process s.t. the
-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
-sub-processes, but not in the parent process. You can think of them as running
-in a parallel universe, more or less.
-
-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,
-you may want to move your `EXPECT_CALL` statements inside the `EXPECT_DEATH`
-macro.
-
-## EXPECT_EQ(htonl(blah), blah_blah) generates weird compiler errors in opt mode. Is this a googletest bug?
-
-Actually, the bug is in `htonl()`.
-
-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
-a *macro*, which breaks this usage.
-
-Worse, the macro definition of `htonl()` uses a `gcc` extension and is *not*
-standard C++. That hacky implementation has some ad hoc limitations. In
-particular, it prevents you from writing `Foo<sizeof(htonl(x))>()`, where `Foo`
-is a template that has an integral argument.
-
-The implementation of `EXPECT_EQ(a, b)` uses `sizeof(... a ...)` inside a
-template argument, and thus doesn't compile in opt mode when `a` contains a call
-to `htonl()`. It is difficult to make `EXPECT_EQ` bypass the `htonl()` bug, as
-the solution must work with different compilers on various platforms.
-
-`htonl()` has some other problems as described in `//util/endian/endian.h`,
-which defines `ghtonl()` to replace it. `ghtonl()` does the same thing `htonl()`
-does, only without its problems. We suggest you to use `ghtonl()` instead of
-`htonl()`, both in your tests and production code.
-
-`//util/endian/endian.h` also defines `ghtons()`, which solves similar problems
-in `htons()`.
-
-Don't forget to add `//util/endian` to the list of dependencies in the `BUILD`
-file wherever `ghtonl()` and `ghtons()` are used. The library consists of a
-single header file and will not bloat your binary.
-
-## The compiler complains about "undefined references" to some static const member variables, but I did define them in the class body. What's wrong?
-
-If your class has a static data member:
-
-```c++
-// foo.h
-class Foo {
- ...
- static const int kBar = 100;
-};
-```
-
-You also need to define it *outside* of the class body in `foo.cc`:
-
-```c++
-const int Foo::kBar; // No initializer here.
-```
-
-Otherwise your code is **invalid C++**, and may break in unexpected ways. In
-particular, using it in googletest comparison assertions (`EXPECT_EQ`, etc) will
-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. :-)
-
-## Can I derive a test fixture from another?
-
-Yes.
-
-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
-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
-important system resources like fonts and brushes.
-
-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
-test suite that wants to use this common logic. You then use `TEST_F()` to write
-tests using each derived fixture.
-
-Typically, your code looks like this:
-
-```c++
-// Defines a base test fixture.
-class BaseTest : public ::testing::Test {
- protected:
- ...
-};
-
-// Derives a fixture FooTest from BaseTest.
-class FooTest : public BaseTest {
- protected:
- void SetUp() override {
- BaseTest::SetUp(); // Sets up the base fixture first.
- ... additional set-up work ...
- }
-
- void TearDown() override {
- ... clean-up work for FooTest ...
- BaseTest::TearDown(); // Remember to tear down the base fixture
- // after cleaning up FooTest!
- }
-
- ... functions and variables for FooTest ...
-};
-
-// Tests that use the fixture FooTest.
-TEST_F(FooTest, Bar) { ... }
-TEST_F(FooTest, Baz) { ... }
-
-... additional fixtures derived from BaseTest ...
-```
-
-If necessary, you can continue to derive test fixtures from a derived fixture.
-googletest has no limit on how deep the hierarchy can be.
-
-For a complete example using derived test fixtures, see
-(The stuff inside the angled brackets for the `static_cast` operator is the type
-of the function pointer for the `int`-version of `IsPositive()`.)
-
-As another example, when you have a template function
-
-```c++
-template <typename T>
-bool IsNegative(T x) {
- return x < 0;
-}
-```
-
-you can use it in a predicate assertion like this:
-
-```c++
-ASSERT_PRED1(IsNegative<int>, -5);
-```
-
-Things are more interesting if your template has more than one parameters. The
-following won't compile:
-
-```c++
-ASSERT_PRED2(GreaterThan<int, int>, 5, 0);
-```
-
-as the C++ pre-processor thinks you are giving `ASSERT_PRED2` 4 arguments, which
-is one more than expected. The workaround is to wrap the predicate function in
-parentheses:
-
-```c++
-ASSERT_PRED2((GreaterThan<int, int>), 5, 0);
-```
-
-## 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,
-instead of
-
-```c++
- return RUN_ALL_TESTS();
-```
-
-they write
-
-```c++
- RUN_ALL_TESTS();
-```
-
-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
-`main()` function ignores it, your test will be considered successful even if it
-has a googletest assertion failure. Very bad.
-
-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
-`gcc`. If you do so, you'll get a compiler error.
-
-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
-return value of `main()`.
-
-But how could we introduce a change that breaks existing tests? Well, in this
-case, the code was already broken in the first place, so we didn't break it. :-)
-
-## My compiler complains that a constructor (or destructor) cannot return a value. What's going on?
-
-Due to a peculiarity of C++, in order to support the syntax for streaming
-messages to an `ASSERT_*`, e.g.
-
-```c++
- ASSERT_EQ(1, Foo()) << "blah blah" << foo;
-```
-
-we had to give up using `ASSERT*` and `FAIL*` (but not `EXPECT*` and
-`ADD_FAILURE*`) in constructors and destructors. The workaround is to move the
-content of your constructor/destructor to a private void member function, or
-switch to `EXPECT_*()` if that works. This
-[section](advanced.md#assertion-placement) in the user's guide explains it.
-
-## My SetUp() function is not called. Why?
-
-C++ is case-sensitive. Did you spell it as `Setup()`?
-
-Similarly, sometimes people spell `SetUpTestSuite()` as `SetupTestSuite()` and
-wonder why it's never called.
-
-
-## 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.
-
-You don't have to. Instead of
-
-```c++
-class FooTest : public BaseTest {};
-
-TEST_F(FooTest, Abc) { ... }
-TEST_F(FooTest, Def) { ... }
-
-class BarTest : public BaseTest {};
-
-TEST_F(BarTest, Abc) { ... }
-TEST_F(BarTest, Def) { ... }
-```
-
-you can simply `typedef` the test fixtures:
-
-```c++
-typedef BaseTest FooTest;
-
-TEST_F(FooTest, Abc) { ... }
-TEST_F(FooTest, Def) { ... }
-
-typedef BaseTest BarTest;
-
-TEST_F(BarTest, Abc) { ... }
-TEST_F(BarTest, Def) { ... }
-```
-
-## 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
-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
-problem.
-
-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
-example:
-
-```shell
-$ ./my_test > gtest_output.txt
-```
-
-## Why should I prefer test fixtures over global variables?
-
-There are several good reasons:
-
-1. It's likely your test needs to change the states of its global variables.
- This makes it difficult to keep side effects from escaping one test and
- contaminating others, making debugging difficult. By using fixtures, each
- test has a fresh set of variables that's different (but with the same
- names). Thus, tests are kept independent of each other.
-2. Global variables pollute the global namespace.
-3. Test fixtures can be reused via subclassing, which cannot be done easily
- with global variables. This is useful if many test suites have something in
- common.
-
-## What can the statement argument in ASSERT_DEATH() be?
-
-`ASSERT_DEATH(statement, matcher)` (or any death assertion macro) can be used
-wherever *`statement`* is valid. So basically *`statement`* can be any C++
-statement that makes sense in the current context. In particular, it can
-reference global and/or local variables, and can be:
-
-* a simple function call (often the case),
-* a complex expression, or
-* a compound statement.
-
-Some examples are shown here:
-
-```c++
-// A death test can be a simple function call.
-TEST(MyDeathTest, FunctionCall) {
- ASSERT_DEATH(Xyz(5), "Xyz failed");
-}
-
-// Or a complex expression that references variables and functions.
-## 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()`
-makes it harder to search for real problems in the parent's log. Therefore,
-googletest only prints them when the death test has failed.
-
-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
-match). Admittedly, this is a hack. We'll consider a more permanent solution
-after the fork-and-exec-style death tests are implemented.
-
-## The compiler complains about "no match for 'operator<<'" when I use an assertion. What gives?
-
-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
-defined such that we can print a value of `FooType`.
-
-In addition, if `FooType` is declared in a name space, the `<<` operator also
-needs to be defined in the *same* name space. See https://abseil.io/tips/49 for details.
-
-## How do I suppress the memory leak messages on Windows?
-
-Since the statically initialized googletest singleton requires allocations on
-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
-`_CrtMemCheckpoint` and `_CrtMemDumpAllObjectsSince` calls to not report any
-statically initialized heap objects. See MSDN for more details and additional
-heap check/debug routines.
-
-## 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
-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
-mistake in production. Such cleverness also leads to
-[Heisenbugs](https://en.wikipedia.org/wiki/Heisenbug). Therefore we strongly
-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
-test is [Dependency Injection](https://en.wikipedia.org/wiki/Dependency_injection). You can inject
-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
-[`testonly`](https://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.
-
-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
-*horrible* hack of sniffing your executable name (`argv[0]` in `main()`) to know
-whether the code is under test.
-
-## How do I temporarily disable a test?
-
-If you have a broken test that you cannot fix right away, you can add the
-DISABLED_ prefix to its name. This will exclude it from execution. This is
-better than commenting out the code or using #if 0, as disabled tests are still
-compiled (and thus won't rot).
-
-To include disabled tests in test execution, just invoke the test program with
-the --gtest_also_run_disabled_tests flag.
-
-## Is it OK if I have two separate `TEST(Foo, Bar)` test methods defined in different namespaces?
-
-Yes.
-
-The rule is **all test methods in the same test suite must use the same fixture
-class.** This means that the following is **allowed** because both tests use the
-same fixture class (`::testing::Test`).
-
-```c++
-namespace foo {
-TEST(CoolTest, DoSomething) {
- SUCCEED();
-}
-} // namespace foo
-
-namespace bar {
-TEST(CoolTest, DoSomething) {
- SUCCEED();
-}
-} // namespace bar
-```
-
-However, the following code is **not allowed** and will produce a runtime error
-from googletest because the test methods are using different test fixture
-classes with the same test suite name.
-
-```c++
-namespace foo {
-class CoolTest : public ::testing::Test {}; // Fixture foo::CoolTest
-TEST_F(CoolTest, DoSomething) {
- SUCCEED();
-}
-} // namespace foo
-
-namespace bar {
-class CoolTest : public ::testing::Test {}; // Fixture: bar::CoolTest
-[0;32m[----------] [m1 test from DynamicFixtureAnotherName
-DynamicFixture::SetUpTestSuite
-[0;32m[ RUN ] [mDynamicFixtureAnotherName.DynamicTestPass
-DynamicFixture()
-DynamicFixture::SetUp
-DynamicFixture::TearDown
-~DynamicFixture()
-[0;32m[ OK ] [mDynamicFixtureAnotherName.DynamicTestPass
-DynamicFixture::TearDownTestSuite
-[0;32m[----------] [m2 tests from BadDynamicFixture1
-DynamicFixture::SetUpTestSuite
-[0;32m[ RUN ] [mBadDynamicFixture1.FixtureBase
-DynamicFixture()
-DynamicFixture::SetUp
-DynamicFixture::TearDown
-~DynamicFixture()
-[0;32m[ OK ] [mBadDynamicFixture1.FixtureBase
-[0;32m[ RUN ] [mBadDynamicFixture1.TestBase
-DynamicFixture()
-gtest.cc:#: Failure
-Failed
-All tests in the same test suite must use the same test fixture
-class, so mixing TEST_F and TEST in the same test suite is
-illegal. In test suite BadDynamicFixture1,
-test FixtureBase is defined using TEST_F but
-test TestBase is defined using TEST. You probably
-want to change the TEST to TEST_F or move it to another test
-case.
-Stack trace: (omitted)
-
-~DynamicFixture()
-[0;31m[ FAILED ] [mBadDynamicFixture1.TestBase
-DynamicFixture::TearDownTestSuite
-[0;32m[----------] [m2 tests from BadDynamicFixture2
-DynamicFixture::SetUpTestSuite
-[0;32m[ RUN ] [mBadDynamicFixture2.FixtureBase
-DynamicFixture()
-DynamicFixture::SetUp
-DynamicFixture::TearDown
-~DynamicFixture()
-[0;32m[ OK ] [mBadDynamicFixture2.FixtureBase
-[0;32m[ RUN ] [mBadDynamicFixture2.Derived
-DynamicFixture()
-gtest.cc:#: Failure
-Failed
-All tests in the same test suite must use the same test fixture
-class. However, in test suite BadDynamicFixture2,
-you defined test FixtureBase and test Derived
-using two different test fixture classes. This can happen if
-the two classes are from different namespaces or translation
-units and have the same name. You should probably rename one
-of the classes to put the tests into different test suites.
-Stack trace: (omitted)
-
-~DynamicFixture()
-[0;31m[ FAILED ] [mBadDynamicFixture2.Derived
-DynamicFixture::TearDownTestSuite
-[0;32m[----------] [m1 test from PrintingFailingParams/FailingParamTest
-[0;32m[ RUN ] [mPrintingFailingParams/FailingParamTest.Fails/0
-googletest-output-test_.cc:#: Failure
-Expected equality of these values:
- 1
- GetParam()
- Which is: 2
-Stack trace: (omitted)
-
-[0;31m[ FAILED ] [mPrintingFailingParams/FailingParamTest.Fails/0, where GetParam() = 2
-[0;32m[----------] [m1 test from EmptyBasenameParamInst
-[0;32m[ RUN ] [mEmptyBasenameParamInst.Passes/0
-[0;32m[ OK ] [mEmptyBasenameParamInst.Passes/0
-[0;32m[----------] [m2 tests from PrintingStrings/ParamTest
-[0;32m[ RUN ] [mPrintingStrings/ParamTest.Success/a
-[0;32m[ OK ] [mPrintingStrings/ParamTest.Success/a
-[0;32m[ RUN ] [mPrintingStrings/ParamTest.Failure/a
-googletest-output-test_.cc:#: Failure
-Expected equality of these values:
- "b"
- GetParam()
- Which is: "a"
-Expected failure
-Stack trace: (omitted)
-
-[0;31m[ FAILED ] [mPrintingStrings/ParamTest.Failure/a, where GetParam() = "a"
-[0;32m[----------] [m2 tests from GoogleTestVerification
-[0;32m[ RUN ] [mGoogleTestVerification.UninstantiatedParamaterizedTestSuite<DetectNotInstantiatedTest>
-Paramaterized test suite DetectNotInstantiatedTest is defined via TEST_P, but never instantiated. None of the test cases will run. Either no INSTANTIATE_TEST_SUITE_P is provided or the only ones provided expand to nothing.
-
-Ideally, TEST_P definitions should only ever be included as part of binaries that intend to use them. (As opposed to, for example, being placed in a library that may be linked in to get other utilities.)
-[0;32m[ OK ] [mGoogleTestVerification.UninstantiatedParamaterizedTestSuite<DetectNotInstantiatedTest>
-[0;32m[ RUN ] [mGoogleTestVerification.UninstantiatedTypeParamaterizedTestSuite<DetectNotInstantiatedTypesTest>
-Type paramaterized test suite DetectNotInstantiatedTypesTest is defined via REGISTER_TYPED_TEST_SUITE_P, but never instantiated via INSTANTIATE_TYPED_TEST_SUITE_P. None of the test cases will run.
-
-Ideally, TYPED_TEST_P definitions should only ever be included as part of binaries that intend to use them. (As opposed to, for example, being placed in a library that may be linked in to get other utilities.)
-[0;32m[ OK ] [mGoogleTestVerification.UninstantiatedTypeParamaterizedTestSuite<DetectNotInstantiatedTypesTest>
-[0;32m[----------] [mGlobal test environment tear-down
-BarEnvironment::TearDown() called.
-googletest-output-test_.cc:#: Failure
-Failed
-Expected non-fatal failure.
-Stack trace: (omitted)
-
-FooEnvironment::TearDown() called.
-googletest-output-test_.cc:#: Failure
-Failed
-Expected fatal failure.
-Stack trace: (omitted)
-
-[0;32m[==========] [m87 tests from 41 test suites ran.
- <failure message="gtest_xml_output_unittest_.cc:*
Expected equality of these values:
 1
 2" type=""><![CDATA[gtest_xml_output_unittest_.cc:*
- <failure message="gtest_xml_output_unittest_.cc:*
Expected equality of these values:
 1
 2" type=""><![CDATA[gtest_xml_output_unittest_.cc:*
-Expected equality of these values:
- 1
- 2%(stack)s]]></failure>
- <failure message="gtest_xml_output_unittest_.cc:*
Expected equality of these values:
 2
 3" type=""><![CDATA[gtest_xml_output_unittest_.cc:*
- "keywords": "unittest, unit, test, gtest, gmock",
- "description": "googletest is a testing framework developed by the Testing Technology team with Google's specific requirements and constraints in mind. No matter whether you work on Linux, Windows, or a Mac, if you write C++ code, googletest can help you. And it supports any kind of tests, not just unit tests.",