diff --git a/googlemock/docs/ForDummies.md b/googlemock/docs/ForDummies.md index e2f362a6dc886b596b6dcc32211973f6418ea281..0da4cbe27b8d141aa308334ba6532d53182e74b1 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 f389606cbecc868b1f29f478714fa6d7a3384c39..fcc3b56174703154b9dd1d05149a5f10ca73972a 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 0891b8c4066541d3d8357c19028129a33fa8b94d..19ee63ab0c287910e1643140f77d5ac299c6abf8 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 2ed4300762731f2e6fdaebc2067fedd3fc126f52..ee03c5b98908f0aab093f53f6fbe09ac4b674c8d 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 e0ea1b0f37130bdb1fe3c99f996f5f4ae85d5cfc..edd4408054b32496aa0b437c02645232457590e6 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 4c4ecb5c30f9b46c4219acdcb2875bc1c899c68c..7ba8d1219bd014a138b8d7fd6a904980b3880296 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 639c2509aabb265111039914d12a2f44d2700a00..5fd6cb7238a19b7a71a4a95a63be93e1921452d6 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 9511f226ed2218281ecd17a21c66ce450ba47558..34e19c26fdff219a5d83959f75d316189510b045 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 5225341aa0429931f45233a1ba1b62f8ba61a5eb..78864b1667c1c40733009d1a170cc1abb1008789 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 6d5d128ab7ff9219c98904614c676ae1287b86bb..2b7f78407722e1e5e7a86c6713598e579607b781 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 83a8f798108379459e77e7e39bb9c6854f8a2a64..dd4af8f366aa6aca81440dbd6659b54beae3199f 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 ded1a48bff7b6953b276e9fce8c1596db734451a..3dd914dcf16ae34208e0908d16cb9332413206f0 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.