generic-library/googletest
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Googletest export

Browse Source 
Format documentation

PiperOrigin-RevId: 388592443
This commit is contained in:
Abseil Team 2021-08-03 21:37:57 -04:00 committed by Andy Soffer
parent 652ec31f9f
commit 5b40153003
3 changed files with 25 additions and 30 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

36
docs/advanced.md
View File

@ -202,10 +202,9 @@ You can call the function
to assert that types `T1` and `T2` are the same. The function does nothing if to assert that types `T1` and `T2` are the same. The function does nothing if
the assertion is satisfied. If the types are different, the function call will the assertion is satisfied. If the types are different, the function call will
fail to compile, the compiler error message will say that fail to compile, the compiler error message will say that `T1 and T2 are not the
`T1 and T2 are not the same type` and most likely (depending on the compiler) same type` and most likely (depending on the compiler) show you the actual
show you the actual values of `T1` and `T2`. This is mainly useful inside values of `T1` and `T2`. This is mainly useful inside template code.
template code.
**Caveat**: When used inside a member function of a class template or a function **Caveat**: When used inside a member function of a class template or a function
template, `StaticAssertTypeEq<T1, T2>()` is effective only if the function is template, `StaticAssertTypeEq<T1, T2>()` is effective only if the function is
@ -610,15 +609,14 @@ Despite the improved thread safety afforded by the "threadsafe" style of death
test, thread problems such as deadlock are still possible in the presence of test, thread problems such as deadlock are still possible in the presence of
handlers registered with `pthread_atfork(3)`. handlers registered with `pthread_atfork(3)`.
## Using Assertions in Sub-routines ## Using Assertions in Sub-routines
{: .callout .note} {: .callout .note}
Note: If you want to put a series of test assertions in a subroutine to check Note: If you want to put a series of test assertions in a subroutine to check
for a complex condition, consider using for a complex condition, consider using
[a custom GMock matcher](gmock_cook_book.md#NewMatchers) [a custom GMock matcher](gmock_cook_book.md#NewMatchers) instead. This lets you
instead. This lets you provide a more readable error message in case of failure provide a more readable error message in case of failure and avoid all of the
and avoid all of the issues described below. issues described below.
### Adding Traces to Assertions ### Adding Traces to Assertions
@ -631,6 +629,7 @@ the `SCOPED_TRACE` macro or the `ScopedTrace` utility:
```c++ ```c++
SCOPED_TRACE(message); SCOPED_TRACE(message);
``` ```
```c++ ```c++
ScopedTrace trace("file_path", line_number, message); ScopedTrace trace("file_path", line_number, message);
``` ```
@ -1481,8 +1480,8 @@ In frameworks that report a failure by throwing an exception, you could catch
the exception and assert on it. But googletest doesn't use exceptions, so how do the exception and assert on it. But googletest doesn't use exceptions, so how do
we test that a piece of code generates an expected failure? we test that a piece of code generates an expected failure?
`"gtest/gtest-spi.h"` contains some constructs to do this. After #including this header, `"gtest/gtest-spi.h"` contains some constructs to do this.
you can use After #including this header, you can use
```c++ ```c++
EXPECT_FATAL_FAILURE(statement, substring); EXPECT_FATAL_FAILURE(statement, substring);
@ -1592,6 +1591,7 @@ int main(int argc, char** argv) {
return RUN_ALL_TESTS(); return RUN_ALL_TESTS();
} }
``` ```
## Getting the Current Test's Name ## Getting the Current Test's Name
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.
@ -1816,8 +1816,7 @@ By default, a googletest program runs all tests the user has defined. In some
cases (e.g. iterative test development & execution) it may be desirable stop cases (e.g. iterative test development & execution) it may be desirable stop
test execution upon first failure (trading improved latency for completeness). test execution upon first failure (trading improved latency for completeness).
If `GTEST_FAIL_FAST` environment variable or `--gtest_fail_fast` flag is set, If `GTEST_FAIL_FAST` environment variable or `--gtest_fail_fast` flag is set,
the test runner will stop execution as soon as the first test failure is the test runner will stop execution as soon as the first test failure is found.
found.
#### Temporarily Disabling Tests #### Temporarily Disabling Tests
@ -1965,8 +1964,6 @@ text because, for example, you don't have an UTF-8 compatible output medium, run
the test program with `--gtest_print_utf8=0` or set the `GTEST_PRINT_UTF8` the test program with `--gtest_print_utf8=0` or set the `GTEST_PRINT_UTF8`
environment variable to `0`. environment variable to `0`.
#### Generating an XML Report #### Generating an XML Report
googletest can emit a detailed XML report to a file in addition to its normal googletest can emit a detailed XML report to a file in addition to its normal
@ -2253,12 +2250,11 @@ IMPORTANT: The exact format of the JSON document is subject to change.
#### Detecting Test Premature Exit #### Detecting Test Premature Exit
Google Test implements the _premature-exit-file_ protocol for test runners Google Test implements the _premature-exit-file_ protocol for test runners to
to catch any kind of unexpected exits of test programs. Upon start, catch any kind of unexpected exits of test programs. Upon start, Google Test
Google Test creates the file which will be automatically deleted after creates the file which will be automatically deleted after all work has been
all work has been finished. Then, the test runner can check if this file finished. Then, the test runner can check if this file exists. In case the file
exists. In case the file remains undeleted, the inspected test has exited remains undeleted, the inspected test has exited prematurely.
prematurely.
This feature is enabled only if the `TEST_PREMATURE_EXIT_FILE` environment This feature is enabled only if the `TEST_PREMATURE_EXIT_FILE` environment
variable has been set. variable has been set.

1
docs/faq.md
View File

@ -410,7 +410,6 @@ C++ is case-sensitive. Did you spell it as `Setup()`?
Similarly, sometimes people spell `SetUpTestSuite()` as `SetupTestSuite()` and Similarly, sometimes people spell `SetUpTestSuite()` as `SetupTestSuite()` and
wonder why it's never called. 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. ## 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 You don't have to. Instead of

18
docs/primer.md
View File

@ -162,9 +162,9 @@ TEST(TestSuiteName, TestName) {
`TEST()` arguments go from general to specific. The *first* argument is the name `TEST()` arguments go from general to specific. The *first* argument is the name
of the test suite, and the *second* argument is the test's name within the test of the test suite, and the *second* argument is the test's name within the test
suite. Both names must be valid C++ identifiers, and they should not contain suite. Both names must be valid C++ identifiers, and they should not contain any
any underscores (`_`). A test's *full name* consists of its containing test suite and underscores (`_`). A test's *full name* consists of its containing test suite
its individual name. Tests from different test suites can have the same and its individual name. Tests from different test suites can have the same
individual name. individual name.
For example, let's take a simple integer function: For example, let's take a simple integer function:
@ -245,8 +245,8 @@ Also, you must first define a test fixture class before using it in a
declaration`". declaration`".
For each test defined with `TEST_F()`, googletest will create a *fresh* test For each test defined with `TEST_F()`, googletest will create a *fresh* test
fixture at runtime, immediately initialize it via `SetUp()`, run the test, fixture at runtime, immediately initialize it via `SetUp()`, run the test, clean
clean up by calling `TearDown()`, and then delete the test fixture. Note that up by calling `TearDown()`, and then delete the test fixture. Note that
different tests in the same test suite have different test fixture objects, and different tests in the same test suite have different test fixture objects, and
googletest always deletes a test fixture before it creates the next one. googletest always deletes a test fixture before it creates the next one.
googletest does **not** reuse the same test fixture for multiple tests. Any googletest does **not** reuse the same test fixture for multiple tests. Any
@ -342,8 +342,8 @@ your defined tests in order to run them.
After defining your tests, you can run them with `RUN_ALL_TESTS()`, which After defining your tests, you can run them with `RUN_ALL_TESTS()`, which
returns `0` if all the tests are successful, or `1` otherwise. Note that returns `0` if all the tests are successful, or `1` otherwise. Note that
`RUN_ALL_TESTS()` runs *all tests* in your link unit--they can be from `RUN_ALL_TESTS()` runs *all tests* in your link unit--they can be from different
different test suites, or even different source files. test suites, or even different source files.
When invoked, the `RUN_ALL_TESTS()` macro: When invoked, the `RUN_ALL_TESTS()` macro:
@ -456,8 +456,8 @@ int main(int argc, char **argv) {
The `::testing::InitGoogleTest()` function parses the command line for The `::testing::InitGoogleTest()` function parses the command line for
googletest flags, and removes all recognized flags. This allows the user to googletest flags, and removes all recognized flags. This allows the user to
control a test program's behavior via various flags, which we'll cover in control a test program's behavior via various flags, which we'll cover in the
the [AdvancedGuide](advanced.md). You **must** call this function before calling [AdvancedGuide](advanced.md). You **must** call this function before calling
`RUN_ALL_TESTS()`, or the flags won't be properly initialized. `RUN_ALL_TESTS()`, or the flags won't be properly initialized.
On Windows, `InitGoogleTest()` also works with wide strings, so it can be used On Windows, `InitGoogleTest()` also works with wide strings, so it can be used