Googletest export
Docs cleanup PiperOrigin-RevId: 356798444
This commit is contained in:
parent
eac6a02cc2
commit
609281088c
@ -107,7 +107,7 @@ assertion* to get the function arguments printed for free:
|
|||||||
| `ASSERT_PRED2(pred2, val1, val2)` | `EXPECT_PRED2(pred2, val1, val2)` | `pred2(val1, val2)` is true |
|
| `ASSERT_PRED2(pred2, val1, val2)` | `EXPECT_PRED2(pred2, val1, val2)` | `pred2(val1, val2)` is true |
|
||||||
| `...` | `...` | `...` |
|
| `...` | `...` | `...` |
|
||||||
|
|
||||||
<!-- mdformat on-->
|
<!-- mdformat on -->
|
||||||
In the above, `predn` is an `n`-ary predicate function or functor, where `val1`,
|
In the above, `predn` is an `n`-ary predicate function or functor, where `val1`,
|
||||||
`val2`, ..., and `valn` are its arguments. The assertion succeeds if the
|
`val2`, ..., and `valn` are its arguments. The assertion succeeds if the
|
||||||
predicate returns `true` when applied to the given arguments, and fails
|
predicate returns `true` when applied to the given arguments, and fails
|
||||||
@ -336,7 +336,7 @@ want to learn more, see
|
|||||||
| `ASSERT_FLOAT_EQ(val1, val2);` | `EXPECT_FLOAT_EQ(val1, val2);` | the two `float` values are almost equal |
|
| `ASSERT_FLOAT_EQ(val1, val2);` | `EXPECT_FLOAT_EQ(val1, val2);` | the two `float` values are almost equal |
|
||||||
| `ASSERT_DOUBLE_EQ(val1, val2);` | `EXPECT_DOUBLE_EQ(val1, val2);` | the two `double` values are almost equal |
|
| `ASSERT_DOUBLE_EQ(val1, val2);` | `EXPECT_DOUBLE_EQ(val1, val2);` | the two `double` values are almost equal |
|
||||||
|
|
||||||
<!-- mdformat on-->
|
<!-- mdformat on -->
|
||||||
|
|
||||||
By "almost equal" we mean the values are within 4 ULP's from each other.
|
By "almost equal" we mean the values are within 4 ULP's from each other.
|
||||||
|
|
||||||
@ -348,7 +348,7 @@ The following assertions allow you to choose the acceptable error bound:
|
|||||||
| ------------------------------------- | ------------------------------------- | -------------------------------------------------------------------------------- |
|
| ------------------------------------- | ------------------------------------- | -------------------------------------------------------------------------------- |
|
||||||
| `ASSERT_NEAR(val1, val2, abs_error);` | `EXPECT_NEAR(val1, val2, abs_error);` | the difference between `val1` and `val2` doesn't exceed the given absolute error |
|
| `ASSERT_NEAR(val1, val2, abs_error);` | `EXPECT_NEAR(val1, val2, abs_error);` | the difference between `val1` and `val2` doesn't exceed the given absolute error |
|
||||||
|
|
||||||
<!-- mdformat on-->
|
<!-- mdformat on -->
|
||||||
|
|
||||||
#### Floating-Point Predicate-Format Functions
|
#### Floating-Point Predicate-Format Functions
|
||||||
|
|
||||||
@ -379,7 +379,7 @@ macros:
|
|||||||
| ------------------------------ | ------------------------------ | --------------------- |
|
| ------------------------------ | ------------------------------ | --------------------- |
|
||||||
| `ASSERT_THAT(value, matcher);` | `EXPECT_THAT(value, matcher);` | value matches matcher |
|
| `ASSERT_THAT(value, matcher);` | `EXPECT_THAT(value, matcher);` | value matches matcher |
|
||||||
|
|
||||||
<!-- mdformat on-->
|
<!-- mdformat on -->
|
||||||
|
|
||||||
For example, `StartsWith(prefix)` is a matcher that matches a string starting
|
For example, `StartsWith(prefix)` is a matcher that matches a string starting
|
||||||
with `prefix`, and you can write:
|
with `prefix`, and you can write:
|
||||||
@ -1365,7 +1365,7 @@ namespace:
|
|||||||
| `Bool()` | Yields sequence `{false, true}`. |
|
| `Bool()` | Yields sequence `{false, true}`. |
|
||||||
| `Combine(g1, g2, ..., gN)` | Yields all combinations (Cartesian product) as std\:\:tuples of the values generated by the `N` generators. |
|
| `Combine(g1, g2, ..., gN)` | Yields all combinations (Cartesian product) as std\:\:tuples of the values generated by the `N` generators. |
|
||||||
|
|
||||||
<!-- mdformat on-->
|
<!-- mdformat on -->
|
||||||
|
|
||||||
For more details, see the comments at the definitions of these functions.
|
For more details, see the comments at the definitions of these functions.
|
||||||
|
|
||||||
@ -2155,9 +2155,9 @@ NOTE: This feature should only be used for temporary pain-relief. You still have
|
|||||||
to fix the disabled tests at a later date. As a reminder, googletest will print
|
to fix the disabled tests at a later date. As a reminder, googletest will print
|
||||||
a banner warning you if a test program contains any disabled tests.
|
a banner warning you if a test program contains any disabled tests.
|
||||||
|
|
||||||
TIP: You can easily count the number of disabled tests you have using `gsearch`
|
TIP: You can easily count the number of disabled tests you have using
|
||||||
and/or `grep`. This number can be used as a metric for improving your test
|
`grep`. This number can be used as a metric for
|
||||||
quality.
|
improving your test quality.
|
||||||
|
|
||||||
#### Temporarily Enabling Disabled Tests
|
#### Temporarily Enabling Disabled Tests
|
||||||
|
|
||||||
|
@ -8,9 +8,9 @@ object (so it can be used as one), but lets you specify at run time how it will
|
|||||||
be used and what it should do (which methods will be called? in which order? how
|
be used and what it should do (which methods will be called? in which order? how
|
||||||
many times? with what arguments? what will they return? etc).
|
many times? with what arguments? what will they return? etc).
|
||||||
|
|
||||||
**Note:** It is easy to confuse the term *fake objects* with mock objects. Fakes
|
It is easy to confuse the term *fake objects* with mock objects. Fakes and mocks
|
||||||
and mocks actually mean very different things in the Test-Driven Development
|
actually mean very different things in the Test-Driven Development (TDD)
|
||||||
(TDD) community:
|
community:
|
||||||
|
|
||||||
* **Fake** objects have working implementations, but usually take some
|
* **Fake** objects have working implementations, but usually take some
|
||||||
shortcut (perhaps to make the operations less expensive), which makes them
|
shortcut (perhaps to make the operations less expensive), which makes them
|
||||||
@ -51,9 +51,9 @@ them fast and reliable, using mocks manually in C++ is *hard*:
|
|||||||
one.
|
one.
|
||||||
|
|
||||||
In contrast, Java and Python programmers have some fine mock frameworks (jMock,
|
In contrast, Java and Python programmers have some fine mock frameworks (jMock,
|
||||||
EasyMock, [Mox](http://wtf/mox), etc), which automate the creation of mocks. As
|
EasyMock, etc), which automate the creation of mocks. As a result, mocking is a
|
||||||
a result, mocking is a proven effective technique and widely adopted practice in
|
proven effective technique and widely adopted practice in those communities.
|
||||||
those communities. Having the right tool absolutely makes the difference.
|
Having the right tool absolutely makes the difference.
|
||||||
|
|
||||||
gMock was built to help C++ programmers. It was inspired by jMock and EasyMock,
|
gMock was built to help C++ programmers. It was inspired by jMock and EasyMock,
|
||||||
but designed with C++'s specifics in mind. It is your friend if any of the
|
but designed with C++'s specifics in mind. It is your friend if any of the
|
||||||
@ -335,7 +335,7 @@ will return 100 the first time, 150 the second time, and then 200 every time.
|
|||||||
Some people like to call this style of syntax a Domain-Specific Language (DSL).
|
Some people like to call this style of syntax a Domain-Specific Language (DSL).
|
||||||
|
|
||||||
**Note:** Why do we use a macro to do this? Well it serves two purposes: first
|
**Note:** Why do we use a macro to do this? Well it serves two purposes: first
|
||||||
it makes expectations easily identifiable (either by `gsearch` or by a human
|
it makes expectations easily identifiable (either by `grep` or by a human
|
||||||
reader), and second it allows gMock to include the source file location of a
|
reader), and second it allows gMock to include the source file location of a
|
||||||
failed expectation in messages, making debugging easier.
|
failed expectation in messages, making debugging easier.
|
||||||
|
|
||||||
|
@ -227,7 +227,7 @@ two `string` objects, use `EXPECT_EQ`, `EXPECT_NE`, and etc instead.
|
|||||||
| `ASSERT_STRCASEEQ(str1,str2);` | `EXPECT_STRCASEEQ(str1,str2);` | the two C strings have the same content, ignoring case |
|
| `ASSERT_STRCASEEQ(str1,str2);` | `EXPECT_STRCASEEQ(str1,str2);` | the two C strings have the same content, ignoring case |
|
||||||
| `ASSERT_STRCASENE(str1,str2);` | `EXPECT_STRCASENE(str1,str2);` | the two C strings have different contents, ignoring case |
|
| `ASSERT_STRCASENE(str1,str2);` | `EXPECT_STRCASENE(str1,str2);` | the two C strings have different contents, ignoring case |
|
||||||
|
|
||||||
<!-- mdformat on-->
|
<!-- mdformat on -->
|
||||||
|
|
||||||
Note that "CASE" in an assertion name means that case is ignored. A `NULL`
|
Note that "CASE" in an assertion name means that case is ignored. A `NULL`
|
||||||
pointer and an empty string are considered *different*.
|
pointer and an empty string are considered *different*.
|
||||||
|
Loading…
Reference in New Issue
Block a user