diff --git a/docs/advanced.md b/docs/advanced.md index 91a4ec137a..16280be1d3 100644 --- a/docs/advanced.md +++ b/docs/advanced.md @@ -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 | | `...` | `...` | `...` | - + 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 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_DOUBLE_EQ(val1, val2);` | `EXPECT_DOUBLE_EQ(val1, val2);` | the two `double` values are almost equal | - + 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 | - + #### Floating-Point Predicate-Format Functions @@ -379,7 +379,7 @@ macros: | ------------------------------ | ------------------------------ | --------------------- | | `ASSERT_THAT(value, matcher);` | `EXPECT_THAT(value, matcher);` | value matches matcher | - + For example, `StartsWith(prefix)` is a matcher that matches a string starting with `prefix`, and you can write: @@ -1365,7 +1365,7 @@ namespace: | `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. | - + 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 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` -and/or `grep`. This number can be used as a metric for improving your test -quality. +TIP: You can easily count the number of disabled tests you have using +`grep`. This number can be used as a metric for +improving your test quality. #### Temporarily Enabling Disabled Tests diff --git a/docs/gmock_for_dummies.md b/docs/gmock_for_dummies.md index 1e5f966db3..6dca904e09 100644 --- a/docs/gmock_for_dummies.md +++ b/docs/gmock_for_dummies.md @@ -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 many times? with what arguments? what will they return? etc). -**Note:** It is easy to confuse the term *fake objects* with mock objects. Fakes -and mocks actually mean very different things in the Test-Driven Development -(TDD) community: +It is easy to confuse the term *fake objects* with mock objects. Fakes and mocks +actually mean very different things in the Test-Driven Development (TDD) +community: * **Fake** objects have working implementations, but usually take some 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. 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 -a result, mocking is a proven effective technique and widely adopted practice in -those communities. Having the right tool absolutely makes the difference. +EasyMock, etc), which automate the creation of mocks. As a result, mocking is a +proven effective technique and widely adopted practice in those communities. +Having the right tool absolutely makes the difference. 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 @@ -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). **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 failed expectation in messages, making debugging easier. diff --git a/docs/primer.md b/docs/primer.md index 2f459fd7fd..c4f7a33eff 100644 --- a/docs/primer.md +++ b/docs/primer.md @@ -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_STRCASENE(str1,str2);` | `EXPECT_STRCASENE(str1,str2);` | the two C strings have different contents, ignoring case | - + Note that "CASE" in an assertion name means that case is ignored. A `NULL` pointer and an empty string are considered *different*.