Commit e935e6c3 by Abseil Team Committed by Derek Mauro

Googletest export

Internal change PiperOrigin-RevId: 356867746
parent 60928108
...@@ -99,7 +99,6 @@ If you already have a function or functor that returns `bool` (or a type that ...@@ -99,7 +99,6 @@ If you already have a function or functor that returns `bool` (or a type that
can be implicitly converted to `bool`), you can use it in a *predicate can be implicitly converted to `bool`), you can use it in a *predicate
assertion* to get the function arguments printed for free: assertion* to get the function arguments printed for free:
<!-- mdformat off(github rendering does not support multiline tables) -->
| Fatal assertion | Nonfatal assertion | Verifies | | Fatal assertion | Nonfatal assertion | Verifies |
| --------------------------------- | --------------------------------- | --------------------------- | | --------------------------------- | --------------------------------- | --------------------------- |
...@@ -107,7 +106,6 @@ assertion* to get the function arguments printed for free: ...@@ -107,7 +106,6 @@ 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 -->
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
...@@ -329,26 +327,22 @@ want to learn more, see ...@@ -329,26 +327,22 @@ want to learn more, see
#### Floating-Point Macros #### Floating-Point Macros
<!-- mdformat off(github rendering does not support multiline tables) -->
| Fatal assertion | Nonfatal assertion | Verifies | | Fatal assertion | Nonfatal assertion | Verifies |
| ------------------------------- | ------------------------------- | ---------------------------------------- | | ------------------------------- | ------------------------------- | ---------------------------------------- |
| `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 -->
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.
The following assertions allow you to choose the acceptable error bound: The following assertions allow you to choose the acceptable error bound:
<!-- mdformat off(github rendering does not support multiline tables) -->
| Fatal assertion | Nonfatal assertion | Verifies | | Fatal assertion | Nonfatal assertion | Verifies |
| ------------------------------------- | ------------------------------------- | -------------------------------------------------------------------------------- | | ------------------------------------- | ------------------------------------- | -------------------------------------------------------------------------------- |
| `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 -->
#### Floating-Point Predicate-Format Functions #### Floating-Point Predicate-Format Functions
...@@ -373,13 +367,11 @@ validating arguments passed to mock objects. A gMock *matcher* is basically a ...@@ -373,13 +367,11 @@ validating arguments passed to mock objects. A gMock *matcher* is basically a
predicate that knows how to describe itself. It can be used in these assertion predicate that knows how to describe itself. It can be used in these assertion
macros: macros:
<!-- mdformat off(github rendering does not support multiline tables) -->
| Fatal assertion | Nonfatal assertion | Verifies | | Fatal assertion | Nonfatal assertion | Verifies |
| ------------------------------ | ------------------------------ | --------------------- | | ------------------------------ | ------------------------------ | --------------------- |
| `ASSERT_THAT(value, matcher);` | `EXPECT_THAT(value, matcher);` | value matches matcher | | `ASSERT_THAT(value, matcher);` | `EXPECT_THAT(value, matcher);` | value matches matcher |
<!-- 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:
...@@ -1355,7 +1347,6 @@ for generating test parameters. They return what we call (surprise!) *parameter ...@@ -1355,7 +1347,6 @@ for generating test parameters. They return what we call (surprise!) *parameter
generators*. Here is a summary of them, which are all in the `testing` generators*. Here is a summary of them, which are all in the `testing`
namespace: namespace:
<!-- mdformat off(github rendering does not support multiline tables) -->
| Parameter Generator | Behavior | | Parameter Generator | Behavior |
| ----------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------- | | ----------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------- |
...@@ -1365,7 +1356,6 @@ namespace: ...@@ -1365,7 +1356,6 @@ 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 -->
For more details, see the comments at the definitions of these functions. For more details, see the comments at the definitions of these functions.
...@@ -1428,8 +1418,8 @@ given test suite, whether their definitions come before or *after* the ...@@ -1428,8 +1418,8 @@ given test suite, whether their definitions come before or *after* the
You can see [sample7_unittest.cc] and [sample8_unittest.cc] for more examples. You can see [sample7_unittest.cc] and [sample8_unittest.cc] for more examples.
[sample7_unittest.cc]: ../googletest/samples/sample7_unittest.cc "Parameterized Test example" [sample7_unittest.cc]: https://github.com/google/googletest/blob/master/googletest/samples/sample7_unittest.cc "Parameterized Test example"
[sample8_unittest.cc]: ../googletest/samples/sample8_unittest.cc "Parameterized Test example with multiple parameters" [sample8_unittest.cc]: https://github.com/google/googletest/blob/master/googletest/samples/sample8_unittest.cc "Parameterized Test example with multiple parameters"
### Creating Value-Parameterized Abstract Tests ### Creating Value-Parameterized Abstract Tests
...@@ -1579,7 +1569,7 @@ TYPED_TEST(FooTest, HasPropertyA) { ... } ...@@ -1579,7 +1569,7 @@ TYPED_TEST(FooTest, HasPropertyA) { ... }
You can see [sample6_unittest.cc] for a complete example. You can see [sample6_unittest.cc] for a complete example.
[sample6_unittest.cc]: ../googletest/samples/sample6_unittest.cc "Typed Test example" [sample6_unittest.cc]: https://github.com/google/googletest/blob/master/googletest/samples/sample6_unittest.cc "Typed Test example"
## Type-Parameterized Tests ## Type-Parameterized Tests
...@@ -2022,7 +2012,7 @@ You can do so by adding one line: ...@@ -2022,7 +2012,7 @@ You can do so by adding one line:
Now, sit back and enjoy a completely different output from your tests. For more Now, sit back and enjoy a completely different output from your tests. For more
details, see [sample9_unittest.cc]. details, see [sample9_unittest.cc].
[sample9_unittest.cc]: ../googletest/samples/sample9_unittest.cc "Event listener example" [sample9_unittest.cc]: https://github.com/google/googletest/blob/master/googletest/samples/sample9_unittest.cc "Event listener example"
You may append more than one listener to the list. When an `On*Start()` or You may append more than one listener to the list. When an `On*Start()` or
`OnTestPartResult()` event is fired, the listeners will receive it in the order `OnTestPartResult()` event is fired, the listeners will receive it in the order
...@@ -2049,7 +2039,7 @@ by the former. ...@@ -2049,7 +2039,7 @@ by the former.
See [sample10_unittest.cc] for an example of a failure-raising listener. See [sample10_unittest.cc] for an example of a failure-raising listener.
[sample10_unittest.cc]: ../googletest/samples/sample10_unittest.cc "Failure-raising listener example" [sample10_unittest.cc]: https://github.com/google/googletest/blob/master/googletest/samples/sample10_unittest.cc "Failure-raising listener example"
## Running Test Programs: Advanced Options ## Running Test Programs: Advanced Options
......
...@@ -265,7 +265,7 @@ If necessary, you can continue to derive test fixtures from a derived fixture. ...@@ -265,7 +265,7 @@ If necessary, you can continue to derive test fixtures from a derived fixture.
googletest has no limit on how deep the hierarchy can be. googletest has no limit on how deep the hierarchy can be.
For a complete example using derived test fixtures, see For a complete example using derived test fixtures, see
[sample5_unittest.cc](../googletest/samples/sample5_unittest.cc). [sample5_unittest.cc](https://github.com/google/googletest/blob/master/googletest/samples/sample5_unittest.cc).
## My compiler complains "void value not ignored as it ought to be." What does this mean? ## My compiler complains "void value not ignored as it ought to be." What does this mean?
...@@ -670,7 +670,7 @@ there is an `std::ostream& operator<<(std::ostream&, const FooType&)` function ...@@ -670,7 +670,7 @@ there is an `std::ostream& operator<<(std::ostream&, const FooType&)` function
defined such that we can print a value of `FooType`. defined such that we can print a value of `FooType`.
In addition, if `FooType` is declared in a name space, the `<<` operator also In addition, if `FooType` is declared in a name space, the `<<` operator also
needs to be defined in the *same* name space. See https://abseil.io/tips/49 for details. needs to be defined in the *same* name space. See abseil.io/tips/49 for details.
## How do I suppress the memory leak messages on Windows? ## How do I suppress the memory leak messages on Windows?
......
...@@ -1250,12 +1250,10 @@ that satisfies matcher `m`. ...@@ -1250,12 +1250,10 @@ that satisfies matcher `m`.
For example: For example:
<!-- mdformat off(github rendering does not support multiline tables) -->
| Expression | Description | | Expression | Description |
| :--------------------------- | :--------------------------------------- | | :--------------------------- | :--------------------------------------- |
| `Field(&Foo::number, Ge(3))` | Matches `x` where `x.number >= 3`. | | `Field(&Foo::number, Ge(3))` | Matches `x` where `x.number >= 3`. |
| `Property(&Foo::name, StartsWith("John "))` | Matches `x` where `x.name()` starts with `"John "`. | | `Property(&Foo::name, StartsWith("John "))` | Matches `x` where `x.name()` starts with `"John "`. |
<!-- mdformat on -->
Note that in `Property(&Foo::baz, ...)`, method `baz()` must take no argument Note that in `Property(&Foo::baz, ...)`, method `baz()` must take no argument
and be declared as `const`. Don't use `Property()` against member functions that and be declared as `const`. Don't use `Property()` against member functions that
...@@ -4123,7 +4121,6 @@ If you are writing a function that returns an `ACTION` object, you'll need to ...@@ -4123,7 +4121,6 @@ If you are writing a function that returns an `ACTION` object, you'll need to
know its type. The type depends on the macro used to define the action and the know its type. The type depends on the macro used to define the action and the
parameter types. The rule is relatively simple: parameter types. The rule is relatively simple:
<!-- mdformat off(GitHub does not support multiline tables) -->
| Given Definition | Expression | Has Type | | Given Definition | Expression | Has Type |
| ----------------------------- | ------------------- | --------------------- | | ----------------------------- | ------------------- | --------------------- |
...@@ -4135,7 +4132,6 @@ parameter types. The rule is relatively simple: ...@@ -4135,7 +4132,6 @@ parameter types. The rule is relatively simple:
| `ACTION_TEMPLATE(Baz, HAS_m_TEMPLATE_PARAMS(...), AND_2_VALUE_PARAMS(p1, p2))` | `Baz<t1, ..., t_m>(bool_value, int_value)` | `BazActionP2<t1, ..., t_m, bool, int>` | | `ACTION_TEMPLATE(Baz, HAS_m_TEMPLATE_PARAMS(...), AND_2_VALUE_PARAMS(p1, p2))` | `Baz<t1, ..., t_m>(bool_value, int_value)` | `BazActionP2<t1, ..., t_m, bool, int>` |
| ... | ... | ... | | ... | ... | ... |
<!-- mdformat on -->
Note that we have to pick different suffixes (`Action`, `ActionP`, `ActionP2`, Note that we have to pick different suffixes (`Action`, `ActionP`, `ActionP2`,
and etc) for actions with different numbers of value parameters, or the action and etc) for actions with different numbers of value parameters, or the action
......
...@@ -66,13 +66,11 @@ deprecated and refactored away. ...@@ -66,13 +66,11 @@ deprecated and refactored away.
So please be aware of the different definitions of the terms: So please be aware of the different definitions of the terms:
<!-- mdformat off(github rendering does not support multiline tables) -->
Meaning | googletest Term | [ISTQB](http://www.istqb.org/) Term Meaning | googletest Term | [ISTQB](http://www.istqb.org/) Term
:----------------------------------------------------------------------------------- | :---------------------- | :---------------------------------- :----------------------------------------------------------------------------------- | :---------------------- | :----------------------------------
Exercise a particular program path with specific input values and verify the results | [TEST()](#simple-tests) | [Test Case][istqb test case] Exercise a particular program path with specific input values and verify the results | [TEST()](#simple-tests) | [Test Case][istqb test case]
<!-- mdformat on -->
[istqb test case]: http://glossary.istqb.org/en/search/test%20case [istqb test case]: http://glossary.istqb.org/en/search/test%20case
[istqb test suite]: http://glossary.istqb.org/en/search/test%20suite [istqb test suite]: http://glossary.istqb.org/en/search/test%20suite
...@@ -218,7 +216,6 @@ as `ASSERT_EQ(expected, actual)`, so lots of existing code uses this order. Now ...@@ -218,7 +216,6 @@ as `ASSERT_EQ(expected, actual)`, so lots of existing code uses this order. Now
The assertions in this group compare two **C strings**. If you want to compare The assertions in this group compare two **C strings**. If you want to compare
two `string` objects, use `EXPECT_EQ`, `EXPECT_NE`, and etc instead. two `string` objects, use `EXPECT_EQ`, `EXPECT_NE`, and etc instead.
<!-- mdformat off(github rendering does not support multiline tables) -->
| Fatal assertion | Nonfatal assertion | Verifies | | Fatal assertion | Nonfatal assertion | Verifies |
| -------------------------- | ------------------------------ | -------------------------------------------------------- | | -------------------------- | ------------------------------ | -------------------------------------------------------- |
...@@ -227,7 +224,6 @@ two `string` objects, use `EXPECT_EQ`, `EXPECT_NE`, and etc instead. ...@@ -227,7 +224,6 @@ 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 -->
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*.
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment