summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorGennadiy Civil <gennadiycivil@users.noreply.github.com>2018-08-20 15:04:11 (GMT)
committerGitHub <noreply@github.com>2018-08-20 15:04:11 (GMT)
commit9404c5ae04312630638a95da1435ee8a9c74ffe8 (patch)
tree9ce76a98e56c0ecd1b530a4552c3d89c29e737f1
parent49e6a9b771c2d3cc4f0b3856bfcc7316ae51c1f6 (diff)
parentddc618ab31c8b683b52e26304bfd7bd9b4a3bb0f (diff)
downloadgoogletest-9404c5ae04312630638a95da1435ee8a9c74ffe8.zip
googletest-9404c5ae04312630638a95da1435ee8a9c74ffe8.tar.gz
googletest-9404c5ae04312630638a95da1435ee8a9c74ffe8.tar.bz2
Merge pull request #1754 from vkotovv/docs-advanced-broken-links
docs: fixed broken references to sections in Advanced guide
-rw-r--r--googletest/docs/advanced.md10
1 files changed, 5 insertions, 5 deletions
diff --git a/googletest/docs/advanced.md b/googletest/docs/advanced.md
index 3a097f1..8065d19 100644
--- a/googletest/docs/advanced.md
+++ b/googletest/docs/advanced.md
@@ -649,7 +649,7 @@ _death tests_. More generally, any test that checks that a program terminates
Note that if a piece of code throws an exception, we don't consider it "death"
for the purpose of death tests, as the caller of the code could catch the
exception and avoid the crash. If you want to verify exceptions thrown by your
-code, see [Exception Assertions](#ExceptionAssertions).
+code, see [Exception Assertions](#exception-assertions).
If you want to test `EXPECT_*()/ASSERT_*()` failures in your test code, see
Catching Failures
@@ -1147,7 +1147,7 @@ test has at least one failure of either kind.
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](#XmlReport) if you
+recorded for a key will be emitted to the [XML output](#generating-an-xml-report) if you
specify one. For example, the test
```c++
@@ -1424,7 +1424,7 @@ will have these names:
* `InstantiationName/FooTest.HasBlahBlah/1` for `"miny"`
* `InstantiationName/FooTest.HasBlahBlah/2` for `"moe"`
-You can use these names in [`--gtest_filter`](#TestFilter).
+You can use these names in [`--gtest_filter`](#running-a-subset-of-the-tests).
This statement will instantiate all tests from `FooTest` again, each with
parameter values `"cat"` and `"dog"`:
@@ -1674,7 +1674,7 @@ To test them, we use the following special techniques:
* Both static functions and definitions/declarations in an unnamed namespace
are only visible within the same translation unit. To test them, you can
`#include` the entire `.cc` file being tested in your `*_test.cc` file.
- (#including `.cc` files is not a good way to reuse code - you should not do
+ (including `.cc` files is not a good way to reuse code - you should not do
this in production code!)
However, a better approach is to move the private code into the
@@ -2120,7 +2120,7 @@ $ foo_test --gtest_repeat=1000 --gtest_filter=FooBar.*
Repeat the tests whose name matches the filter 1000 times.
```
-If your test program contains [global set-up/tear-down](#GlobalSetUp) code, it
+If your test program contains [global set-up/tear-down](#global-set-up-and-tear-down) code, it
will be repeated in each iteration as well, as the flakiness may be in it. You
can also specify the repeat count by setting the `GTEST_REPEAT` environment
variable.