3party/googletest
0
0
Fork 0
mirror of https://github.com/google/googletest.git synced 2024-12-26 17:41:03 +08:00
Code Issues Projects Releases Wiki Activity

Googletest export

Browse Source 
Create new Testing API reference

PiperOrigin-RevId: 376969148
This commit is contained in:
Abseil Team 2021-06-01 22:28:29 -04:00 committed by Andy Soffer
parent 5f6a14c846
commit 53495a2a7d
3 changed files with 1460 additions and 48 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
docs/_data/navigation.yml
View File

@ -21,6 +21,8 @@ nav:
url: "/gmock_cheat_sheet.html" url: "/gmock_cheat_sheet.html"
- section: "References" - section: "References"
items: items:
- title: "Testing Reference"
url: "/reference/testing.html"
- title: "Mocking Reference" - title: "Mocking Reference"
url: "/reference/mocking.html" url: "/reference/mocking.html"
- title: "Assertions" - title: "Assertions"

75
docs/advanced.md
View File

@ -1057,26 +1057,15 @@ TEST_P(FooTest, HasBlahBlah) {
} }
``` ```
Finally, you can use `INSTANTIATE_TEST_SUITE_P` to instantiate the test suite Finally, you can use the `INSTANTIATE_TEST_SUITE_P` macro to instantiate the
with any set of parameters you want. googletest defines a number of functions test suite with any set of parameters you want. GoogleTest defines a number of
for generating test parameters. They return what we call (surprise!) *parameter functions for generating test parameters—see details at
generators*. Here is a summary of them, which are all in the `testing` [`INSTANTIATE_TEST_SUITE_P`](reference/testing.md#INSTANTIATE_TEST_SUITE_P) in
namespace: the Testing Reference.
For example, the following statement will instantiate tests from the `FooTest`
| Parameter Generator | Behavior | test suite each with parameter values `"meeny"`, `"miny"`, and `"moe"` using the
| ----------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------- | [`Values`](reference/testing.md#param-generators) parameter generator:
| `Range(begin, end [, step])` | Yields values `{begin, begin+step, begin+step+step, ...}`. The values do not include `end`. `step` defaults to 1. |
| `Values(v1, v2, ..., vN)` | Yields values `{v1, v2, ..., vN}`. |
| `ValuesIn(container)` and `ValuesIn(begin,end)` | Yields values from a C-style array, an STL-style container, or an iterator range `[begin, end)` |
| `Bool()` | Yields sequence `{false, true}`. |
| `Combine(g1, g2, ..., gN)` | Yields all combinations (Cartesian product) as std\:\:tuples of the values generated by the `N` generators. |
For more details, see the comments at the definitions of these functions.
The following statement will instantiate tests from the `FooTest` test suite
each with parameter values `"meeny"`, `"miny"`, and `"moe"`.
```c++ ```c++
INSTANTIATE_TEST_SUITE_P(MeenyMinyMoe, INSTANTIATE_TEST_SUITE_P(MeenyMinyMoe,
@ -1090,7 +1079,8 @@ function scope.
The first argument to `INSTANTIATE_TEST_SUITE_P` is a unique name for the The first argument to `INSTANTIATE_TEST_SUITE_P` is a unique name for the
instantiation of the test suite. The next argument is the name of the test instantiation of the test suite. The next argument is the name of the test
pattern, and the last is the parameter generator. pattern, and the last is the
[parameter generator](reference/testing.md#param-generators).
You can instantiate a test pattern more than once, so to distinguish different You can instantiate a test pattern more than once, so to distinguish different
instances of the pattern, the instantiation name is added as a prefix to the instances of the pattern, the instantiation name is added as a prefix to the
@ -1107,7 +1097,8 @@ instantiations. The tests from the instantiation above will have these names:
You can use these names in [`--gtest_filter`](#running-a-subset-of-the-tests). You can use these names in [`--gtest_filter`](#running-a-subset-of-the-tests).
The following statement will instantiate all tests from `FooTest` again, each The following statement will instantiate all tests from `FooTest` again, each
with parameter values `"cat"` and `"dog"`: with parameter values `"cat"` and `"dog"` using the
[`ValuesIn`](reference/testing.md#param-generators) parameter generator:
```c++ ```c++
const char* pets[] = {"cat", "dog"}; const char* pets[] = {"cat", "dog"};
@ -1605,27 +1596,12 @@ int main(int argc, char** argv) {
Sometimes a function may need to know the name of the currently running test. Sometimes a function may need to know the name of the currently running test.
For example, you may be using the `SetUp()` method of your test fixture to set For example, you may be using the `SetUp()` method of your test fixture to set
the golden file name based on which test is running. The `::testing::TestInfo` the golden file name based on which test is running. The
class has this information: [`TestInfo`](reference/testing.md#TestInfo) class has this information.
```c++
namespace testing {
class TestInfo {
public:
// Returns the test suite name and the test name, respectively.
//
// Do NOT delete or free the return value - it's managed by the
// TestInfo class.
const char* test_suite_name() const;
const char* name() const;
};
}
```
To obtain a `TestInfo` object for the currently running test, call To obtain a `TestInfo` object for the currently running test, call
`current_test_info()` on the `UnitTest` singleton object: `current_test_info()` on the [`UnitTest`](reference/testing.md#UnitTest)
singleton object:
```c++ ```c++
// Gets information about the currently running test. // Gets information about the currently running test.
@ -1655,12 +1631,14 @@ checkpoints to implement a resource leak checker, for example.
### Defining Event Listeners ### Defining Event Listeners
To define a event listener, you subclass either testing::TestEventListener or To define a event listener, you subclass either
testing::EmptyTestEventListener The former is an (abstract) interface, where [`testing::TestEventListener`](reference/testing.md#TestEventListener) or
*each pure virtual method can be overridden to handle a test event* (For [`testing::EmptyTestEventListener`](reference/testing.md#EmptyTestEventListener)
example, when a test starts, the `OnTestStart()` method will be called.). The The former is an (abstract) interface, where *each pure virtual method can be
latter provides an empty implementation of all methods in the interface, such overridden to handle a test event* (For example, when a test starts, the
that a subclass only needs to override the methods it cares about. `OnTestStart()` method will be called.). The latter provides an empty
implementation of all methods in the interface, such that a subclass only needs
to override the methods it cares about.
When an event is fired, its context is passed to the handler function as an When an event is fired, its context is passed to the handler function as an
argument. The following argument types are used: argument. The following argument types are used:
@ -1704,8 +1682,9 @@ Here's an example:
### Using Event Listeners ### Using Event Listeners
To use the event listener you have defined, add an instance of it to the To use the event listener you have defined, add an instance of it to the
googletest event listener list (represented by class TestEventListeners - note googletest event listener list (represented by class
the "s" at the end of the name) in your `main()` function, before calling [`TestEventListeners`](reference/testing.md#TestEventListeners) - note the "s"
at the end of the name) in your `main()` function, before calling
`RUN_ALL_TESTS()`: `RUN_ALL_TESTS()`:
```c++ ```c++

1431
docs/reference/testing.md Normal file
View File

File diff suppressed because it is too large Load Diff