diff options
Diffstat (limited to 'googletest')
| -rw-r--r-- | googletest/docs/faq.md | 64 |
1 files changed, 32 insertions, 32 deletions
diff --git a/googletest/docs/faq.md b/googletest/docs/faq.md index 30c64e3..1e2c341 100644 --- a/googletest/docs/faq.md +++ b/googletest/docs/faq.md @@ -76,7 +76,7 @@ for simplicity we just say that it cannot start with `_`.). It may seem fine for `TestCaseName` and `TestName` to contain `_` in the middle. However, consider this: -``` cpp +```c++ TEST(Time, Flies_Like_An_Arrow) { ... } TEST(Time_Flies, Like_An_Arrow) { ... } ``` @@ -242,7 +242,7 @@ of this approach: 1. Throwing in a destructor is undefined behavior in C++. Not using exceptions means Google Test's assertions are safe to use in destructors. 1. The `EXPECT_*` family of macros will continue even after a failure, allowing multiple failures in a `TEST` to be reported in a single run. This is a popular feature, as in C++ the edit-compile-test cycle is usually quite long and being able to fixing more than one thing at a time is a blessing. 1. If assertions are implemented using exceptions, a test may falsely ignore a failure if it's caught by user code: -``` cpp +```c++ try { ... ASSERT_TRUE(...) ... } catch (...) { ... } ``` @@ -259,13 +259,13 @@ macro for both cases. One possibility is to provide only one macro for tests with fixtures, and require the user to define an empty fixture sometimes: -``` cpp +```c++ class FooTest : public ::testing::Test {}; TEST_F(FooTest, DoesThis) { ... } ``` or -``` cpp +```c++ typedef ::testing::Test FooTest; TEST_F(FooTest, DoesThat) { ... } @@ -293,7 +293,7 @@ possibly allows. In particular: * The runner-style requires to split the information into two pieces: the definition of the death test itself, and the specification for the runner on how to run the death test and what to expect. The death test would be written in C++, while the runner spec may or may not be. A user needs to carefully keep the two in sync. `ASSERT_DEATH(statement, expected_message)` specifies all necessary information in one place, in one language, without boilerplate code. It is very declarative. * `ASSERT_DEATH` has a similar syntax and error-reporting semantics as other Google Test assertions, and thus is easy to learn. * `ASSERT_DEATH` can be mixed with other assertions and other logic at your will. You are not limited to one death test per test method. For example, you can write something like: -``` cpp +```c++ if (FooCondition()) { ASSERT_DEATH(Bar(), "blah"); } else { @@ -302,7 +302,7 @@ possibly allows. In particular: ``` If you prefer one death test per test method, you can write your tests in that style too, but we don't want to impose that on the users. The fewer artificial limitations the better. * `ASSERT_DEATH` can reference local variables in the current function, and you can decide how many death tests you want based on run-time information. For example, -``` cpp +```c++ const int count = GetCount(); // Only known at run time. for (int i = 1; i <= count; i++) { ASSERT_DEATH({ @@ -335,7 +335,7 @@ as running in a parallel universe, more or less. If your class has a static data member: -``` cpp +```c++ // foo.h class Foo { ... @@ -345,7 +345,7 @@ class Foo { You also need to define it _outside_ of the class body in `foo.cc`: -``` cpp +```c++ const int Foo::kBar; // No initializer here. ``` @@ -376,7 +376,7 @@ to write tests using each derived fixture. Typically, your code looks like this: -``` cpp +```c++ // Defines a base test fixture. class BaseTest : public ::testing::Test { protected: @@ -476,7 +476,7 @@ explicitly telling the compiler which version to pick. For example, suppose you have -``` cpp +```c++ bool IsPositive(int n) { return n > 0; } @@ -487,13 +487,13 @@ bool IsPositive(double x) { you will get a compiler error if you write -``` cpp +```c++ EXPECT_PRED1(IsPositive, 5); ``` However, this will work: -``` cpp +```c++ EXPECT_PRED1(static_cast<bool (*)(int)>(IsPositive), 5); ``` @@ -502,7 +502,7 @@ type of the function pointer for the `int`-version of `IsPositive()`.) As another example, when you have a template function -``` cpp +```c++ template <typename T> bool IsNegative(T x) { return x < 0; @@ -511,14 +511,14 @@ bool IsNegative(T x) { you can use it in a predicate assertion like this: -``` cpp +```c++ ASSERT_PRED1(IsNegative<int>, -5); ``` Things are more interesting if your template has more than one parameters. The following won't compile: -``` cpp +```c++ ASSERT_PRED2(GreaterThan<int, int>, 5, 0); ``` @@ -527,7 +527,7 @@ as the C++ pre-processor thinks you are giving `ASSERT_PRED2` 4 arguments, which is one more than expected. The workaround is to wrap the predicate function in parentheses: -``` cpp +```c++ ASSERT_PRED2((GreaterThan<int, int>), 5, 0); ``` @@ -537,13 +537,13 @@ ASSERT_PRED2((GreaterThan<int, int>), 5, 0); Some people had been ignoring the return value of `RUN_ALL_TESTS()`. That is, instead of -``` cpp +```c++ return RUN_ALL_TESTS(); ``` they write -``` cpp +```c++ RUN_ALL_TESTS(); ``` @@ -562,7 +562,7 @@ is used as the return value of `main()`. Due to a peculiarity of C++, in order to support the syntax for streaming messages to an `ASSERT_*`, e.g. -``` cpp +```c++ ASSERT_EQ(1, Foo()) << "blah blah" << foo; ``` @@ -591,7 +591,7 @@ the corresponding source code, or use `C-x `` to jump to the next failure. You don't have to. Instead of -``` cpp +```c++ class FooTest : public BaseTest {}; TEST_F(FooTest, Abc) { ... } @@ -604,7 +604,7 @@ TEST_F(BarTest, Def) { ... } ``` you can simply `typedef` the test fixtures: -``` cpp +```c++ typedef BaseTest FooTest; TEST_F(FooTest, Abc) { ... } @@ -646,7 +646,7 @@ members of the helper class public. You have several other options that don't require using `FRIEND_TEST`: * Write the tests as members of the fixture class: -``` cpp +```c++ class Foo { friend class FooTest; ... @@ -668,7 +668,7 @@ TEST_F(FooTest, Test2) { } ``` * In the fixture class, write accessors for the tested class' private members, then use the accessors in your tests: -``` cpp +```c++ class Foo { friend class FooTest; ... @@ -689,7 +689,7 @@ TEST_F(FooTest, Test1) { } ``` * If the methods are declared **protected**, you can change their access level in a test-only subclass: -``` cpp +```c++ class YourClass { ... protected: // protected access for testability. @@ -717,7 +717,7 @@ implementation details and ideally should be kept out of a .h. So often I make them free functions instead. Instead of: -``` cpp +```c++ // foo.h class Foo { ... @@ -733,7 +733,7 @@ EXPECT_TRUE(Foo::Func(12345)); ``` You probably should better write: -``` cpp +```c++ // foo.h class Foo { ... @@ -774,7 +774,7 @@ Then `foo.cc` can be easily tested. If you are adding tests to an existing file and don't want an intrusive change like this, there is a hack: just include the entire `foo.cc` file in your unit test. For example: -``` cpp +```c++ // File foo_unittest.cc // The headers section @@ -805,7 +805,7 @@ reference global and/or local variables, and can be: Some examples are shown here: -``` cpp +```c++ // A death test can be a simple function call. TEST(MyDeathTest, FunctionCall) { ASSERT_DEATH(Xyz(5), "Xyz failed"); @@ -884,7 +884,7 @@ inefficient and makes the semantics unclean. If we were to determine the order of tests based on test name instead of test case name, then we would have a problem with the following situation: -``` cpp +```c++ TEST_F(FooTest, AbcDeathTest) { ... } TEST_F(FooTest, Uvw) { ... } @@ -903,7 +903,7 @@ You don't have to, but if you like, you may split up the test case into `FooTest` and `FooDeathTest`, where the names make it clear that they are related: -``` cpp +```c++ class FooTest : public ::testing::Test { ... }; TEST_F(FooTest, Abc) { ... } @@ -1005,11 +1005,11 @@ Specifically, if both Google Test and some other code define macro ``` to the compiler flags to tell Google Test to change the macro's name from `FOO` to `GTEST_FOO`. For example, with `-DGTEST_DONT_DEFINE_TEST=1`, you'll need to write -``` cpp +```c++ GTEST_TEST(SomeTest, DoesThis) { ... } ``` instead of -``` cpp +```c++ TEST(SomeTest, DoesThis) { ... } ``` in order to define a test. |