Preparation for including docs in round-trip with OSS. Manual review and merge docs internal-OSS
This commit is contained in:
Gennadiy Civil
parent
4ab6f4d709
commit
f899e81e43
@ -57,8 +57,6 @@ switch(expression) {
|
||||
NOTE: you can only use `FAIL()` in functions that return `void`. See the
|
||||
[Assertion Placement section](#assertion-placement) for more information.
|
||||
|
||||
|
||||
|
||||
### Exception Assertions
|
||||
|
||||
These are for verifying that a piece of code throws (or does not throw) an
|
||||
@ -81,8 +79,7 @@ EXPECT_NO_THROW({
|
||||
});
|
||||
```
|
||||
|
||||
**Availability**: requires exceptions to be enabled in the
|
||||
build environment
|
||||
**Availability**: requires exceptions to be enabled in the build environment
|
||||
|
||||
### Predicate Assertions for Better Error Messages
|
||||
|
||||
@ -156,8 +153,6 @@ c is 10
|
||||
> [this](faq.md#the-compiler-complains-no-matching-function-to-call-when-i-use-assert-pred-how-do-i-fix-it)
|
||||
> for how to resolve it.
|
||||
|
||||
|
||||
|
||||
#### Using a Function That Returns an AssertionResult
|
||||
|
||||
While `EXPECT_PRED*()` and friends are handy for a quick job, the syntax is not
|
||||
@ -245,8 +240,6 @@ Then the statement `EXPECT_FALSE(IsEven(Fib(6)))` will print
|
||||
Expected: false
|
||||
```
|
||||
|
||||
|
||||
|
||||
#### Using a Predicate-Formatter
|
||||
|
||||
If you find the default message generated by `(ASSERT|EXPECT)_PRED*` and
|
||||
@ -319,8 +312,6 @@ As you may have realized, many of the built-in assertions we introduced earlier
|
||||
are special cases of `(EXPECT|ASSERT)_PRED_FORMAT*`. In fact, most of them are
|
||||
indeed defined using `(EXPECT|ASSERT)_PRED_FORMAT*`.
|
||||
|
||||
|
||||
|
||||
### Floating-Point Comparison
|
||||
|
||||
Comparing floating-point numbers is tricky. Due to round-off errors, it is very
|
||||
@ -357,8 +348,6 @@ The following assertions allow you to choose the acceptable error bound:
|
||||
: : : exceed the given absolute :
|
||||
: : : error :
|
||||
|
||||
|
||||
|
||||
#### Floating-Point Predicate-Format Functions
|
||||
|
||||
Some floating-point operations are useful, but not that often used. In order to
|
||||
@ -374,8 +363,6 @@ EXPECT_PRED_FORMAT2(::testing::DoubleLE, val1, val2);
|
||||
Verifies that `val1` is less than, or almost equal to, `val2`. You can replace
|
||||
`EXPECT_PRED_FORMAT2` in the above table with `ASSERT_PRED_FORMAT2`.
|
||||
|
||||
|
||||
|
||||
### Asserting Using gMock Matchers
|
||||
|
||||
[gMock](../../googlemock) comes with a library of matchers for validating
|
||||
@ -427,8 +414,6 @@ using ::testing::MatchesRegex;
|
||||
EXPECT_THAT(bar_string, MatchesRegex("\\w*\\d+"));
|
||||
```
|
||||
|
||||
|
||||
|
||||
If the string contains a well-formed HTML or XML document, you can check whether
|
||||
its DOM tree matches an
|
||||
[XPath expression](http://www.w3.org/TR/xpath/#contents):
|
||||
@ -501,8 +486,6 @@ void Test2() { Foo<bool> foo; foo.Bar(); }
|
||||
|
||||
to cause a compiler error.
|
||||
|
||||
|
||||
|
||||
### Assertion Placement
|
||||
|
||||
You can use assertions in any C++ function. In particular, it doesn't have to be
|
||||
@ -995,8 +978,6 @@ Some tips on using `SCOPED_TRACE`:
|
||||
5. The trace dump is clickable in Emacs - hit `return` on a line number and
|
||||
you'll be taken to that line in the source file!
|
||||
|
||||
|
||||
|
||||
### Propagating Fatal Failures
|
||||
|
||||
A common pitfall when using `ASSERT_*` and `FAIL*` is not understanding that
|
||||
@ -1077,8 +1058,7 @@ EXPECT_NO_FATAL_FAILURE({
|
||||
});
|
||||
```
|
||||
|
||||
Assertions from multiple threads are
|
||||
currently not supported on Windows.
|
||||
Assertions from multiple threads are currently not supported on Windows.
|
||||
|
||||
#### Checking for Failures in the Current Test
|
||||
|
||||
@ -1119,8 +1099,6 @@ 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
|
||||
@ -1159,8 +1137,6 @@ will output XML like this:
|
||||
> of all test suites (e.g. in a test environment), it will be attributed to
|
||||
> the top-level XML element.
|
||||
|
||||
|
||||
|
||||
## Sharing Resources Between Tests in the Same Test Suite
|
||||
|
||||
googletest creates a new test fixture object for each test in order to make
|
||||
@ -1237,8 +1213,6 @@ NOTE: Though the above code declares `SetUpTestSuite()` protected, it may
|
||||
sometimes be necessary to declare it public, such as when using it with
|
||||
`TEST_P`.
|
||||
|
||||
|
||||
|
||||
## Global Set-Up and Tear-Down
|
||||
|
||||
Just as you can do set-up and tear-down at the test level and the test suite
|
||||
@ -1934,8 +1908,6 @@ particular, you cannot find the test suite name in `TestSuiteSetUp()`,
|
||||
`TestSuiteTearDown()` (where you know the test suite name implicitly), or
|
||||
functions called from them.
|
||||
|
||||
|
||||
|
||||
## Extending googletest by Handling Test Events
|
||||
|
||||
googletest provides an **event listener API** to let you receive notifications
|
||||
@ -1946,8 +1918,6 @@ console output, replace the XML output, or provide a completely different form
|
||||
of output, such as a GUI or a database. You can also use test events as
|
||||
checkpoints to implement a resource leak checker, for example.
|
||||
|
||||
|
||||
|
||||
### Defining Event Listeners
|
||||
|
||||
To define a event listener, you subclass either testing::TestEventListener or
|
||||
@ -2088,8 +2058,6 @@ TestSuite2.
|
||||
None of the tests listed are actually run if the flag is provided. There is no
|
||||
corresponding environment variable for this flag.
|
||||
|
||||
|
||||
|
||||
#### Running a Subset of the Tests
|
||||
|
||||
By default, a googletest program runs all tests the user has defined. Sometimes,
|
||||
@ -2156,8 +2124,6 @@ TIP: You can easily count the number of disabled tests you have using `gsearch`
|
||||
and/or `grep`. This number can be used as a metric for improving your test
|
||||
quality.
|
||||
|
||||
|
||||
|
||||
#### Temporarily Enabling Disabled Tests
|
||||
|
||||
To include disabled tests in test execution, just invoke the test program with
|
||||
@ -2166,8 +2132,6 @@ the `--gtest_also_run_disabled_tests` flag or set the
|
||||
You can combine this with the `--gtest_filter` flag to further select which
|
||||
disabled tests to run.
|
||||
|
||||
|
||||
|
||||
### Repeating the Tests
|
||||
|
||||
Once in a while you'll run into a test whose result is hit-or-miss. Perhaps it
|
||||
@ -2364,8 +2328,6 @@ Things to note:
|
||||
* Each `<failure>` element corresponds to a single failed googletest
|
||||
assertion.
|
||||
|
||||
|
||||
|
||||
#### Generating a JSON Report
|
||||
|
||||
googletest can also emit a JSON report as an alternative format to XML. To
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user