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

Merge branch 'master' into hethi/remove-old-docs

Browse Source
This commit is contained in:
Herbert Thielen
2017-08-09 11:03:27 +02:00
parent 6b89677481 461713fec4
commit e022dcded8
27 changed files with 87 additions and 44 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
googletest/docs/AdvancedGuide.md
View File

@@ -32,7 +32,7 @@ output in the future.
`FAIL()` generates a fatal failure, while `ADD_FAILURE()` and `ADD_FAILURE_AT()` generate a nonfatal
failure. These are useful when control flow, rather than a Boolean expression,
deteremines the test's success or failure. For example, you might want to write
determines the test's success or failure. For example, you might want to write
something like:
```
@@ -675,7 +675,7 @@ syntax only.
## How It Works ##
Under the hood, `ASSERT_EXIT()` spawns a new process and executes the
death test statement in that process. The details of of how precisely
death test statement in that process. The details of how precisely
that happens depend on the platform and the variable
`::testing::GTEST_FLAG(death_test_style)` (which is initialized from the
command-line flag `--gtest_death_test_style`).
@@ -1344,7 +1344,7 @@ TYPED_TEST(FooTest, DoesBlah) {
TYPED_TEST(FooTest, HasPropertyA) { ... }
```
You can see `samples/sample6_unittest.cc` for a complete example.
You can see [`samples/sample6_unittest.cc`](../samples/sample6_unittest.cc) for a complete example.
_Availability:_ Linux, Windows (requires MSVC 8.0 or above), Mac;
since version 1.1.0.
@@ -1551,7 +1551,7 @@ exception, you could catch the exception and assert on it. But Google
Test doesn't use exceptions, so how do we test that a piece of code
generates an expected failure?
`"gtest/gtest-spi.h"` contains some constructs to do this. After
`"gtest/gtest-spi.h"` contains some constructs to do this. After
`#include`ing this header, you can use
| `EXPECT_FATAL_FAILURE(`_statement, substring_`);` |

4
googletest/docs/DevGuide.md
View File

@@ -80,8 +80,8 @@ instructions for how to sign and return it.
## Coding Style ##
To keep the source consistent, readable, diffable and easy to merge,
we use a fairly rigid coding style, as defined by the [google-styleguide](http://code.google.com/p/google-styleguide/) project. All patches will be expected
to conform to the style outlined [here](http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml).
we use a fairly rigid coding style, as defined by the [google-styleguide](https://github.com/google/styleguide) project. All patches will be expected
to conform to the style outlined [here](https://google.github.io/styleguide/cppguide.html).
## Updating Generated Code ##

2
googletest/docs/Primer.md
View File

@@ -382,7 +382,7 @@ When invoked, the `RUN_ALL_TESTS()` macro:
1. Restores the state of all Google Test flags.
1. Repeats the above steps for the next test, until all tests have run.
In addition, if the text fixture's constructor generates a fatal failure in
In addition, if the test fixture's constructor generates a fatal failure in
step 2, there is no point for step 3 - 5 and they are thus skipped. Similarly,
if step 3 generates a fatal failure, step 4 will be skipped.