gitMirror/googletest
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge pull request #1719 from happyCoder92/master

Browse Source 
docs: fix broken links
This commit is contained in:
Gennadiy Civil 2018-08-09 10:54:09 -07:00 committed by GitHub
commit b46b86ee60
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 5 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
googletest/docs/advanced.md
View File

@ -3,7 +3,7 @@
## Introduction ## Introduction
Now that you have read the [googletest Primer](primer) and learned how to write Now that you have read the [googletest Primer](primer.md) and learned how to write
tests using googletest, it's time to learn some new tricks. This document will tests using googletest, it's time to learn some new tricks. This document will
show you more assertions as well as how to construct complex failure messages, show you more assertions as well as how to construct complex failure messages,
propagate fatal failures, reuse and speed up your test fixtures, and use various propagate fatal failures, reuse and speed up your test fixtures, and use various
@ -152,7 +152,7 @@ c is 10
> >
> 1. If you see a compiler error "no matching function to call" when using > 1. If you see a compiler error "no matching function to call" when using
> `ASSERT_PRED*` or `EXPECT_PRED*`, please see > `ASSERT_PRED*` or `EXPECT_PRED*`, please see
> [this](faq#OverloadedPredicate) for how to resolve it. > [this](faq.md#OverloadedPredicate) for how to resolve it.
> 1. Currently we only provide predicate assertions of arity <= 5. If you need > 1. Currently we only provide predicate assertions of arity <= 5. If you need
> a higher-arity assertion, let [us](https://github.com/google/googletest/issues) know. > a higher-arity assertion, let [us](https://github.com/google/googletest/issues) know.

5
googletest/docs/faq.md
View File

@ -707,8 +707,9 @@ In general, the recommended way to cause the code to behave differently under
test is [Dependency Injection](https://en.wikipedia.org/wiki/Dependency_injection). You can inject test is [Dependency Injection](https://en.wikipedia.org/wiki/Dependency_injection). You can inject
different functionality from the test and from the production code. Since your different functionality from the test and from the production code. Since your
production code doesn't link in the for-test logic at all (the production code doesn't link in the for-test logic at all (the
[`testonly`](http://go/testonly) attribute for BUILD targets helps to ensure [`testonly`](https://docs.bazel.build/versions/master/be/common-definitions.html#common.testonly)
that), there is no danger in accidentally running it. attribute for BUILD targets helps to ensure that), there is no danger in
accidentally running it.
However, if you *really*, *really*, *really* have no choice, and if you follow However, if you *really*, *really*, *really* have no choice, and if you follow
the rule of ending your test program names with `_test`, you can use the the rule of ending your test program names with `_test`, you can use the