Fix typo in documents

This commit is contained in:
hyuk.myeong 2019-10-01 14:24:55 +09:00
parent dc1ca9ae4c
commit 51f7396d40
3 changed files with 7 additions and 9 deletions

View File

@ -213,7 +213,7 @@ specific domain much better than `Foo` does.
Once you have a mock class, using it is easy. The typical work flow is:
1. Import the gMock names from the `testing` namespace such that you can use
them unqualified (You only have to do it once per file. Remember that
them unqualified (You only have to do it once per file). Remember that
namespaces are a good idea.
2. Create some mock objects.
3. Specify your expectations on them (How many times will a method be called?

View File

@ -642,7 +642,7 @@ Fatal assertion | Nonfatal assertion
where `statement` is a statement that is expected to cause the process to die,
`predicate` is a function or function object that evaluates an integer exit
status, and `matcher` is either a GMock matcher matching a `const std::string&`
status, and `matcher` is either a gMock matcher matching a `const std::string&`
or a (Perl) regular expression - either of which is matched against the stderr
output of `statement`. For legacy reasons, a bare string (i.e. with no matcher)
is interpreted as `ContainsRegex(str)`, **not** `Eq(str)`. Note that `statement`
@ -657,7 +657,7 @@ As usual, the `ASSERT` variants abort the current test function, while the
> has called `exit()` or `_exit()` with a non-zero value, or it may be killed by
> a signal.
>
> This means that if `*statement*` terminates the process with a 0 exit code, it
> This means that if *`statement`* terminates the process with a 0 exit code, it
> is *not* considered a crash by `EXPECT_DEATH`. Use `EXPECT_EXIT` instead if
> this is the case, or if you want to restrict the exit code more precisely.
@ -687,7 +687,7 @@ Note that a death test only cares about three things:
2. (in the case of `ASSERT_EXIT` and `EXPECT_EXIT`) does the exit status
satisfy `predicate`? Or (in the case of `ASSERT_DEATH` and `EXPECT_DEATH`)
is the exit status non-zero? And
3. does the stderr output match `regex`?
3. does the stderr output match `matcher`?
In particular, if `statement` generates an `ASSERT_*` or `EXPECT_*` failure, it
will **not** cause the death test to fail, as googletest assertions don't abort
@ -1132,7 +1132,7 @@ will output XML like this:
> * `RecordProperty()` is a static member of the `Test` class. Therefore it
> needs to be prefixed with `::testing::Test::` if used outside of the
> `TEST` body and the test fixture class.
> * `*key*` must be a valid XML attribute name, and cannot conflict with the
> * *`key`* must be a valid XML attribute name, and cannot conflict with the
> ones already used by googletest (`name`, `status`, `time`, `classname`,
> `type_param`, and `value_param`).
> * Calling `RecordProperty()` outside of the lifespan of a test is allowed.
@ -1904,8 +1904,6 @@ To obtain a `TestInfo` object for the currently running test, call
const ::testing::TestInfo* const test_info =
::testing::UnitTest::GetInstance()->current_test_info();
printf("We are in test %s of test suite %s.\n",
test_info->name(),
test_info->test_suite_name());

View File

@ -531,8 +531,8 @@ There are several good reasons:
## What can the statement argument in ASSERT_DEATH() be?
`ASSERT_DEATH(*statement*, *regex*)` (or any death assertion macro) can be used
wherever `*statement*` is valid. So basically `*statement*` can be any C++
`ASSERT_DEATH(statement, matcher)` (or any death assertion macro) can be used
wherever *`statement`* is valid. So basically *`statement`* can be any C++
statement that makes sense in the current context. In particular, it can
reference global and/or local variables, and can be: