diff options
| -rw-r--r-- | googlemock/docs/ForDummies.md | 2 | ||||
| -rw-r--r-- | googlemock/docs/v1_5/ForDummies.md | 2 | ||||
| -rw-r--r-- | googlemock/docs/v1_6/ForDummies.md | 2 | ||||
| -rw-r--r-- | googlemock/docs/v1_7/ForDummies.md | 2 | ||||
| -rw-r--r-- | googletest/README.md | 2 | ||||
| -rw-r--r-- | googletest/docs/AdvancedGuide.md | 6 | ||||
| -rw-r--r-- | googletest/docs/FAQ.md | 2 | ||||
| -rw-r--r-- | googletest/docs/V1_5_AdvancedGuide.md | 4 | ||||
| -rw-r--r-- | googletest/docs/V1_6_AdvancedGuide.md | 4 | ||||
| -rw-r--r-- | googletest/docs/V1_6_FAQ.md | 2 | ||||
| -rw-r--r-- | googletest/docs/V1_7_AdvancedGuide.md | 4 | ||||
| -rw-r--r-- | googletest/docs/V1_7_FAQ.md | 2 |
12 files changed, 17 insertions, 17 deletions
diff --git a/googlemock/docs/ForDummies.md b/googlemock/docs/ForDummies.md index e2f362a..0da4cbe 100644 --- a/googlemock/docs/ForDummies.md +++ b/googlemock/docs/ForDummies.md @@ -44,7 +44,7 @@ We encourage you to use Google Mock as: * a _testing_ tool to cut your tests' outbound dependencies and probe the interaction between your module and its collaborators. # Getting Started # -Using Google Mock is easy! Inside your C++ source file, just #include `"gtest/gtest.h"` and `"gmock/gmock.h"`, and you are ready to go. +Using Google Mock is easy! Inside your C++ source file, just `#include` `"gtest/gtest.h"` and `"gmock/gmock.h"`, and you are ready to go. # A Case for Mock Turtles # Let's look at an example. Suppose you are developing a graphics program that relies on a LOGO-like API for drawing. How would you test that it does the right thing? Well, you can run it and compare the screen with a golden screen snapshot, but let's admit it: tests like this are expensive to run and fragile (What if you just upgraded to a shiny new graphics card that has better anti-aliasing? Suddenly you have to update all your golden images.). It would be too painful if all your tests are like this. Fortunately, you learned about Dependency Injection and know the right thing to do: instead of having your application talk to the drawing API directly, wrap the API in an interface (say, `Turtle`) and code to that interface: diff --git a/googlemock/docs/v1_5/ForDummies.md b/googlemock/docs/v1_5/ForDummies.md index f389606..fcc3b56 100644 --- a/googlemock/docs/v1_5/ForDummies.md +++ b/googlemock/docs/v1_5/ForDummies.md @@ -44,7 +44,7 @@ We encourage you to use Google Mock as: * a _testing_ tool to cut your tests' outbound dependencies and probe the interaction between your module and its collaborators. # Getting Started # -Using Google Mock is easy! Inside your C++ source file, just #include `<gtest/gtest.h>` and `<gmock/gmock.h>`, and you are ready to go. +Using Google Mock is easy! Inside your C++ source file, just `#include` `<gtest/gtest.h>` and `<gmock/gmock.h>`, and you are ready to go. # A Case for Mock Turtles # Let's look at an example. Suppose you are developing a graphics program that relies on a LOGO-like API for drawing. How would you test that it does the right thing? Well, you can run it and compare the screen with a golden screen snapshot, but let's admit it: tests like this are expensive to run and fragile (What if you just upgraded to a shiny new graphics card that has better anti-aliasing? Suddenly you have to update all your golden images.). It would be too painful if all your tests are like this. Fortunately, you learned about Dependency Injection and know the right thing to do: instead of having your application talk to the drawing API directly, wrap the API in an interface (say, `Turtle`) and code to that interface: diff --git a/googlemock/docs/v1_6/ForDummies.md b/googlemock/docs/v1_6/ForDummies.md index 0891b8c..19ee63a 100644 --- a/googlemock/docs/v1_6/ForDummies.md +++ b/googlemock/docs/v1_6/ForDummies.md @@ -44,7 +44,7 @@ We encourage you to use Google Mock as: * a _testing_ tool to cut your tests' outbound dependencies and probe the interaction between your module and its collaborators. # Getting Started # -Using Google Mock is easy! Inside your C++ source file, just #include `"gtest/gtest.h"` and `"gmock/gmock.h"`, and you are ready to go. +Using Google Mock is easy! Inside your C++ source file, just `#include` `"gtest/gtest.h"` and `"gmock/gmock.h"`, and you are ready to go. # A Case for Mock Turtles # Let's look at an example. Suppose you are developing a graphics program that relies on a LOGO-like API for drawing. How would you test that it does the right thing? Well, you can run it and compare the screen with a golden screen snapshot, but let's admit it: tests like this are expensive to run and fragile (What if you just upgraded to a shiny new graphics card that has better anti-aliasing? Suddenly you have to update all your golden images.). It would be too painful if all your tests are like this. Fortunately, you learned about Dependency Injection and know the right thing to do: instead of having your application talk to the drawing API directly, wrap the API in an interface (say, `Turtle`) and code to that interface: diff --git a/googlemock/docs/v1_7/ForDummies.md b/googlemock/docs/v1_7/ForDummies.md index 2ed4300..ee03c5b 100644 --- a/googlemock/docs/v1_7/ForDummies.md +++ b/googlemock/docs/v1_7/ForDummies.md @@ -44,7 +44,7 @@ We encourage you to use Google Mock as: * a _testing_ tool to cut your tests' outbound dependencies and probe the interaction between your module and its collaborators. # Getting Started # -Using Google Mock is easy! Inside your C++ source file, just #include `"gtest/gtest.h"` and `"gmock/gmock.h"`, and you are ready to go. +Using Google Mock is easy! Inside your C++ source file, just `#include` `"gtest/gtest.h"` and `"gmock/gmock.h"`, and you are ready to go. # A Case for Mock Turtles # Let's look at an example. Suppose you are developing a graphics program that relies on a LOGO-like API for drawing. How would you test that it does the right thing? Well, you can run it and compare the screen with a golden screen snapshot, but let's admit it: tests like this are expensive to run and fragile (What if you just upgraded to a shiny new graphics card that has better anti-aliasing? Suddenly you have to update all your golden images.). It would be too painful if all your tests are like this. Fortunately, you learned about Dependency Injection and know the right thing to do: instead of having your application talk to the drawing API directly, wrap the API in an interface (say, `Turtle`) and code to that interface: diff --git a/googletest/README.md b/googletest/README.md index e0ea1b0..edd4408 100644 --- a/googletest/README.md +++ b/googletest/README.md @@ -221,7 +221,7 @@ your build script. ### Avoiding Macro Name Clashes ### In C++, macros don't obey namespaces. Therefore two libraries that -both define a macro of the same name will clash if you #include both +both define a macro of the same name will clash if you `#include` both definitions. In case a Google Test macro clashes with another library, you can force Google Test to rename its macro to avoid the conflict. diff --git a/googletest/docs/AdvancedGuide.md b/googletest/docs/AdvancedGuide.md index 4c4ecb5..7ba8d12 100644 --- a/googletest/docs/AdvancedGuide.md +++ b/googletest/docs/AdvancedGuide.md @@ -1450,7 +1450,7 @@ two cases to consider: Both static functions and definitions/declarations in an unnamed namespace are only visible within the same translation unit. To test them, you can `#include` -the entire `.cc` file being tested in your `*_test.cc` file. (#including `.cc` +the entire `.cc` file being tested in your `*_test.cc` file. (`#include`ing `.cc` files is not a good way to reuse code - you should not do this in production code!) @@ -1551,8 +1551,8 @@ exception, you could catch the exception and assert on it. But Google Test doesn't use exceptions, so how do we test that a piece of code generates an expected failure? -`"gtest/gtest-spi.h"` contains some constructs to do this. After -#including this header, you can use +`"gtest/gtest-spi.h"` contains some constructs to do this. After +`#include`ing this header, you can use | `EXPECT_FATAL_FAILURE(`_statement, substring_`);` | |:--------------------------------------------------| diff --git a/googletest/docs/FAQ.md b/googletest/docs/FAQ.md index 639c250..5fd6cb7 100644 --- a/googletest/docs/FAQ.md +++ b/googletest/docs/FAQ.md @@ -994,7 +994,7 @@ you can use the _horrible_ hack of sniffing your executable name ## Google Test defines a macro that clashes with one defined by another library. How do I deal with that? ## In C++, macros don't obey namespaces. Therefore two libraries that -both define a macro of the same name will clash if you #include both +both define a macro of the same name will clash if you `#include` both definitions. In case a Google Test macro clashes with another library, you can force Google Test to rename its macro to avoid the conflict. diff --git a/googletest/docs/V1_5_AdvancedGuide.md b/googletest/docs/V1_5_AdvancedGuide.md index 9511f22..34e19c2 100644 --- a/googletest/docs/V1_5_AdvancedGuide.md +++ b/googletest/docs/V1_5_AdvancedGuide.md @@ -1365,7 +1365,7 @@ two cases to consider: Both static functions and definitions/declarations in an unnamed namespace are only visible within the same translation unit. To test them, you can `#include` -the entire `.cc` file being tested in your `*_test.cc` file. (#including `.cc` +the entire `.cc` file being tested in your `*_test.cc` file. (`#include`ing `.cc` files is not a good way to reuse code - you should not do this in production code!) @@ -1467,7 +1467,7 @@ Test doesn't use exceptions, so how do we test that a piece of code generates an expected failure? `<gtest/gtest-spi.h>` contains some constructs to do this. After -#including this header, you can use +`#include`ing this header, you can use | `EXPECT_FATAL_FAILURE(`_statement, substring_`);` | |:--------------------------------------------------| diff --git a/googletest/docs/V1_6_AdvancedGuide.md b/googletest/docs/V1_6_AdvancedGuide.md index 5225341..78864b1 100644 --- a/googletest/docs/V1_6_AdvancedGuide.md +++ b/googletest/docs/V1_6_AdvancedGuide.md @@ -1447,7 +1447,7 @@ two cases to consider: Both static functions and definitions/declarations in an unnamed namespace are only visible within the same translation unit. To test them, you can `#include` -the entire `.cc` file being tested in your `*_test.cc` file. (#including `.cc` +the entire `.cc` file being tested in your `*_test.cc` file. (`#include`ing `.cc` files is not a good way to reuse code - you should not do this in production code!) @@ -1549,7 +1549,7 @@ Test doesn't use exceptions, so how do we test that a piece of code generates an expected failure? `"gtest/gtest-spi.h"` contains some constructs to do this. After -#including this header, you can use +`#include`ing this header, you can use | `EXPECT_FATAL_FAILURE(`_statement, substring_`);` | |:--------------------------------------------------| diff --git a/googletest/docs/V1_6_FAQ.md b/googletest/docs/V1_6_FAQ.md index 6d5d128..2b7f784 100644 --- a/googletest/docs/V1_6_FAQ.md +++ b/googletest/docs/V1_6_FAQ.md @@ -989,7 +989,7 @@ you can use the _horrible_ hack of sniffing your executable name ## Google Test defines a macro that clashes with one defined by another library. How do I deal with that? ## In C++, macros don't obey namespaces. Therefore two libraries that -both define a macro of the same name will clash if you #include both +both define a macro of the same name will clash if you `#include` both definitions. In case a Google Test macro clashes with another library, you can force Google Test to rename its macro to avoid the conflict. diff --git a/googletest/docs/V1_7_AdvancedGuide.md b/googletest/docs/V1_7_AdvancedGuide.md index 83a8f79..dd4af8f 100644 --- a/googletest/docs/V1_7_AdvancedGuide.md +++ b/googletest/docs/V1_7_AdvancedGuide.md @@ -1448,7 +1448,7 @@ two cases to consider: Both static functions and definitions/declarations in an unnamed namespace are only visible within the same translation unit. To test them, you can `#include` -the entire `.cc` file being tested in your `*_test.cc` file. (#including `.cc` +the entire `.cc` file being tested in your `*_test.cc` file. (`#include`ing `.cc` files is not a good way to reuse code - you should not do this in production code!) @@ -1550,7 +1550,7 @@ Test doesn't use exceptions, so how do we test that a piece of code generates an expected failure? `"gtest/gtest-spi.h"` contains some constructs to do this. After -#including this header, you can use +`#include`ing this header, you can use | `EXPECT_FATAL_FAILURE(`_statement, substring_`);` | |:--------------------------------------------------| diff --git a/googletest/docs/V1_7_FAQ.md b/googletest/docs/V1_7_FAQ.md index ded1a48..3dd914d 100644 --- a/googletest/docs/V1_7_FAQ.md +++ b/googletest/docs/V1_7_FAQ.md @@ -989,7 +989,7 @@ you can use the _horrible_ hack of sniffing your executable name ## Google Test defines a macro that clashes with one defined by another library. How do I deal with that? ## In C++, macros don't obey namespaces. Therefore two libraries that -both define a macro of the same name will clash if you #include both +both define a macro of the same name will clash if you `#include` both definitions. In case a Google Test macro clashes with another library, you can force Google Test to rename its macro to avoid the conflict. |