Merge pull request #2356 from kuzkry:typos
PiperOrigin-RevId: 260786935
diff --git a/.travis.yml b/.travis.yml
index db199c8..6b4c5c7 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -12,9 +12,9 @@
include:
- os: linux
sudo: required
- before_install: chmod -R +x ./ci/*platformio.sh
+ before_install: chmod -R +x ./ci/*platformio.sh
install: ./ci/install-platformio.sh
- script: ./ci/build-platformio.sh
+ script: ./ci/build-platformio.sh
- os: linux
dist: xenial
compiler: gcc
@@ -29,7 +29,7 @@
script: ./ci/build-linux-bazel.sh
- os: linux
compiler: gcc
- env: BUILD_TYPE=Debug VERBOSE=1 CXX_FLAGS=-std=c++11
+ env: BUILD_TYPE=Debug VERBOSE=1 CXX_FLAGS=-std=c++11
- os: linux
compiler: clang
env: BUILD_TYPE=Release VERBOSE=1 CXX_FLAGS=-std=c++11 -Wgnu-zero-variadic-macro-arguments
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index c6e656e..e8f77c9 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -29,19 +29,19 @@
1. Submit an issue describing your proposed change to the
[issue tracker](https://github.com/google/googletest).
-1. Please don't mix more than one logical change per submittal, because it
+2. Please don't mix more than one logical change per submittal, because it
makes the history hard to follow. If you want to make a change that doesn't
have a corresponding issue in the issue tracker, please create one.
-1. Also, coordinate with team members that are listed on the issue in question.
+3. Also, coordinate with team members that are listed on the issue in question.
This ensures that work isn't being duplicated and communicating your plan
early also generally leads to better patches.
-1. If your proposed change is accepted, and you haven't already done so, sign a
+4. If your proposed change is accepted, and you haven't already done so, sign a
Contributor License Agreement (see details above).
-1. Fork the desired repo, develop and test your code changes.
-1. Ensure that your code adheres to the existing style in the sample to which
+5. Fork the desired repo, develop and test your code changes.
+6. Ensure that your code adheres to the existing style in the sample to which
you are contributing.
-1. Ensure that your code has an appropriate set of unit tests which all pass.
-1. Submit a pull request.
+7. Ensure that your code has an appropriate set of unit tests which all pass.
+8. Submit a pull request.
## The Google Test and Google Mock Communities
@@ -131,7 +131,7 @@
You don't need to worry about regenerating the source files unless you need to
modify them. You would then modify the corresponding `.pump` files and run the
'[pump.py](googletest/scripts/pump.py)' generator script. See the
-[Pump Manual](googletest/g3doc/PumpManual.md).
+[Pump Manual](googletest/docs/PumpManual.md).
## Developing Google Mock
diff --git a/README.md b/README.md
index 3cd8396..5b417fa 100644
--- a/README.md
+++ b/README.md
@@ -5,11 +5,6 @@
[](https://travis-ci.org/google/googletest)
[](https://ci.appveyor.com/project/GoogleTestAppVeyor/googletest/branch/master)
-### Summer Vacation
-
-June 26, 2019 - July 20 2019 due to summer vacations there will be much reduced
-activity on Pull Requests and issues from the maintainers.
-
### Future Plans
#### 1.8.x Release:
diff --git a/googlemock/CMakeLists.txt b/googlemock/CMakeLists.txt
index c204f27..f75ec45 100644
--- a/googlemock/CMakeLists.txt
+++ b/googlemock/CMakeLists.txt
@@ -142,7 +142,7 @@
"$project_bin = \"${CMAKE_BINARY_DIR}/bin/$<CONFIG>\"
$env:Path = \"$project_bin;$env:Path\"
& $args")
- elseif (MINGW)
+ elseif (MINGW OR CYGWIN)
file(GENERATE OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/RunTest.ps1"
CONTENT
"$project_bin = (cygpath --windows ${CMAKE_BINARY_DIR}/bin)
@@ -162,7 +162,7 @@
cxx_test(gmock-generated-matchers_test gmock_main)
cxx_test(gmock-internal-utils_test gmock_main)
cxx_test(gmock-matchers_test gmock_main)
- if (MINGW)
+ if (MINGW OR CYGWIN)
target_compile_options(gmock-matchers_test PRIVATE "-Wa,-mbig-obj")
endif()
cxx_test(gmock-more-actions_test gmock_main)
diff --git a/googlemock/docs/cheat_sheet.md b/googlemock/docs/cheat_sheet.md
index d0b68ce..540da39 100644
--- a/googlemock/docs/cheat_sheet.md
+++ b/googlemock/docs/cheat_sheet.md
@@ -2,6 +2,8 @@
<!-- GOOGLETEST_CM0019 DO NOT DELETE -->
+<!-- GOOGLETEST_CM0033 DO NOT DELETE -->
+
### Defining a Mock Class
#### Mocking a Normal Class {#MockClass}
@@ -232,7 +234,7 @@
Built-in matchers (where `argument` is the function argument) are divided into
several categories:
-## Wildcard
+#### Wildcard
Matcher | Description
:-------------------------- | :-----------------------------------------------
@@ -495,6 +497,10 @@
| `WhenDynamicCastTo<T>(m)` | when `argument` is passed through |
: : `dynamic_cast<T>()`, it matches matcher `m`. :
+<!-- GOOGLETEST_CM0026 DO NOT DELETE -->
+
+<!-- GOOGLETEST_CM0027 DO NOT DELETE -->
+
#### Multi-argument Matchers {#MultiArgMatchers}
Technically, all matchers match a *single* value. A "multi-argument" matcher is
@@ -525,13 +531,25 @@
You can make a matcher from one or more other matchers:
-| Matcher | Description |
-| :----------------------- | :---------------------------------------------- |
-| `AllOf(m1, m2, ..., mn)` | `argument` matches all of the matchers `m1` to |
-: : `mn`. :
-| `AnyOf(m1, m2, ..., mn)` | `argument` matches at least one of the matchers |
-: : `m1` to `mn`. :
-| `Not(m)` | `argument` doesn't match matcher `m`. |
+| Matcher | Description |
+| :------------------------------- | :-------------------------------------- |
+| `AllOf(m1, m2, ..., mn)` | `argument` matches all of the matchers |
+: : `m1` to `mn`. :
+| `AllOfArray({m0, m1, ..., mn})`, | The same as `AllOf()` except that the |
+: `AllOfArray(a_container)`, : matchers come from an initializer list, :
+: `AllOfArray(begin, end)`, : STL-style container, iterator range, or :
+: `AllOfArray(array)`, or : C-style array. :
+: `AllOfArray(array, count)` : :
+| `AnyOf(m1, m2, ..., mn)` | `argument` matches at least one of the |
+: : matchers `m1` to `mn`. :
+| `AnyOfArray({m0, m1, ..., mn})`, | The same as `AnyOf()` except that the |
+: `AnyOfArray(a_container)`, : matchers come from an initializer list, :
+: `AnyOfArray(begin, end)`, : STL-style container, iterator range, or :
+: `AnyOfArray(array)`, or : C-style array. :
+: `AnyOfArray(array, count)` : :
+| `Not(m)` | `argument` doesn't match matcher `m`. |
+
+<!-- GOOGLETEST_CM0028 DO NOT DELETE -->
#### Adapters for Matchers
@@ -550,7 +568,7 @@
`AddressSatisfies(callback)` and `Truly(callback)` take ownership of `callback`,
which must be a permanent callback.
-#### Matchers as Predicates {#MatchersAsPredicatesCheat}
+#### Using Matchers as Predicates {#MatchersAsPredicatesCheat}
| Matcher | Description |
| :---------------------------- | :------------------------------------------ |
@@ -581,26 +599,19 @@
**Notes:**
1. The `MATCHER*` macros cannot be used inside a function or class.
-1. The matcher body must be *purely functional* (i.e. it cannot have any side
+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).
-1. You can use `PrintToString(x)` to convert a value `x` of any type to a
+3. You can use `PrintToString(x)` to convert a value `x` of any type to a
string.
-## Matchers as Test Assertions
-
-Matcher | Description
-:--------------------------- | :----------
-`ASSERT_THAT(expression, m)` | Generates a [fatal failure](../../googletest/docs/primer.md#assertions) if the value of `expression` doesn't match matcher `m`.
-`EXPECT_THAT(expression, m)` | Generates a non-fatal failure if the value of `expression` doesn't match matcher `m`.
-
### Actions {#ActionList}
**Actions** specify what a mock function should do when invoked.
#### Returning a Value
-| Matcher | Description |
+| | |
| :-------------------------- | :-------------------------------------------- |
| `Return()` | Return from a `void` mock function. |
| `Return(value)` | Return `value`. If the type of `value` is |
@@ -619,7 +630,7 @@
#### Side Effects
-| Matcher | Description |
+| | |
| :--------------------------------- | :-------------------------------------- |
| `Assign(&variable, value)` | Assign `value` to variable. |
| `DeleteArg<N>()` | Delete the `N`-th (0-based) argument, |
@@ -652,8 +663,11 @@
In the following, by "callable" we mean a free function, `std::function`,
functor, lambda, or `google3`-style permanent callback.
-| Matcher | Description |
+| | |
| :---------------------------------- | :------------------------------------- |
+| `f` | Invoke f with the arguments passed to |
+: : the mock function, where f is a :
+: : callable (except of google3 callback). :
| `Invoke(f)` | Invoke `f` with the arguments passed |
: : to the mock function, where `f` can be :
: : a global/static function or a functor. :
@@ -708,7 +722,7 @@
calls the mock function's #2 argument, passing to it `5` and `string("Hi")` by
value, and `foo` by reference.
-## Default Action
+#### Default Action
| Matcher | Description |
| :------------ | :----------------------------------------------------- |
@@ -718,9 +732,11 @@
**Note:** due to technical reasons, `DoDefault()` cannot be used inside a
composite action - trying to do so will result in a run-time error.
-## Composite Actions
+<!-- GOOGLETEST_CM0032 DO NOT DELETE -->
-| Matcher | Description |
+#### Composite Actions
+
+| | |
| :----------------------------- | :------------------------------------------ |
| `DoAll(a1, a2, ..., an)` | Do all actions `a1` to `an` and return the |
: : result of `an` in each invocation. The :
@@ -734,9 +750,22 @@
: : it. :
| `WithoutArgs(a)` | Perform action `a` without any arguments. |
-## Defining Actions
+#### Defining Actions
-| Matcher | Description |
+<table border="1" cellspacing="0" cellpadding="1">
+ <tr>
+ <td>`struct SumAction {` <br>
+  `template <typename T>` <br>
+  `T operator()(T x, Ty) { return x + y; }` <br>
+ `};`
+ </td>
+ <td> Defines a generic functor that can be used as an action summing its
+ arguments. </td> </tr>
+ <tr>
+ </tr>
+</table>
+
+| | |
| :--------------------------------- | :-------------------------------------- |
| `ACTION(Sum) { return arg0 + arg1; | Defines an action `Sum()` to return the |
: }` : sum of the mock function's argument #0 :
@@ -755,7 +784,7 @@
These are used in `Times()` to specify how many times a mock function will be
called:
-| Matcher | Description |
+| | |
| :---------------- | :----------------------------------------------------- |
| `AnyNumber()` | The function can be called any number of times. |
| `AtLeast(n)` | The call is expected at least `n` times. |
diff --git a/googlemock/docs/cook_book.md b/googlemock/docs/cook_book.md
index ef831a7..676560b 100644
--- a/googlemock/docs/cook_book.md
+++ b/googlemock/docs/cook_book.md
@@ -1,4 +1,4 @@
-## Googletest Mocking (gMock) Cookbook
+## gMock Cookbook
<!-- GOOGLETEST_CM0012 DO NOT DELETE -->
@@ -824,6 +824,7 @@
```cpp
EXPECT_CALL(foo, DoThat(_, NotNull()));
```
+<!-- GOOGLETEST_CM0022 DO NOT DELETE -->
#### Combining Matchers {#CombiningMatchers}
@@ -1138,6 +1139,8 @@
works as long as the return value can be used as the condition in in statement
`if (condition) ...`.
+<!-- GOOGLETEST_CM0023 DO NOT DELETE -->
+
#### Matching Arguments that Are Not Copyable
When you do an `EXPECT_CALL(mock_obj, Foo(bar))`, gMock saves away a copy of
@@ -2147,7 +2150,11 @@
#### Using Functions/Methods/Functors/Lambdas as Actions {#FunctionsAsActions}
If the built-in actions don't suit you, you can use an existing callable
-(function, `std::function`, method, functor, lambda as an action. ```cpp
+(function, `std::function`, method, functor, lambda as an action.
+
+<!-- GOOGLETEST_CM0024 DO NOT DELETE -->
+
+```cpp
using ::testing::_; using ::testing::Invoke;
class MockFoo : public Foo {
@@ -3239,6 +3246,8 @@
combine `--gmock_verbose=info` with `--gtest_stack_trace_depth=0` on the test
command line.
+<!-- GOOGLETEST_CM0025 DO NOT DELETE -->
+
#### Running Tests in Emacs
If you build and run your tests in Emacs using the `M-x google-compile` command
@@ -4175,3 +4184,61 @@
[googletest's advanced guide](../../googletest/docs/advanced.md#teaching-googletest-how-to-print-your-values)
explains how to extend the printer to do a better job at printing your
particular type than to dump the bytes.
+
+### Useful Mocks Created Using gMock
+
+<!--#include file="includes/g3_testing_LOGs.md"-->
+<!--#include file="includes/g3_mock_callbacks.md"-->
+
+#### Mock std::function {#MockFunction}
+
+`std::function` is a general function type introduced in C++11. It is a
+preferred way of passing callbacks to new interfaces. Functions are copiable,
+and are not usually passed around by pointer, which makes them tricky to mock.
+But fear not - `MockFunction` can help you with that.
+
+`MockFunction<R(T1, ..., Tn)>` has a mock method `Call()` with the signature:
+
+```cpp
+ R Call(T1, ..., Tn);
+```
+
+It also has a `AsStdFunction()` method, which creates a `std::function` proxy
+forwarding to Call:
+
+```cpp
+ std::function<R(T1, ..., Tn)> AsStdFunction();
+```
+
+To use `MockFunction`, first create `MockFunction` object and set up
+expectations on its `Call` method. Then pass proxy obtained from
+`AsStdFunction()` to the code you are testing. For example:
+
+```cpp
+TEST(FooTest, RunsCallbackWithBarArgument) {
+ // 1. Create a mock object.
+ MockFunction<int(string)> mock_function;
+
+ // 2. Set expectations on Call() method.
+ EXPECT_CALL(mock_function, Call("bar")).WillOnce(Return(1));
+
+ // 3. Exercise code that uses std::function.
+ Foo(mock_function.AsStdFunction());
+ // Foo's signature can be either of:
+ // void Foo(const std::function<int(string)>& fun);
+ // void Foo(std::function<int(string)> fun);
+
+ // 4. All expectations will be verified when mock_function
+ // goes out of scope and is destroyed.
+}
+```
+
+Remember that function objects created with `AsStdFunction()` are just
+forwarders. If you create multiple of them, they will share the same set of
+expectations.
+
+Although `std::function` supports unlimited number of arguments, `MockFunction`
+implementation is limited to ten. If you ever hit that limit... well, your
+callback has bigger problems than being mockable. :-)
+
+<!-- GOOGLETEST_CM0034 DO NOT DELETE -->
diff --git a/googlemock/docs/for_dummies.md b/googlemock/docs/for_dummies.md
index 5433e8b..5551cd8 100644
--- a/googlemock/docs/for_dummies.md
+++ b/googlemock/docs/for_dummies.md
@@ -1,4 +1,4 @@
-## Googletest Mocking (gMock) for Dummies {#GMockForDummies}
+## gMock for Dummies {#GMockForDummies}
<!-- GOOGLETEST_CM0013 DO NOT DELETE -->
@@ -206,6 +206,8 @@
readable (a net win in the long run), as you can choose `FooAdaptor` to fit your
specific domain much better than `Foo` does.
+<!-- GOOGLETEST_CM0029 DO NOT DELETE -->
+
### Using Mocks in Tests
Once you have a mock class, using it is easy. The typical work flow is:
@@ -593,8 +595,8 @@
order as written. If a call is made out-of-order, it will be an error.
(What if you care about the relative order of some of the calls, but not all of
-them? Can you specify an arbitrary partial order? The answer is ... yes! If you
-are impatient, the details can be found [here](#PartialOrder).)
+them? Can you specify an arbitrary partial order? The answer is ... yes! The
+details can be found [here](cook_book.md#OrderedCalls).)
#### All Expectations Are Sticky (Unless Said Otherwise) {#StickyExpectations}
diff --git a/googlemock/docs/gmock_faq.md b/googlemock/docs/gmock_faq.md
index 184c501..8bc45b1 100644
--- a/googlemock/docs/gmock_faq.md
+++ b/googlemock/docs/gmock_faq.md
@@ -81,6 +81,8 @@
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
@@ -124,6 +126,8 @@
.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
diff --git a/googletest/CMakeLists.txt b/googletest/CMakeLists.txt
index 52a615d..db29294 100644
--- a/googletest/CMakeLists.txt
+++ b/googletest/CMakeLists.txt
@@ -188,7 +188,7 @@
"$project_bin = \"${CMAKE_BINARY_DIR}/bin/$<CONFIG>\"
$env:Path = \"$project_bin;$env:Path\"
& $args")
- elseif (MINGW)
+ elseif (MINGW OR CYGWIN)
file(GENERATE OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/RunTest.ps1"
CONTENT
"$project_bin = (cygpath --windows ${CMAKE_BINARY_DIR}/bin)
diff --git a/googletest/docs/advanced.md b/googletest/docs/advanced.md
index ac7e689..f8624c0 100644
--- a/googletest/docs/advanced.md
+++ b/googletest/docs/advanced.md
@@ -1150,9 +1150,9 @@
1. In your test fixture class (say `FooTest` ), declare as `static` some member
variables to hold the shared resources.
-1. Outside your test fixture class (typically just below it), define those
+2. Outside your test fixture class (typically just below it), define those
member variables, optionally giving them initial values.
-1. In the same test fixture class, define a `static void SetUpTestSuite()`
+3. In the same test fixture class, define a `static void SetUpTestSuite()`
function (remember not to spell it as **`SetupTestSuite`** with a small
`u`!) to set up the shared resources and a `static void TearDownTestSuite()`
function to tear them down.
@@ -1222,15 +1222,15 @@
environment, which knows how to set-up and tear-down:
```c++
-class Environment {
+class Environment : public ::testing::Environment {
public:
virtual ~Environment() {}
// Override this to define how to set up the environment.
- virtual void SetUp() {}
+ void SetUp() override {}
// Override this to define how to tear down the environment.
- virtual void TearDown() {}
+ void TearDown() override {}
};
```
@@ -1425,7 +1425,7 @@
1. Put the definition of the parameterized test fixture class (e.g. `FooTest`)
in a header file, say `foo_param_test.h`. Think of this as *declaring* your
abstract tests.
-1. Put the `TEST_P` definitions in `foo_param_test.cc`, which includes
+2. Put the `TEST_P` definitions in `foo_param_test.cc`, which includes
`foo_param_test.h`. Think of this as *implementing* your abstract tests.
Once they are defined, you can instantiate them by including `foo_param_test.h`,
@@ -1786,10 +1786,10 @@
1. You cannot stream a failure message to either macro.
-1. `statement` in `EXPECT_FATAL_FAILURE{_ON_ALL_THREADS}()` cannot reference
+2. `statement` in `EXPECT_FATAL_FAILURE{_ON_ALL_THREADS}()` cannot reference
local non-static variables or non-static members of `this` object.
-1. `statement` in `EXPECT_FATAL_FAILURE{_ON_ALL_THREADS}()` cannot return a
+3. `statement` in `EXPECT_FATAL_FAILURE{_ON_ALL_THREADS}()` cannot return a
value.
## Registering tests programmatically
@@ -2015,7 +2015,7 @@
1. You cannot generate any failure in `OnTestPartResult()` (otherwise it will
cause `OnTestPartResult()` to be called recursively).
-1. A listener that handles `OnTestPartResult()` is not allowed to generate any
+2. A listener that handles `OnTestPartResult()` is not allowed to generate any
failure.
When you add listeners to the listener list, you should put listeners that
diff --git a/googletest/docs/faq.md b/googletest/docs/faq.md
index 0e9cfee..d6e7f54 100644
--- a/googletest/docs/faq.md
+++ b/googletest/docs/faq.md
@@ -8,7 +8,7 @@
compiler and the standard library:
1. any identifier that starts with an `_` followed by an upper-case letter, and
-1. any identifier that contains two consecutive underscores (i.e. `__`)
+2. any identifier that contains two consecutive underscores (i.e. `__`)
*anywhere* in its name.
User code is *prohibited* from using such identifiers.
@@ -22,11 +22,11 @@
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.
-1. If `TestSuiteName` ends with an `_` (say, `Foo_`), we get
+2. If `TestSuiteName` ends with an `_` (say, `Foo_`), we get
`Foo__TestName_Test`, which is invalid.
-1. If `TestName` starts with an `_` (say, `_Bar`), we get
+3. If `TestName` starts with an `_` (say, `_Bar`), we get
`TestSuiteName__Bar_Test`, which is invalid.
-1. If `TestName` ends with an `_` (say, `Bar_`), we get
+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 `_`
@@ -524,8 +524,8 @@
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.
-1. Global variables pollute the global namespace.
-1. Test fixtures can be reused via subclassing, which cannot be done easily
+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.
diff --git a/googletest/docs/primer.md b/googletest/docs/primer.md
index 388df3b..2759820 100644
--- a/googletest/docs/primer.md
+++ b/googletest/docs/primer.md
@@ -15,26 +15,26 @@
that succeeds or fails as a result of other tests. googletest isolates the
tests by running each of them on a different object. When a test fails,
googletest allows you to run it in isolation for quick debugging.
-1. Tests should be well *organized* and reflect the structure of the tested
+2. Tests should be well *organized* and reflect the structure of the tested
code. googletest groups related tests into test suites that can share data
and subroutines. This common pattern is easy to recognize and makes tests
easy to maintain. Such consistency is especially helpful when people switch
projects and start to work on a new code base.
-1. Tests should be *portable* and *reusable*. Google has a lot of code that is
+3. Tests should be *portable* and *reusable*. Google has a lot of code that is
platform-neutral, its tests should also be platform-neutral. googletest
works on different OSes, with different compilers, with or without
exceptions, so googletest tests can work with a variety of configurations.
-1. When tests fail, they should provide as much *information* about the problem
+4. When tests fail, they should provide as much *information* about the problem
as possible. googletest doesn't stop at the first test failure. Instead, it
only stops the current test and continues with the next. You can also set up
tests that report non-fatal failures after which the current test continues.
Thus, you can detect and fix multiple bugs in a single run-edit-compile
cycle.
-1. The testing framework should liberate test writers from housekeeping chores
+5. The testing framework should liberate test writers from housekeeping chores
and let them focus on the test *content*. googletest automatically keeps
track of all tests defined, and doesn't require the user to enumerate them
in order to run them.
-1. Tests should be *fast*. With googletest, you can reuse shared resources
+6. Tests should be *fast*. With googletest, you can reuse shared resources
across tests and pay for the set-up/tear-down only once, without making
tests depend on each other.
@@ -193,7 +193,7 @@
When doing pointer comparisons use `*_EQ(ptr, nullptr)` and `*_NE(ptr, nullptr)`
instead of `*_EQ(ptr, NULL)` and `*_NE(ptr, NULL)`. This is because `nullptr` is
-typed while `NULL` is not. See [FAQ](faq.md)for more details.
+typed while `NULL` is not. See [FAQ](faq.md) for more details.
If you're working with floating point numbers, you may want to use the floating
point variations of some of these macros in order to avoid problems caused by
@@ -245,9 +245,9 @@
1. Use the `TEST()` macro to define and name a test function, These are
ordinary C++ functions that don't return a value.
-1. In this function, along with any valid C++ statements you want to include,
+2. In this function, along with any valid C++ statements you want to include,
use the various googletest assertions to check values.
-1. The test's result is determined by the assertions; if any assertion in the
+3. The test's result is determined by the assertions; if any assertion in the
test fails (either fatally or non-fatally), or if the test crashes, the
entire test fails. Otherwise, it succeeds.
@@ -309,16 +309,16 @@
1. Derive a class from `::testing::Test` . Start its body with `protected:` as
we'll want to access fixture members from sub-classes.
-1. Inside the class, declare any objects you plan to use.
-1. If necessary, write a default constructor or `SetUp()` function to prepare
+2. Inside the class, declare any objects you plan to use.
+3. If necessary, write a default constructor or `SetUp()` function to prepare
the objects for each test. A common mistake is to spell `SetUp()` as
**`Setup()`** with a small `u` - Use `override` in C++11 to make sure you
spelled it correctly
-1. If necessary, write a destructor or `TearDown()` function to release any
+4. If necessary, write a destructor or `TearDown()` function to release any
resources you allocated in `SetUp()` . To learn when you should use the
constructor/destructor and when you should use `SetUp()/TearDown()`, read
the [FAQ](faq.md).
-1. If needed, define subroutines for your tests to share.
+5. If needed, define subroutines for your tests to share.
When using a fixture, use `TEST_F()` instead of `TEST()` as it allows you to
access objects and subroutines in the test fixture:
@@ -422,11 +422,11 @@
When these tests run, the following happens:
1. googletest constructs a `QueueTest` object (let's call it `t1` ).
-1. `t1.SetUp()` initializes `t1` .
-1. The first test ( `IsEmptyInitially` ) runs on `t1` .
-1. `t1.TearDown()` cleans up after the test finishes.
-1. `t1` is destructed.
-1. The above steps are repeated on another `QueueTest` object, this time
+2. `t1.SetUp()` initializes `t1` .
+3. The first test ( `IsEmptyInitially` ) runs on `t1` .
+4. `t1.TearDown()` cleans up after the test finishes.
+5. `t1` is destructed.
+6. The above steps are repeated on another `QueueTest` object, this time
running the `DequeueWorks` test.
**Availability**: Linux, Windows, Mac.
@@ -456,7 +456,7 @@
* Deletes the fixture.
-* Restores the state of all all googletest flags
+* Restores the state of all googletest flags
* Repeats the above steps for the next test, until all tests have run.
