eson/googletest
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Merge pull request #2495 from hyukmyeong:typo

Browse Source 
PiperOrigin-RevId: 273346440
This commit is contained in:
Gennadiy Civil 2019-10-07 15:16:08 -04:00
commit 3f5a8c6ee6
3 changed files with 7 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
googlemock/docs/for_dummies.md
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: 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 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. namespaces are a good idea.
2. Create some mock objects. 2. Create some mock objects.
3. Specify your expectations on them (How many times will a method be called? 3. Specify your expectations on them (How many times will a method be called?

10
googletest/docs/advanced.md
View File

@ -642,7 +642,7 @@ Fatal assertion | Nonfatal assertion
where `statement` is a statement that is expected to cause the process to die, 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 `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 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) 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` 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 > has called `exit()` or `_exit()` with a non-zero value, or it may be killed by
> a signal. > 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 > 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. > 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 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`) satisfy `predicate`? Or (in the case of `ASSERT_DEATH` and `EXPECT_DEATH`)
is the exit status non-zero? And 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 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 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 > * `RecordProperty()` is a static member of the `Test` class. Therefore it
> needs to be prefixed with `::testing::Test::` if used outside of the > needs to be prefixed with `::testing::Test::` if used outside of the
> `TEST` body and the test fixture class. > `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`, > ones already used by googletest (`name`, `status`, `time`, `classname`,
> `type_param`, and `value_param`). > `type_param`, and `value_param`).
> * Calling `RecordProperty()` outside of the lifespan of a test is allowed. > * 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 = const ::testing::TestInfo* const test_info =
::testing::UnitTest::GetInstance()->current_test_info(); ::testing::UnitTest::GetInstance()->current_test_info();
printf("We are in test %s of test suite %s.\n", printf("We are in test %s of test suite %s.\n",
test_info->name(), test_info->name(),
test_info->test_suite_name()); test_info->test_suite_name());

4
googletest/docs/faq.md
View File

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