diff options
| -rw-r--r-- | googlemock/README.md | 2 | ||||
| -rw-r--r-- | googletest/docs/AdvancedGuide.md | 8 | ||||
| -rw-r--r-- | googletest/docs/DevGuide.md | 37 | ||||
| -rw-r--r-- | googletest/docs/FAQ.md | 100 |
4 files changed, 67 insertions, 80 deletions
diff --git a/googlemock/README.md b/googlemock/README.md index 5456df6e..332beab3 100644 --- a/googlemock/README.md +++ b/googlemock/README.md @@ -78,7 +78,7 @@ posting a question on the Google Mock is not a testing framework itself. Instead, it needs a testing framework for writing tests. Google Mock works seamlessly -with [Google Test](http://code.google.com/p/googletest/), butj +with [Google Test](http://code.google.com/p/googletest/), but you can also use it with [any C++ testing framework](googlemock/ForDummies.md#Using_Google_Mock_with_Any_Testing_Framework). ### Requirements for End Users ### diff --git a/googletest/docs/AdvancedGuide.md b/googletest/docs/AdvancedGuide.md index 4d34ba5b..c24aa480 100644 --- a/googletest/docs/AdvancedGuide.md +++ b/googletest/docs/AdvancedGuide.md @@ -230,7 +230,7 @@ message is formatted: | **Fatal assertion** | **Nonfatal assertion** | **Verifies** | |:--------------------|:-----------------------|:-------------| -| `ASSERT_PRED_FORMAT1(`_pred\_format1, val1_`);` | `EXPECT_PRED_FORMAT1(`_pred\_format1, val1_`); | _pred\_format1(val1)_ is successful | +| `ASSERT_PRED_FORMAT1(`_pred\_format1, val1_`);` | `EXPECT_PRED_FORMAT1(`_pred\_format1, val1_`);` | _pred\_format1(val1)_ is successful | | `ASSERT_PRED_FORMAT2(`_pred\_format2, val1, val2_`);` | `EXPECT_PRED_FORMAT2(`_pred\_format2, val1, val2_`);` | _pred\_format2(val1, val2)_ is successful | | `...` | `...` | `...` | @@ -527,9 +527,9 @@ Google Test has the following macros to support death tests: | **Fatal assertion** | **Nonfatal assertion** | **Verifies** | |:--------------------|:-----------------------|:-------------| -| `ASSERT_DEATH(`_statement, regex_`); | `EXPECT_DEATH(`_statement, regex_`); | _statement_ crashes with the given error | -| `ASSERT_DEATH_IF_SUPPORTED(`_statement, regex_`); | `EXPECT_DEATH_IF_SUPPORTED(`_statement, regex_`); | if death tests are supported, verifies that _statement_ crashes with the given error; otherwise verifies nothing | -| `ASSERT_EXIT(`_statement, predicate, regex_`); | `EXPECT_EXIT(`_statement, predicate, regex_`); |_statement_ exits with the given error and its exit code matches _predicate_ | +| `ASSERT_DEATH(`_statement, regex_`);` | `EXPECT_DEATH(`_statement, regex_`);` | _statement_ crashes with the given error | +| `ASSERT_DEATH_IF_SUPPORTED(`_statement, regex_`);` | `EXPECT_DEATH_IF_SUPPORTED(`_statement, regex_`);` | if death tests are supported, verifies that _statement_ crashes with the given error; otherwise verifies nothing | +| `ASSERT_EXIT(`_statement, predicate, regex_`);` | `EXPECT_EXIT(`_statement, predicate, regex_`);` |_statement_ exits with the given error and its exit code matches _predicate_ | where _statement_ is a statement that is expected to cause the process to die, _predicate_ is a function or function object that evaluates an integer diff --git a/googletest/docs/DevGuide.md b/googletest/docs/DevGuide.md index 867770a6..06467a32 100644 --- a/googletest/docs/DevGuide.md +++ b/googletest/docs/DevGuide.md @@ -14,8 +14,8 @@ All Google Test source and pre-built packages are provided under the [New BSD Li ## The Google Test Community ## -The Google Test community exists primarily through the [discussion group](http://groups.google.com/group/googletestframework), the -[issue tracker](http://code.google.com/p/googletest/issues/list) and, to a lesser extent, the [source control repository](http://code.google.com/p/googletest/source/checkout). You are definitely encouraged to contribute to the +The Google Test community exists primarily through the [discussion group](http://groups.google.com/group/googletestframework) and the GitHub repository. +You are definitely encouraged to contribute to the discussion and you can also help us to keep the effectiveness of the group high by following and promoting the guidelines listed here. @@ -35,37 +35,27 @@ Sure, C++ testing is serious business and all that, but it's also a lot of fun. Let's keep it that way. Let's strive to be one of the friendliest communities in all of open source. -### Where to Discuss Google Test ### - -As always, discuss Google Test in the official [Google C++ Testing Framework discussion group](http://groups.google.com/group/googletestframework). You don't have to actually submit -code in order to sign up. Your participation itself is a valuable -contribution. +As always, discuss Google Test in the official GoogleTest discussion group. +You don't have to actually submit code in order to sign up. Your participation +itself is a valuable contribution. # Working with the Code # If you want to get your hands dirty with the code inside Google Test, this is the section for you. -## Checking Out the Source from Subversion ## - -Checking out the Google Test source is most useful if you plan to -tweak it yourself. You check out the source for Google Test using a -[Subversion](http://subversion.tigris.org/) client as you would for any -other project hosted on Google Code. Please see the instruction on -the [source code access page](http://code.google.com/p/googletest/source/checkout) for how to do it. - ## Compiling from Source ## Once you check out the code, you can find instructions on how to -compile it in the [README](http://code.google.com/p/googletest/source/browse/trunk/README) file. +compile it in the [README](../README.md) file. ## Testing ## A testing framework is of no good if itself is not thoroughly tested. Tests should be written for any new code, and changes should be verified to not break existing tests before they are submitted for -review. To perform the tests, follow the instructions in [README](http://code.google.com/p/googletest/source/browse/trunk/README) and -verify that there are no failures. +review. To perform the tests, follow the instructions in +[README](../README.md) and verify that there are no failures. # Contributing Code # @@ -104,14 +94,12 @@ can read the PumpManual for details. Please do submit code. Here's what you need to do: - 1. Normally you should make your change against the SVN trunk instead of a branch or a tag, as the latter two are for release control and should be treated mostly as read-only. - 1. Decide which code you want to submit. A submission should be a set of changes that addresses one issue in the [Google Test issue tracker](http://code.google.com/p/googletest/issues/list). Please don't mix more than one logical change per submittal, because it makes the history hard to follow. If you want to make a change that doesn't have a corresponding issue in the issue tracker, please create one. + 1. A submission should be a set of changes that addresses one issue in the [issue tracker](https://github.com/google/googletest/issues). Please don't mix more than one logical change per submittal, because it makes the history hard to follow. If you want to make a change that doesn't have a corresponding issue in the issue tracker, please create one. 1. Also, coordinate with team members that are listed on the issue in question. This ensures that work isn't being duplicated and communicating your plan early also generally leads to better patches. 1. Ensure that your code adheres to the [Google Test source code style](#Coding_Style.md). 1. Ensure that there are unit tests for your code. 1. Sign a Contributor License Agreement. - 1. Create a patch file using `svn diff`. - 1. We use [Rietveld](http://codereview.appspot.com/) to do web-based code reviews. You can read about the tool [here](http://code.google.com/p/rietveld/wiki/CodeReviewHelp). When you are ready, upload your patch via Rietveld and notify `googletestframework@googlegroups.com` to review it. There are several ways to upload the patch. We recommend using the [upload\_gtest.py](http://code.google.com/p/googletest/source/browse/trunk/scripts/upload_gtest.py) script, which you can find in the `scripts/` folder in the SVN trunk. + 1. Create a Pull Request in the usual way. ## Google Test Committers ## @@ -125,7 +113,7 @@ Test. # Release Process # -We follow the typical release process for Subversion-based projects: +We follow a typical release process: 1. A release branch named `release-X.Y` is created. 1. Bugs are fixed and features are added in trunk; those individual patches are merged into the release branch until it's stable. @@ -133,7 +121,6 @@ We follow the typical release process for Subversion-based projects: 1. Repeat steps 2 and 3 throughout one release cycle (as determined by features or time). 1. Go back to step 1 to create another release branch and so on. - --- -This page is based on the [Making GWT Better](http://code.google.com/webtoolkit/makinggwtbetter.html) guide from the [Google Web Toolkit](http://code.google.com/webtoolkit/) project. Except as otherwise [noted](http://code.google.com/policies.html#restrictions), the content of this page is licensed under the [Creative Commons Attribution 2.5 License](http://creativecommons.org/licenses/by/2.5/).
\ No newline at end of file +This page is based on the [Making GWT Better](http://code.google.com/webtoolkit/makinggwtbetter.html) guide from the [Google Web Toolkit](http://code.google.com/webtoolkit/) project. Except as otherwise [noted](http://code.google.com/policies.html#restrictions), the content of this page is licensed under the [Creative Commons Attribution 2.5 License](http://creativecommons.org/licenses/by/2.5/). diff --git a/googletest/docs/FAQ.md b/googletest/docs/FAQ.md index ccbd97bd..7f6ff4c1 100644 --- a/googletest/docs/FAQ.md +++ b/googletest/docs/FAQ.md @@ -28,11 +28,11 @@ list can help you decide whether it is for you too. * `SCOPED_TRACE` helps you understand the context of an assertion failure when it comes from inside a sub-routine or loop. * You can decide which tests to run using name patterns. This saves time when you want to quickly reproduce a test failure. * Google Test can generate XML test result reports that can be parsed by popular continuous build system like Hudson. - * Simple things are easy in Google Test, while hard things are possible: in addition to advanced features like [global test environments](http://code.google.com/p/googletest/wiki/AdvancedGuide#Global_Set-Up_and_Tear-Down) and tests parameterized by [values](http://code.google.com/p/googletest/wiki/AdvancedGuide#Value_Parameterized_Tests) or [types](http://code.google.com/p/googletest/wiki/AdvancedGuide#Typed_Tests), Google Test supports various ways for the user to extend the framework -- if Google Test doesn't do something out of the box, chances are that a user can implement the feature using Google Test's public API, without changing Google Test itself. In particular, you can: - * expand your testing vocabulary by defining [custom predicates](http://code.google.com/p/googletest/wiki/AdvancedGuide#Predicate_Assertions_for_Better_Error_Messages), - * teach Google Test how to [print your types](http://code.google.com/p/googletest/wiki/AdvancedGuide#Teaching_Google_Test_How_to_Print_Your_Values), - * define your own testing macros or utilities and verify them using Google Test's [Service Provider Interface](http://code.google.com/p/googletest/wiki/AdvancedGuide#Catching_Failures), and - * reflect on the test cases or change the test output format by intercepting the [test events](http://code.google.com/p/googletest/wiki/AdvancedGuide#Extending_Google_Test_by_Handling_Test_Events). + * Simple things are easy in Google Test, while hard things are possible: in addition to advanced features like [global test environments](https://github.com/google/googletest/blob/master/googletest/docs/AdvancedGuide.md#global-set-up-and-tear-down) and tests parameterized by [values](https://github.com/google/googletest/blob/master/googletest/docs/AdvancedGuide.md#value-parameterized-tests) or [types](https://github.com/google/googletest/blob/master/googletest/docs/AdvancedGuide.md#typed-tests), Google Test supports various ways for the user to extend the framework -- if Google Test doesn't do something out of the box, chances are that a user can implement the feature using Google Test's public API, without changing Google Test itself. In particular, you can: + * expand your testing vocabulary by defining [custom predicates](https://github.com/google/googletest/blob/master/googletest/docs/AdvancedGuide.md#predicate-assertions-for-better-error-messages), + * teach Google Test how to [print your types](https://github.com/google/googletest/blob/master/googletest/docs/AdvancedGuide.md#teaching-google-test-how-to-print-your-values), + * define your own testing macros or utilities and verify them using Google Test's [Service Provider Interface](https://github.com/google/googletest/blob/master/googletest/docs/AdvancedGuide.md#catching-failures), and + * reflect on the test cases or change the test output format by intercepting the [test events](https://github.com/google/googletest/blob/master/googletest/docs/AdvancedGuide.md#extending-google-test-by-handling-test-events). ## I'm getting warnings when compiling Google Test. Would you fix them? ## @@ -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 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 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 class FooTest : public ::testing::Test {}; TEST_F(FooTest, DoesThis) { ... } ``` or -``` +``` cpp 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 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 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 // 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 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 // Defines a base test fixture. class BaseTest : public ::testing::Test { protected: @@ -409,7 +409,7 @@ If necessary, you can continue to derive test fixtures from a derived fixture. Google Test has no limit on how deep the hierarchy can be. For a complete example using derived test fixtures, see -[sample5](http://code.google.com/p/googletest/source/browse/trunk/samples/sample5_unittest.cc). +[sample5](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? ## @@ -476,7 +476,7 @@ explicitly telling the compiler which version to pick. For example, suppose you have -``` +``` cpp 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 EXPECT_PRED1(IsPositive, 5); ``` However, this will work: -``` +``` cpp 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 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 ASSERT_PRED1(IsNegative*<int>*, -5); ``` Things are more interesting if your template has more than one parameters. The following won't compile: -``` +``` cpp 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 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 return RUN_ALL_TESTS(); ``` they write -``` +``` cpp 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 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 class FooTest : public BaseTest {}; TEST_F(FooTest, Abc) { ... } @@ -604,7 +604,7 @@ TEST_F(BarTest, Def) { ... } ``` you can simply `typedef` the test fixtures: -``` +``` cpp 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 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 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 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 // foo.h class Foo { ... @@ -733,7 +733,7 @@ EXPECT_TRUE(Foo::Func(12345)); ``` You probably should better write: -``` +``` cpp // 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 // File foo_unittest.cc // The headers section @@ -803,8 +803,9 @@ reference global and/or local variables, and can be: * a complex expression, or * a compound statement. -> Some examples are shown here: -``` +Some examples are shown here: + +``` cpp // A death test can be a simple function call. TEST(MyDeathTest, FunctionCall) { ASSERT_DEATH(Xyz(5), "Xyz failed"); @@ -883,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 TEST_F(FooTest, AbcDeathTest) { ... } TEST_F(FooTest, Uvw) { ... } @@ -902,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 class FooTest : public ::testing::Test { ... }; TEST_F(FooTest, Abc) { ... } @@ -955,13 +956,12 @@ using gtest-md.vcproj instead of gtest.vcproj. ## I put my tests in a library and Google Test doesn't run them. What's happening? ## Have you read a -[warning](http://code.google.com/p/googletest/wiki/Primer#Important_note_for_Visual_C++_users) on +[warning](https://github.com/google/googletest/blob/master/googletest/docs/Primer.md#important-note-for-visual-c-users) on the Google Test Primer page? ## I want to use Google Test with Visual Studio but don't know where to start. ## Many people are in your position and one of the posted his solution to -our mailing list. Here is his link: -http://hassanjamilahmad.blogspot.com/2009/07/gtest-starters-help.html. +our mailing list. ## I am seeing compile errors mentioning std::type\_traits when I try to use Google Test on Solaris. ## Google Test uses parts of the standard C++ library that SunStudio does not support. @@ -1006,11 +1006,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 GTEST_TEST(SomeTest, DoesThis) { ... } ``` instead of -``` +``` cpp TEST(SomeTest, DoesThis) { ... } ``` in order to define a test. @@ -1024,7 +1024,7 @@ Yes. The rule is **all test methods in the same test case must use the same fixture class**. This means that the following is **allowed** because both tests use the same fixture class (`::testing::Test`). -``` +``` cpp namespace foo { TEST(CoolTest, DoSomething) { SUCCEED(); @@ -1040,7 +1040,7 @@ TEST(CoolTest, DoSomething) { However, the following code is **not allowed** and will produce a runtime error from Google Test because the test methods are using different test fixture classes with the same test case name. -``` +``` cpp namespace foo { class CoolTest : public ::testing::Test {}; // Fixture foo::CoolTest TEST_F(CoolTest, DoSomething) { @@ -1059,19 +1059,19 @@ TEST_F(CoolTest, DoSomething) { ## How do I build Google Testing Framework with Xcode 4? ## If you try to build Google Test's Xcode project with Xcode 4.0 or later, you may encounter an error message that looks like -"Missing SDK in target gtest\_framework: /Developer/SDKs/MacOSX10.4u.sdk". That means that Xcode does not support the SDK the project is targeting. See the Xcode section in the [README](http://code.google.com/p/googletest/source/browse/trunk/README) file on how to resolve this. +"Missing SDK in target gtest\_framework: /Developer/SDKs/MacOSX10.4u.sdk". That means that Xcode does not support the SDK the project is targeting. See the Xcode section in the [README](https://github.com/google/googletest/blob/master/googletest/README.md) file on how to resolve this. ## My question is not covered in your FAQ! ## If you cannot find the answer to your question in this FAQ, there are some other resources you can use: - 1. read other [wiki pages](http://code.google.com/p/googletest/w/list), - 1. search the mailing list [archive](http://groups.google.com/group/googletestframework/topics), + 1. read other [wiki pages](https://github.com/google/googletest/tree/master/googletest/docs), + 1. search the mailing list [archive](https://groups.google.com/forum/#!forum/googletestframework), 1. ask it on [googletestframework@googlegroups.com](mailto:googletestframework@googlegroups.com) and someone will answer it (to prevent spam, we require you to join the [discussion group](http://groups.google.com/group/googletestframework) before you can post.). Please note that creating an issue in the -[issue tracker](http://code.google.com/p/googletest/issues/list) is _not_ +[issue tracker](https://github.com/google/googletest/issues) is _not_ a good way to get your answer, as it is monitored infrequently by a very small number of people. @@ -1079,9 +1079,9 @@ When asking a question, it's helpful to provide as much of the following information as possible (people cannot help you if there's not enough information in your question): - * the version (or the revision number if you check out from SVN directly) of Google Test you use (Google Test is under active development, so it's possible that your problem has been solved in a later version), + * the version (or the commit hash if you check out from Git directly) of Google Test you use (Google Test is under active development, so it's possible that your problem has been solved in a later version), * your operating system, * the name and version of your compiler, * the complete command line flags you give to your compiler, * the complete compiler error messages (if the question is about compilation), - * the _actual_ code (ideally, a minimal but complete program) that has the problem you encounter.
\ No newline at end of file + * the _actual_ code (ideally, a minimal but complete program) that has the problem you encounter. |