diff options
36 files changed, 382 insertions, 336 deletions
diff --git a/.travis.yml b/.travis.yml index 90002648..3204dfac 100644 --- a/.travis.yml +++ b/.travis.yml @@ -2,29 +2,29 @@ # http://about.travis-ci.org/docs/user/build-configuration/ # This file can be validated on: # http://lint.travis-ci.org/ -# See also -# http://stackoverflow.com/questions/22111549/travis-ci-with-clang-3-4-and-c11/30925448#30925448 -# to allow C++11, though we are not yet building with -std=c++11 install: # /usr/bin/gcc is 4.6 always, but gcc-X.Y is available. - if [ "$CXX" = "g++" ]; then export CXX="g++-4.9" CC="gcc-4.9"; fi -# /usr/bin/clang is our version already, and clang-X.Y does not exist. -#- if [ "$CXX" = "clang++" ]; then export CXX="clang++-3.7" CC="clang-3.7"; fi +# /usr/bin/clang is 3.4, lets override with modern one. +- if [ "$CXX" = "clang++" ] && [ "$TRAVIS_OS_NAME" = "linux" ]; then export CXX="clang++-3.7" CC="clang-3.7"; fi - echo ${PATH} -- ls /usr/local -- ls /usr/local/bin -- export PATH=/usr/local/bin:/usr/bin:${PATH} - echo ${CXX} - ${CXX} --version +- ${CXX} -v addons: apt: + # List of whitelisted in travis packages for ubuntu-precise can be found here: + # https://github.com/travis-ci/apt-package-whitelist/blob/master/ubuntu-precise + # List of whitelisted in travis apt-sources: + # https://github.com/travis-ci/apt-source-whitelist/blob/master/ubuntu.json sources: - ubuntu-toolchain-r-test + - llvm-toolchain-precise-3.7 packages: - gcc-4.9 - g++-4.9 - - clang + - clang-3.7 - valgrind os: - linux diff --git a/CMakeLists.txt b/CMakeLists.txt new file mode 100644 index 00000000..8d2b552e --- /dev/null +++ b/CMakeLists.txt @@ -0,0 +1,16 @@ +cmake_minimum_required(VERSION 2.6.2) + +project( googletest-distribution ) + +enable_testing() + +option(BUILD_GTEST "Builds the googletest subproject" OFF) + +#Note that googlemock target already builds googletest +option(BUILD_GMOCK "Builds the googlemock subproject" ON) + +if(BUILD_GMOCK) + add_subdirectory( googlemock ) +elseif(BUILD_GTEST) + add_subdirectory( googletest ) +endif() @@ -53,7 +53,7 @@ the following notable projects: * The [Chromium projects](http://www.chromium.org/) (behind the Chrome browser and Chrome OS). * The [LLVM](http://llvm.org/) compiler. - * [Protocol Buffers](http://code.google.com/p/protobuf/), Google's data + * [Protocol Buffers](https://github.com/google/protobuf), Google's data interchange format. * The [OpenCV](http://opencv.org/) computer vision library. @@ -66,7 +66,7 @@ Test UI is written in C#. [GTest TAP Listener](https://github.com/kinow/gtest-tap-listener) is an event listener for Google Test that implements the -[TAP protocol](http://en.wikipedia.org/wiki/Test_Anything_Protocol) for test +[TAP protocol](https://en.wikipedia.org/wiki/Test_Anything_Protocol) for test result output. If your test runner understands TAP, you may find it useful. ## Requirements ## @@ -110,9 +110,9 @@ We welcome patches. If you plan to contribute a patch, you need to build Google Test and its own tests from a git checkout (described below), which has further requirements: - * [Python](http://python.org/) v2.3 or newer (for running some of + * [Python](https://www.python.org/) v2.3 or newer (for running some of the tests and re-generating certain source files from templates) - * [CMake](http://www.cmake.org/) v2.6.4 or newer + * [CMake](https://cmake.org/) v2.6.4 or newer ## Regenerating Source Files ## diff --git a/googlemock/CMakeLists.txt b/googlemock/CMakeLists.txt index cd522776..beb259a2 100644 --- a/googlemock/CMakeLists.txt +++ b/googlemock/CMakeLists.txt @@ -92,6 +92,22 @@ cxx_library(gmock_main src/gmock-all.cc src/gmock_main.cc) +# If the CMake version supports it, attach header directory information +# to the targets for when we are part of a parent build (ie being pulled +# in via add_subdirectory() rather than being a standalone build). +if (DEFINED CMAKE_VERSION AND NOT "${CMAKE_VERSION}" VERSION_LESS "2.8.11") + target_include_directories(gmock INTERFACE "${gmock_SOURCE_DIR}/include") + target_include_directories(gmock_main INTERFACE "${gmock_SOURCE_DIR}/include") +endif() + +######################################################################## +# +# Install rules +install(TARGETS gmock gmock_main + DESTINATION lib) +install(DIRECTORY ${gmock_SOURCE_DIR}/include/gmock + DESTINATION include) + ######################################################################## # # Google Mock's own tests. 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/googlemock/docs/CheatSheet.md b/googlemock/docs/CheatSheet.md index aef01b1f..ef4451b8 100644 --- a/googlemock/docs/CheatSheet.md +++ b/googlemock/docs/CheatSheet.md @@ -77,7 +77,7 @@ The typical flow is: 1. Create the mock objects. 1. Optionally, set the default actions of the mock objects. 1. Set your expectations on the mock objects (How will they be called? What wil they do?). - 1. Exercise code that uses the mock objects; if necessary, check the result using [Google Test](http://code.google.com/p/googletest/) assertions. + 1. Exercise code that uses the mock objects; if necessary, check the result using [Google Test](../../googletest/) assertions. 1. When a mock objects is destructed, Google Mock automatically verifies that all expectations on it have been satisfied. Here is an example: @@ -197,7 +197,7 @@ matcher will be changed. |`NanSensitiveFloatEq(a_float)`|`argument` is a `float` value approximately equal to `a_float`, treating two NaNs as equal. | The above matchers use ULP-based comparison (the same as used in -[Google Test](http://code.google.com/p/googletest/)). They +[Google Test](../../googletest/)). They automatically pick a reasonable error bound based on the absolute value of the expected value. `DoubleEq()` and `FloatEq()` conform to the IEEE standard, which requires comparing two NaNs for equality to @@ -227,7 +227,7 @@ The `argument` can be either a C string or a C++ string object: `ContainsRegex()` and `MatchesRegex()` use the regular expression syntax defined -[here](http://code.google.com/p/googletest/wiki/AdvancedGuide#Regular_Expression_Syntax). +[here](../../googletest/docs/AdvancedGuide.md#regular-expression-syntax). `StrCaseEq()`, `StrCaseNe()`, `StrEq()`, and `StrNe()` work for wide strings as well. @@ -322,7 +322,7 @@ You can make a matcher from one or more other matchers: |`MatcherCast<T>(m)`|casts matcher `m` to type `Matcher<T>`.| |:------------------|:--------------------------------------| -|`SafeMatcherCast<T>(m)`| [safely casts](http://code.google.com/p/googlemock/wiki/CookBook#Casting_Matchers) matcher `m` to type `Matcher<T>`. | +|`SafeMatcherCast<T>(m)`| [safely casts](CookBook.md#casting-matchers) matcher `m` to type `Matcher<T>`. | |`Truly(predicate)` |`predicate(argument)` returns something considered by C++ to be true, where `predicate` is a function or functor.| ## Matchers as Predicates ## @@ -347,7 +347,7 @@ You can make a matcher from one or more other matchers: ## Matchers as Test Assertions ## -|`ASSERT_THAT(expression, m)`|Generates a [fatal failure](http://code.google.com/p/googletest/wiki/Primer#Assertions) if the value of `expression` doesn't match matcher `m`.| +|`ASSERT_THAT(expression, m)`|Generates a [fatal failure](../../googletest/docs/Primer.md#assertions) if the value of `expression` doesn't match matcher `m`.| |:---------------------------|:----------------------------------------------------------------------------------------------------------------------------------------------| |`EXPECT_THAT(expression, m)`|Generates a non-fatal failure if the value of `expression` doesn't match matcher `m`. | @@ -553,10 +553,10 @@ class MockFunction<R(A1, ..., An)> { MOCK_METHODn(Call, R(A1, ..., An)); }; ``` -See this [recipe](http://code.google.com/p/googlemock/wiki/CookBook#Using_Check_Points) for one application of it. +See this [recipe](CookBook.md#using-check-points) for one application of it. # Flags # | `--gmock_catch_leaked_mocks=0` | Don't report leaked mock objects as failures. | |:-------------------------------|:----------------------------------------------| -| `--gmock_verbose=LEVEL` | Sets the default verbosity level (`info`, `warning`, or `error`) of Google Mock messages. |
\ No newline at end of file +| `--gmock_verbose=LEVEL` | Sets the default verbosity level (`info`, `warning`, or `error`) of Google Mock messages. | diff --git a/googlemock/docs/CookBook.md b/googlemock/docs/CookBook.md index 8a0d3f70..c215b551 100644 --- a/googlemock/docs/CookBook.md +++ b/googlemock/docs/CookBook.md @@ -905,7 +905,7 @@ Matches(AllOf(Ge(0), Le(100), Ne(50))) Since matchers are basically predicates that also know how to describe themselves, there is a way to take advantage of them in -[Google Test](http://code.google.com/p/googletest/) assertions. It's +[Google Test](../../googletest/) assertions. It's called `ASSERT_THAT` and `EXPECT_THAT`: ``` @@ -948,7 +948,7 @@ Expected: starts with "Hello" ``` **Credit:** The idea of `(ASSERT|EXPECT)_THAT` was stolen from the -[Hamcrest](http://code.google.com/p/hamcrest/) project, which adds +[Hamcrest](https://github.com/hamcrest/) project, which adds `assertThat()` to JUnit. ## Using Predicates as Matchers ## @@ -1343,7 +1343,7 @@ Remember that `_` is the wildcard matcher that matches anything. With this, if ` Note that the order of the two `EXPECT_CALLs` is important, as a newer `EXPECT_CALL` takes precedence over an older one. -For more on uninteresting calls, nice mocks, and strict mocks, read ["The Nice, the Strict, and the Naggy"](https://code.google.com/p/googlemock/wiki/CookBook#The_Nice,_the_Strict,_and_the_Naggy). +For more on uninteresting calls, nice mocks, and strict mocks, read ["The Nice, the Strict, and the Naggy"](#the-nice-the-strict-and-the-naggy). ## Expecting Ordered Calls ## @@ -1387,7 +1387,7 @@ instead of being overly constraining. Google Mock allows you to impose an arbitrary DAG (directed acyclic graph) on the calls. One way to express the DAG is to use the -[After](http://code.google.com/p/googlemock/wiki/CheatSheet#The_After_Clause) clause of `EXPECT_CALL`. +[After](CheatSheet.md#the-after-clause) clause of `EXPECT_CALL`. Another way is via the `InSequence()` clause (not the same as the `InSequence` class), which we borrowed from jMock 2. It's less @@ -2484,7 +2484,7 @@ MockFoo::~MockFoo() {} When it's being destoyed, your friendly mock object will automatically verify that all expectations on it have been satisfied, and will -generate [Google Test](http://code.google.com/p/googletest/) failures +generate [Google Test](../../googletest/) failures if not. This is convenient as it leaves you with one less thing to worry about. That is, unless you are not sure if your mock object will be destoyed. @@ -2803,7 +2803,7 @@ obvious that the third `EXPECT_CALL` is written wrong. Case solved. ## Running Tests in Emacs ## If you build and run your tests in Emacs, the source file locations of -Google Mock and [Google Test](http://code.google.com/p/googletest/) +Google Mock and [Google Test](../../googletest/) errors will be highlighted. Just press `<Enter>` on one of them and you'll be taken to the offending line. Or, you can just type `C-x `` to jump to the next error. @@ -2838,7 +2838,7 @@ and you should see an `OUTPUT_DIR` directory being created with files These three files contain everything you need to use Google Mock (and Google Test). Just copy them to anywhere you want and you are ready to write tests and use mocks. You can use the -[scrpts/test/Makefile](http://code.google.com/p/googlemock/source/browse/trunk/scripts/test/Makefile) file as an example on how to compile your tests +[scrpts/test/Makefile](../scripts/test/Makefile) file as an example on how to compile your tests against them. # Extending Google Mock # @@ -3670,6 +3670,6 @@ This printer knows how to print built-in C++ types, native arrays, STL containers, and any type that supports the `<<` operator. For other types, it prints the raw bytes in the value and hopes that you the user can figure it out. -[Google Test's advanced guide](http://code.google.com/p/googletest/wiki/AdvancedGuide#Teaching_Google_Test_How_to_Print_Your_Values) +[Google Test's advanced guide](../../googletest/docs/AdvancedGuide.md#teaching-google-test-how-to-print-your-values) explains how to extend the printer to do a better job at -printing your particular type than to dump the bytes.
\ No newline at end of file +printing your particular type than to dump the bytes. diff --git a/googlemock/docs/DevGuide.md b/googlemock/docs/DevGuide.md index be9e64d1..f4bab75c 100644 --- a/googlemock/docs/DevGuide.md +++ b/googlemock/docs/DevGuide.md @@ -15,7 +15,7 @@ All Google Mock source and pre-built packages are provided under the [New BSD Li ## The Google Mock Community ## The Google Mock community exists primarily through the [discussion group](http://groups.google.com/group/googlemock), the -[issue tracker](http://code.google.com/p/googlemock/issues/list) and, to a lesser extent, the [source control repository](http://code.google.com/p/googlemock/source/checkout). You are definitely encouraged to contribute to the +[issue tracker](https://github.com/google/googletest/issues) and, to a lesser extent, the [source control 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. @@ -52,12 +52,12 @@ Checking out the Google Mock source is most useful if you plan to tweak it yourself. You check out the source for Google Mock 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/googlemock/source/checkout) for how to do it. +the [source code access page](../) 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/googlemock/source/browse/trunk/README) file. +compile it in the [README](../README.md) file. ## Testing ## @@ -90,8 +90,8 @@ instructions for how to sign and return it. ## Coding Style ## To keep the source consistent, readable, diffable and easy to merge, -we use a fairly rigid coding style, as defined by the [google-styleguide](http://code.google.com/p/google-styleguide/) project. All patches will be expected -to conform to the style outlined [here](http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml). +we use a fairly rigid coding style, as defined by the [google-styleguide](https://github.com/google/styleguide) project. All patches will be expected +to conform to the style outlined [here](https://github.com/google/styleguide/blob/gh-pages/cppguide.xml). ## Submitting Patches ## @@ -104,7 +104,7 @@ Please do submit code. Here's what you need to do: 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 `googlemock@googlegroups.com` to review it. There are several ways to upload the patch. We recommend using the [upload\_gmock.py](http://code.google.com/p/googlemock/source/browse/trunk/scripts/upload_gmock.py) script, which you can find in the `scripts/` folder in the SVN trunk. + 1. We use [Rietveld](http://codereview.appspot.com/) to do web-based code reviews. You can read about the tool [here](https://github.com/rietveld-codereview/rietveld/wiki). When you are ready, upload your patch via Rietveld and notify `googlemock@googlegroups.com` to review it. There are several ways to upload the patch. We recommend using the [upload\_gmock.py](../scripts/upload_gmock.py) script, which you can find in the `scripts/` folder in the SVN trunk. ## Google Mock Committers ## @@ -129,4 +129,4 @@ We follow the typical release process for Subversion-based projects: --- -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/googlemock/docs/Documentation.md b/googlemock/docs/Documentation.md index 920ed59d..444151ee 100644 --- a/googlemock/docs/Documentation.md +++ b/googlemock/docs/Documentation.md @@ -9,4 +9,4 @@ This page lists all documentation wiki pages for Google Mock **(the SVN trunk ve To contribute code to Google Mock, read: * [DevGuide](DevGuide.md) -- read this _before_ writing your first patch. - * [Pump Manual](http://code.google.com/p/googletest/wiki/PumpManual) -- how we generate some of Google Mock's source files.
\ No newline at end of file + * [Pump Manual](../googletest/docs/PumpManual.md) -- how we generate some of Google Mock's source files. diff --git a/googlemock/docs/ForDummies.md b/googlemock/docs/ForDummies.md index f6c1ba7a..e2f362a6 100644 --- a/googlemock/docs/ForDummies.md +++ b/googlemock/docs/ForDummies.md @@ -1,6 +1,6 @@ -(**Note:** If you get compiler errors that you don't understand, be sure to consult [Google Mock Doctor](http://code.google.com/p/googlemock/wiki/FrequentlyAskedQuestions#How_am_I_supposed_to_make_sense_of_these_horrible_template_error).) +(**Note:** If you get compiler errors that you don't understand, be sure to consult [Google Mock Doctor](FrequentlyAskedQuestions.md#how-am-i-supposed-to-make-sense-of-these-horrible-template-errors).) # What Is Google C++ Mocking Framework? # When you write a prototype or test, often it's not feasible or wise to rely on real objects entirely. A **mock object** implements the same interface as a real 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). @@ -76,7 +76,7 @@ If you are lucky, the mocks you need to use have already been implemented by som Using the `Turtle` interface as example, here are the simple steps you need to follow: 1. Derive a class `MockTurtle` from `Turtle`. - 1. Take a _virtual_ function of `Turtle` (while it's possible to [mock non-virtual methods using templates](http://code.google.com/p/googlemock/wiki/CookBook#Mocking_Nonvirtual_Methods), it's much more involved). Count how many arguments it has. + 1. Take a _virtual_ function of `Turtle` (while it's possible to [mock non-virtual methods using templates](CookBook.md#mocking-nonvirtual-methods), it's much more involved). Count how many arguments it has. 1. In the `public:` section of the child class, write `MOCK_METHODn();` (or `MOCK_CONST_METHODn();` if you are mocking a `const` method), where `n` is the number of the arguments; if you counted wrong, shame on you, and a compiler error will tell you so. 1. Now comes the fun part: you take the function signature, cut-and-paste the _function name_ as the _first_ argument to the macro, and leave what's left as the _second_ argument (in case you're curious, this is the _type of the function_). 1. Repeat until all virtual functions you want to mock are done. @@ -105,7 +105,7 @@ You don't need to define these mock methods somewhere else - the `MOCK_METHOD*` tool requires that you have Python 2.4 installed. You give it a C++ file and the name of an abstract class defined in it, and it will print the definition of the mock class for you. Due to the complexity of the C++ language, this script may not always work, but -it can be quite handy when it does. For more details, read the [user documentation](http://code.google.com/p/googlemock/source/browse/trunk/scripts/generator/README). +it can be quite handy when it does. For more details, read the [user documentation](../scripts/generator/README). ## Where to Put It ## When you define a mock class, you need to decide where to put its definition. Some people put it in a `*_test.cc`. This is fine when the interface being mocked (say, `Foo`) is owned by the same person or team. Otherwise, when the owner of `Foo` changes it, your test could break. (You can't really expect `Foo`'s maintainer to fix every test that uses `Foo`, can you?) @@ -169,7 +169,7 @@ This means `EXPECT_CALL()` should be read as expecting that a call will occur _i Admittedly, this test is contrived and doesn't do much. You can easily achieve the same effect without using Google Mock. However, as we shall reveal soon, Google Mock allows you to do _much more_ with the mocks. ## Using Google Mock with Any Testing Framework ## -If you want to use something other than Google Test (e.g. [CppUnit](http://apps.sourceforge.net/mediawiki/cppunit/index.php?title=Main_Page) or +If you want to use something other than Google Test (e.g. [CppUnit](http://sourceforge.net/projects/cppunit/) or [CxxTest](http://cxxtest.tigris.org/)) as your testing framework, just change the `main()` function in the previous section to: ``` int main(int argc, char** argv) { @@ -187,7 +187,7 @@ sometimes causes the test program to crash. You'll still be able to notice that the test has failed, but it's not a graceful failure. A better solution is to use Google Test's -[event listener API](http://code.google.com/p/googletest/wiki/AdvancedGuide#Extending_Google_Test_by_Handling_Test_Events) +[event listener API](../../googletest/docs/AdvancedGuide.md#extending-google-test-by-handling-test-events) to report a test failure to your testing framework properly. You'll need to implement the `OnTestPartResult()` method of the event listener interface, but it should be straightforward. @@ -301,7 +301,7 @@ says that `turtle.GetY()` will be called _at least twice_ (Google Mock knows thi Of course, if you explicitly write a `Times()`, Google Mock will not try to infer the cardinality itself. What if the number you specified is larger than there are `WillOnce()` clauses? Well, after all `WillOnce()`s are used up, Google Mock will do the _default_ action for the function every time (unless, of course, you have a `WillRepeatedly()`.). -What can we do inside `WillOnce()` besides `Return()`? You can return a reference using `ReturnRef(variable)`, or invoke a pre-defined function, among [others](http://code.google.com/p/googlemock/wiki/CheatSheet#Actions). +What can we do inside `WillOnce()` besides `Return()`? You can return a reference using `ReturnRef(variable)`, or invoke a pre-defined function, among [others](CheatSheet.md#actions). **Important note:** The `EXPECT_CALL()` statement evaluates the action clause only once, even though the action may be performed many times. Therefore you must be careful about side effects. The following may not do what you want: @@ -436,4 +436,4 @@ In Google Mock, if you are not interested in a method, just don't say anything a # What Now? # Congratulations! You've learned enough about Google Mock to start using it. Now, you might want to join the [googlemock](http://groups.google.com/group/googlemock) discussion group and actually write some tests using Google Mock - it will be fun. Hey, it may even be addictive - you've been warned. -Then, if you feel like increasing your mock quotient, you should move on to the [CookBook](CookBook.md). You can learn many advanced features of Google Mock there -- and advance your level of enjoyment and testing bliss.
\ No newline at end of file +Then, if you feel like increasing your mock quotient, you should move on to the [CookBook](CookBook.md). You can learn many advanced features of Google Mock there -- and advance your level of enjoyment and testing bliss. diff --git a/googlemock/docs/FrequentlyAskedQuestions.md b/googlemock/docs/FrequentlyAskedQuestions.md index 859a71e1..5eac83f4 100644 --- a/googlemock/docs/FrequentlyAskedQuestions.md +++ b/googlemock/docs/FrequentlyAskedQuestions.md @@ -7,7 +7,7 @@ tried [Google Mock Doctor](#How_am_I_supposed_to_make_sense_of_these_horrible_te ## When I call a method on my mock object, the method for the real object is invoked instead. What's the problem? ## -In order for a method to be mocked, it must be _virtual_, unless you use the [high-perf dependency injection technique](http://code.google.com/p/googlemock/wiki/CookBook#Mocking_Nonvirtual_Methods). +In order for a method to be mocked, it must be _virtual_, unless you use the [high-perf dependency injection technique](CookBook.md#mocking-nonvirtual-methods). ## I wrote some matchers. After I upgraded to a new version of Google Mock, they no longer compile. What's going on? ## @@ -196,8 +196,8 @@ class MyGreatMatcher { ``` For more information, you can read these -[two](http://code.google.com/p/googlemock/wiki/CookBook#Writing_New_Monomorphic_Matchers) -[recipes](http://code.google.com/p/googlemock/wiki/CookBook#Writing_New_Polymorphic_Matchers) +[two](CookBook.md#writing-new-monomorphic-matchers) +[recipes](CookBook.md#writing-new-polymorphic-matchers) from the cookbook. As always, you are welcome to post questions on `googlemock@googlegroups.com` if you need any help. @@ -206,7 +206,7 @@ need any help. Google Mock works out of the box with Google Test. However, it's easy to configure it to work with any testing framework of your choice. -[Here](http://code.google.com/p/googlemock/wiki/ForDummies#Using_Google_Mock_with_Any_Testing_Framework) is how. +[Here](ForDummies.md#using-google-mock-with-any-testing-framework) is how. ## How am I supposed to make sense of these horrible template errors? ## @@ -474,10 +474,10 @@ verbose level. If you find yourself needing to perform some action that's not supported by Google Mock directly, remember that you can define your own actions using -[MakeAction()](http://code.google.com/p/googlemock/wiki/CookBook#Writing_New_Actions) or -[MakePolymorphicAction()](http://code.google.com/p/googlemock/wiki/CookBook#Writing_New_Polymorphic_Actions), +[MakeAction()](CookBook.md#writing-new-actions) or +[MakePolymorphicAction()](CookBook.md#writing_new_polymorphic_actions), or you can write a stub function and invoke it using -[Invoke()](http://code.google.com/p/googlemock/wiki/CookBook#Using_Functions_Methods_Functors). +[Invoke()](CookBook.md#using-functions_methods_functors). ## MOCK\_METHODn()'s second argument looks funny. Why don't you use the MOCK\_METHODn(Method, return\_type, arg\_1, ..., arg\_n) syntax? ## @@ -599,7 +599,7 @@ when the mock method is called. `SetArgPointee()` says what the side effect is, but doesn't say what the return value should be. You need `DoAll()` to chain a `SetArgPointee()` with a `Return()`. -See this [recipe](http://code.google.com/p/googlemock/wiki/CookBook#Mocking_Side_Effects) for more details and an example. +See this [recipe](CookBook.md#mocking_side_effects) for more details and an example. ## My question is not in your FAQ! ## @@ -607,12 +607,12 @@ See this [recipe](http://code.google.com/p/googlemock/wiki/CookBook#Mocking_Side 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/googlemock/w/list), + 1. read other [documentation](Documentation.md), 1. search the mailing list [archive](http://groups.google.com/group/googlemock/topics), 1. ask it on [googlemock@googlegroups.com](mailto:googlemock@googlegroups.com) and someone will answer it (to prevent spam, we require you to join the [discussion group](http://groups.google.com/group/googlemock) before you can post.). Please note that creating an issue in the -[issue tracker](http://code.google.com/p/googlemock/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. @@ -625,4 +625,4 @@ not enough information in your question): * 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. diff --git a/googlemock/include/gmock/gmock-actions.h b/googlemock/include/gmock/gmock-actions.h index c09c4d6e..b3f654af 100644 --- a/googlemock/include/gmock/gmock-actions.h +++ b/googlemock/include/gmock/gmock-actions.h @@ -46,7 +46,7 @@ #include "gmock/internal/gmock-internal-utils.h" #include "gmock/internal/gmock-port.h" -#if GTEST_LANG_CXX11 // Defined by gtest-port.h via gmock-port.h. +#if GTEST_HAS_STD_TYPE_TRAITS_ // Defined by gtest-port.h via gmock-port.h. #include <type_traits> #endif @@ -96,7 +96,7 @@ struct BuiltInDefaultValueGetter<T, false> { template <typename T> class BuiltInDefaultValue { public: -#if GTEST_LANG_CXX11 +#if GTEST_HAS_STD_TYPE_TRAITS_ // This function returns true iff type T has a built-in default value. static bool Exists() { return ::std::is_default_constructible<T>::value; @@ -107,7 +107,7 @@ class BuiltInDefaultValue { T, ::std::is_default_constructible<T>::value>::Get(); } -#else // GTEST_LANG_CXX11 +#else // GTEST_HAS_STD_TYPE_TRAITS_ // This function returns true iff type T has a built-in default value. static bool Exists() { return false; @@ -117,7 +117,7 @@ class BuiltInDefaultValue { return BuiltInDefaultValueGetter<T, false>::Get(); } -#endif // GTEST_LANG_CXX11 +#endif // GTEST_HAS_STD_TYPE_TRAITS_ }; // This partial specialization says that we use the same built-in diff --git a/googlemock/test/gmock-actions_test.cc b/googlemock/test/gmock-actions_test.cc index a665fc5f..f470de4c 100644 --- a/googlemock/test/gmock-actions_test.cc +++ b/googlemock/test/gmock-actions_test.cc @@ -214,7 +214,7 @@ class MyNonDefaultConstructible { int value_; }; -#if GTEST_LANG_CXX11 +#if GTEST_HAS_STD_TYPE_TRAITS_ TEST(BuiltInDefaultValueTest, ExistsForDefaultConstructibleType) { EXPECT_TRUE(BuiltInDefaultValue<MyDefaultConstructible>::Exists()); @@ -224,7 +224,7 @@ TEST(BuiltInDefaultValueTest, IsDefaultConstructedForDefaultConstructibleType) { EXPECT_EQ(42, BuiltInDefaultValue<MyDefaultConstructible>::Get().value()); } -#endif // GTEST_LANG_CXX11 +#endif // GTEST_HAS_STD_TYPE_TRAITS_ TEST(BuiltInDefaultValueTest, DoesNotExistForNonDefaultConstructibleType) { EXPECT_FALSE(BuiltInDefaultValue<MyNonDefaultConstructible>::Exists()); diff --git a/googlemock/test/gmock-matchers_test.cc b/googlemock/test/gmock-matchers_test.cc index b09acba9..78c4c901 100644 --- a/googlemock/test/gmock-matchers_test.cc +++ b/googlemock/test/gmock-matchers_test.cc @@ -1042,14 +1042,14 @@ TEST(IsNullTest, ReferenceToConstLinkedPtr) { EXPECT_FALSE(m.Matches(non_null_p)); } -#if GTEST_LANG_CXX11 +#if GTEST_HAS_STD_FUNCTION_ TEST(IsNullTest, StdFunction) { const Matcher<std::function<void()>> m = IsNull(); EXPECT_TRUE(m.Matches(std::function<void()>())); EXPECT_FALSE(m.Matches([]{})); } -#endif // GTEST_LANG_CXX11 +#endif // GTEST_HAS_STD_FUNCTION_ // Tests that IsNull() describes itself properly. TEST(IsNullTest, CanDescribeSelf) { @@ -1090,14 +1090,14 @@ TEST(NotNullTest, ReferenceToConstLinkedPtr) { EXPECT_TRUE(m.Matches(non_null_p)); } -#if GTEST_LANG_CXX11 +#if GTEST_HAS_STD_FUNCTION_ TEST(NotNullTest, StdFunction) { const Matcher<std::function<void()>> m = NotNull(); EXPECT_TRUE(m.Matches([]{})); EXPECT_FALSE(m.Matches(std::function<void()>())); } -#endif // GTEST_LANG_CXX11 +#endif // GTEST_HAS_STD_FUNCTION_ // Tests that NotNull() describes itself properly. TEST(NotNullTest, CanDescribeSelf) { @@ -2708,22 +2708,18 @@ class FloatingPointTest : public testing::Test { zero_bits_(Floating(0).bits()), one_bits_(Floating(1).bits()), infinity_bits_(Floating(Floating::Infinity()).bits()), - close_to_positive_zero_( - Floating::ReinterpretBits(zero_bits_ + max_ulps_/2)), - close_to_negative_zero_( - -Floating::ReinterpretBits(zero_bits_ + max_ulps_ - max_ulps_/2)), - further_from_negative_zero_(-Floating::ReinterpretBits( + close_to_positive_zero_(AsBits(zero_bits_ + max_ulps_/2)), + close_to_negative_zero_(AsBits(zero_bits_ + max_ulps_ - max_ulps_/2)), + further_from_negative_zero_(-AsBits( zero_bits_ + max_ulps_ + 1 - max_ulps_/2)), - close_to_one_(Floating::ReinterpretBits(one_bits_ + max_ulps_)), - further_from_one_(Floating::ReinterpretBits(one_bits_ + max_ulps_ + 1)), + close_to_one_(AsBits(one_bits_ + max_ulps_)), + further_from_one_(AsBits(one_bits_ + max_ulps_ + 1)), infinity_(Floating::Infinity()), - close_to_infinity_( - Floating::ReinterpretBits(infinity_bits_ - max_ulps_)), - further_from_infinity_( - Floating::ReinterpretBits(infinity_bits_ - max_ulps_ - 1)), + close_to_infinity_(AsBits(infinity_bits_ - max_ulps_)), + further_from_infinity_(AsBits(infinity_bits_ - max_ulps_ - 1)), max_(Floating::Max()), - nan1_(Floating::ReinterpretBits(Floating::kExponentBitMask | 1)), - nan2_(Floating::ReinterpretBits(Floating::kExponentBitMask | 200)) { + nan1_(AsBits(Floating::kExponentBitMask | 1)), + nan2_(AsBits(Floating::kExponentBitMask | 200)) { } void TestSize() { @@ -2804,6 +2800,12 @@ class FloatingPointTest : public testing::Test { // Some NaNs. const RawType nan1_; const RawType nan2_; + + private: + template <typename T> + static RawType AsBits(T value) { + return Floating::ReinterpretBits(static_cast<Bits>(value)); + } }; // Tests floating-point matchers with fixed epsilons. @@ -3179,6 +3181,8 @@ MATCHER_P(FieldIIs, inner_matcher, "") { return ExplainMatchResult(inner_matcher, arg.i, result_listener); } +#if GTEST_HAS_RTTI + TEST(WhenDynamicCastToTest, SameType) { Derived derived; derived.i = 4; @@ -3236,12 +3240,8 @@ TEST(WhenDynamicCastToTest, AmbiguousCast) { TEST(WhenDynamicCastToTest, Describe) { Matcher<Base*> matcher = WhenDynamicCastTo<Derived*>(Pointee(_)); -#if GTEST_HAS_RTTI const string prefix = "when dynamic_cast to " + internal::GetTypeName<Derived*>() + ", "; -#else // GTEST_HAS_RTTI - const string prefix = "when dynamic_cast, "; -#endif // GTEST_HAS_RTTI EXPECT_EQ(prefix + "points to a value that is anything", Describe(matcher)); EXPECT_EQ(prefix + "does not point to a value that is anything", DescribeNegation(matcher)); @@ -3275,6 +3275,8 @@ TEST(WhenDynamicCastToTest, BadReference) { EXPECT_THAT(as_base_ref, Not(WhenDynamicCastTo<const OtherDerived&>(_))); } +#endif // GTEST_HAS_RTTI + // Minimal const-propagating pointer. template <typename T> class ConstPropagatingPtr { diff --git a/googletest/CMakeLists.txt b/googletest/CMakeLists.txt index bd78cfe6..621d0f04 100644 --- a/googletest/CMakeLists.txt +++ b/googletest/CMakeLists.txt @@ -22,6 +22,11 @@ option(gtest_build_samples "Build gtest's sample programs." OFF) option(gtest_disable_pthreads "Disable uses of pthreads in gtest." OFF) +option( + gtest_hide_internal_symbols + "Build gtest with internal symbols hidden in shared libraries." + OFF) + # Defines pre_project_set_up_hermetic_build() and set_up_hermetic_build(). include(cmake/hermetic_build.cmake OPTIONAL) @@ -46,6 +51,11 @@ if (COMMAND set_up_hermetic_build) set_up_hermetic_build() endif() +if (gtest_hide_internal_symbols) + set(CMAKE_CXX_VISIBILITY_PRESET hidden) + set(CMAKE_VISIBILITY_INLINES_HIDDEN 1) +endif() + # Define helper functions and macros used by Google Test. include(cmake/internal_utils.cmake) @@ -81,6 +91,22 @@ cxx_library(gtest "${cxx_strict}" src/gtest-all.cc) cxx_library(gtest_main "${cxx_strict}" src/gtest_main.cc) target_link_libraries(gtest_main gtest) +# If the CMake version supports it, attach header directory information +# to the targets for when we are part of a parent build (ie being pulled +# in via add_subdirectory() rather than being a standalone build). +if (DEFINED CMAKE_VERSION AND NOT "${CMAKE_VERSION}" VERSION_LESS "2.8.11") + target_include_directories(gtest INTERFACE "${gtest_SOURCE_DIR}/include") + target_include_directories(gtest_main INTERFACE "${gtest_SOURCE_DIR}/include") +endif() + +######################################################################## +# +# Install rules +install(TARGETS gtest gtest_main + DESTINATION lib) +install(DIRECTORY ${gtest_SOURCE_DIR}/include/gtest + DESTINATION include) + ######################################################################## # # Samples on how to link user tests with gtest or gtest_main. diff --git a/googletest/README.md b/googletest/README.md index 9bd59c8e..e0ea1b0f 100644 --- a/googletest/README.md +++ b/googletest/README.md @@ -54,7 +54,7 @@ it. ### Using CMake ### Google Test comes with a CMake build script ( -[CMakeLists.txt](master/CMakeLists.txt)) that can be used on a wide range of platforms ("C" stands for +[CMakeLists.txt](CMakeLists.txt)) that can be used on a wide range of platforms ("C" stands for cross-platform.). If you don't have CMake installed already, you can download it for free from <http://www.cmake.org/>. @@ -136,7 +136,7 @@ these macros are named like `GTEST_XYZ` and you define them to either 1 or 0 to enable or disable a certain feature. We list the most frequently used macros below. For a complete list, -see file [include/gtest/internal/gtest-port.h](https://github.com/google/googletest/blob/master/include/gtest/internal/gtest-port.h). +see file [include/gtest/internal/gtest-port.h](include/gtest/internal/gtest-port.h). ### Choosing a TR1 Tuple Library ### diff --git a/googletest/docs/AdvancedGuide.md b/googletest/docs/AdvancedGuide.md index 576efc35..5ad10e10 100644 --- a/googletest/docs/AdvancedGuide.md +++ b/googletest/docs/AdvancedGuide.md @@ -44,7 +44,7 @@ switch(expression) { } ``` -Note: you can only use `FAIL()` in functions that return `void`. See the [Assertion Placement section](#Assertion_Placement.md) for more information. +Note: you can only use `FAIL()` in functions that return `void`. See the [Assertion Placement section](#assertion-placement) for more information. _Availability_: Linux, Windows, Mac. @@ -125,7 +125,7 @@ c is 10<br> **Notes:** - 1. If you see a compiler error "no matching function to call" when using `ASSERT_PRED*` or `EXPECT_PRED*`, please see [this](http://code.google.com/p/googletest/wiki/FAQ#The_compiler_complains_%22no_matching_function_to_call%22) for how to resolve it. + 1. If you see a compiler error "no matching function to call" when using `ASSERT_PRED*` or `EXPECT_PRED*`, please see [this FAQ](FAQ.md#the-compiler-complains-no-matching-function-to-call-when-i-use-assert_predn-how-do-i-fix-it) for how to resolve it. 1. Currently we only provide predicate assertions of arity <= 5. If you need a higher-arity assertion, let us know. _Availability_: Linux, Windows, Mac @@ -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 | | `...` | `...` | `...` | @@ -265,7 +265,7 @@ int SmallestPrimeCommonDivisor(int m, int n) { ... } int n) { if (MutuallyPrime(m, n)) return ::testing::AssertionSuccess(); - + return ::testing::AssertionFailure() << m_expr << " and " << n_expr << " (" << m << " and " << n << ") are not mutually prime, " << "as they have a common divisor " @@ -517,9 +517,9 @@ _death tests_. More generally, any test that checks that a program terminates Note that if a piece of code throws an exception, we don't consider it "death" for the purpose of death tests, as the caller of the code could catch the exception and avoid the crash. If you want to verify exceptions thrown by your code, -see [Exception Assertions](#Exception_Assertions.md). +see [Exception Assertions](#exception-assertions). -If you want to test `EXPECT_*()/ASSERT_*()` failures in your test code, see [Catching Failures](#Catching_Failures.md). +If you want to test `EXPECT_*()/ASSERT_*()` failures in your test code, see [Catching Failures](#catching-failures). ## How to Write a Death Test ## @@ -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 @@ -804,7 +804,7 @@ For example, 11: EXPECT_EQ(1, Bar(n)); 12: EXPECT_EQ(2, Bar(n + 1)); 13: } -14: +14: 15: TEST(FooTest, Bar) { 16: { 17: SCOPED_TRACE("A"); // This trace point will be included in @@ -1199,9 +1199,9 @@ which are all in the `testing` namespace: | `Values(v1, v2, ..., vN)` | Yields values `{v1, v2, ..., vN}`. | | `ValuesIn(container)` and `ValuesIn(begin, end)` | Yields values from a C-style array, an STL-style container, or an iterator range `[begin, end)`. `container`, `begin`, and `end` can be expressions whose values are determined at run time. | | `Bool()` | Yields sequence `{false, true}`. | -| `Combine(g1, g2, ..., gN)` | Yields all combinations (the Cartesian product for the math savvy) of the values generated by the `N` generators. This is only available if your system provides the `<tr1/tuple>` header. If you are sure your system does, and Google Test disagrees, you can override it by defining `GTEST_HAS_TR1_TUPLE=1`. See comments in [include/gtest/internal/gtest-port.h](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/internal/gtest-port.h) for more information. | +| `Combine(g1, g2, ..., gN)` | Yields all combinations (the Cartesian product for the math savvy) of the values generated by the `N` generators. This is only available if your system provides the `<tr1/tuple>` header. If you are sure your system does, and Google Test disagrees, you can override it by defining `GTEST_HAS_TR1_TUPLE=1`. See comments in [include/gtest/internal/gtest-port.h](../include/gtest/internal/gtest-port.h) for more information. | -For more details, see the comments at the definitions of these functions in the [source code](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/gtest-param-test.h). +For more details, see the comments at the definitions of these functions in the [source code](../include/gtest/gtest-param-test.h). The following statement will instantiate tests from the `FooTest` test case each with parameter values `"meeny"`, `"miny"`, and `"moe"`. @@ -1226,7 +1226,7 @@ names: * `InstantiationName/FooTest.HasBlahBlah/1` for `"miny"` * `InstantiationName/FooTest.HasBlahBlah/2` for `"moe"` -You can use these names in [--gtest\_filter](#Running_a_Subset_of_the_Tests.md). +You can use these names in [--gtest\_filter](#running-a-subset-of-the-tests). This statement will instantiate all tests from `FooTest` again, each with parameter values `"cat"` and `"dog"`: @@ -1249,8 +1249,8 @@ tests in the given test case, whether their definitions come before or _after_ the `INSTANTIATE_TEST_CASE_P` statement. You can see -[these](http://code.google.com/p/googletest/source/browse/trunk/samples/sample7_unittest.cc) -[files](http://code.google.com/p/googletest/source/browse/trunk/samples/sample8_unittest.cc) for more examples. +[these](../samples/sample7_unittest.cc) +[files](../samples/sample8_unittest.cc) for more examples. _Availability_: Linux, Windows (requires MSVC 8.0 or above), Mac; since version 1.2.0. @@ -1646,8 +1646,8 @@ _Availability:_ Linux, Windows, Mac; since v1.4.0. ## Defining Event Listeners ## To define a event listener, you subclass either -[testing::TestEventListener](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/gtest.h#855) -or [testing::EmptyTestEventListener](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/gtest.h#905). +[testing::TestEventListener](../include/gtest/gtest.h#L991) +or [testing::EmptyTestEventListener](../include/gtest/gtest.h#L1044). The former is an (abstract) interface, where <i>each pure virtual method<br> can be overridden to handle a test event</i> (For example, when a test starts, the `OnTestStart()` method will be called.). The latter provides @@ -1656,10 +1656,10 @@ subclass only needs to override the methods it cares about. When an event is fired, its context is passed to the handler function as an argument. The following argument types are used: - * [UnitTest](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/gtest.h#1007) reflects the state of the entire test program, - * [TestCase](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/gtest.h#689) has information about a test case, which can contain one or more tests, - * [TestInfo](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/gtest.h#599) contains the state of a test, and - * [TestPartResult](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/gtest-test-part.h#42) represents the result of a test assertion. + * [UnitTest](../include/gtest/gtest.h#L1151) reflects the state of the entire test program, + * [TestCase](../include/gtest/gtest.h#L778) has information about a test case, which can contain one or more tests, + * [TestInfo](../include/gtest/gtest.h#L644) contains the state of a test, and + * [TestPartResult](../include/gtest/gtest-test-part.h#L47) represents the result of a test assertion. An event handler function can examine the argument it receives to find out interesting information about the event and the test program's @@ -1695,7 +1695,7 @@ state. Here's an example: To use the event listener you have defined, add an instance of it to the Google Test event listener list (represented by class -[TestEventListeners](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/gtest.h#929) +[TestEventListeners](../include/gtest/gtest.h#L1064) - note the "s" at the end of the name) in your `main()` function, before calling `RUN_ALL_TESTS()`: ``` @@ -1723,7 +1723,7 @@ event listener list and delete it. You can do so by adding one line: Now, sit back and enjoy a completely different output from your tests. For more details, you can read this -[sample](http://code.google.com/p/googletest/source/browse/trunk/samples/sample9_unittest.cc). +[sample](../samples/sample9_unittest.cc). You may append more than one listener to the list. When an `On*Start()` or `OnTestPartResult()` event is fired, the listeners will receive it in @@ -1748,7 +1748,7 @@ failures. This ensures that failures generated by the latter are attributed to the right test by the former. We have a sample of failure-raising listener -[here](http://code.google.com/p/googletest/source/browse/trunk/samples/sample10_unittest.cc). +[here](../samples/sample10_unittest.cc). # Running Test Programs: Advanced Options # @@ -1868,12 +1868,12 @@ _Availability:_ Linux, Windows, Mac. ### Temporarily Enabling Disabled Tests ### -To include [disabled tests](#Temporarily_Disabling_Tests.md) in test +To include [disabled tests](#temporarily-disabling-tests) in test execution, just invoke the test program with the `--gtest_also_run_disabled_tests` flag or set the `GTEST_ALSO_RUN_DISABLED_TESTS` environment variable to a value other than `0`. You can combine this with the -[--gtest\_filter](#Running_a_Subset_of_the_Tests.md) flag to further select +[--gtest\_filter](#running-a-subset-of-the-tests) flag to further select which disabled tests to run. _Availability:_ Linux, Windows, Mac; since version 1.3.0. @@ -2173,11 +2173,11 @@ and you should see an `OUTPUT_DIR` directory being created with files `gtest/gtest.h` and `gtest/gtest-all.cc` in it. These files contain everything you need to use Google Test. Just copy them to anywhere you want and you are ready to write tests. You can use the -[scripts/test/Makefile](http://code.google.com/p/googletest/source/browse/trunk/scripts/test/Makefile) +[scripts/test/Makefile](../scripts/test/Makefile) file as an example on how to compile your tests against them. # Where to Go from Here # Congratulations! You've now learned more advanced Google Test tools and are ready to tackle more complex testing tasks. If you want to dive even deeper, you -can read the [Frequently-Asked Questions](FAQ.md).
\ No newline at end of file +can read the [Frequently-Asked Questions](FAQ.md). 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..639c2509 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](AdvancedGuide.md#global-set-up-and-tear-down) and tests parameterized by [values](AdvancedGuide.md#value-parameterized-tests) or [types](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](AdvancedGuide.md#predicate-assertions-for-better-error-messages), + * teach Google Test how to [print your types](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](AdvancedGuide.md#catching-failures), and + * reflect on the test cases or change the test output format by intercepting the [test events](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) { ... } ``` @@ -201,7 +201,7 @@ we don't have a convention on the order of the two arguments for twice in the implementation, making it even harder to understand and maintain. We believe the benefit doesn't justify the cost. -Finally, with the growth of Google Mock's [matcher](http://code.google.com/p/googlemock/wiki/CookBook#Using_Matchers_in_Google_Test_Assertions) library, we are +Finally, with the growth of Google Mock's [matcher](../../googlemock/docs/CookBook.md#using-matchers-in-google-test-assertions) library, we are encouraging people to use the unified `EXPECT_THAT(value, matcher)` syntax more often in tests. One significant advantage of the matcher approach is that matchers can be easily combined to form new matchers, @@ -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](../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 { ... @@ -754,7 +754,7 @@ EXPECT_TRUE(internal::Func(12345)); ## I would like to run a test several times with different parameters. Do I need to write several similar copies of it? ## -No. You can use a feature called [value-parameterized tests](AdvancedGuide#Value_Parameterized_Tests.md) which +No. You can use a feature called [value-parameterized tests](AdvancedGuide.md#Value_Parameterized_Tests) which lets you repeat your tests with different parameters, without defining it more than once. ## How do I test a file that defines main()? ## @@ -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"); @@ -848,7 +849,7 @@ expression syntax (http://en.wikipedia.org/wiki/Regular_expression#POSIX_Extended_Regular_Expressions). On Windows, it uses a limited variant of regular expression syntax. For more details, see the -[regular expression syntax](AdvancedGuide#Regular_Expression_Syntax.md). +[regular expression syntax](AdvancedGuide.md#Regular_Expression_Syntax). ## I have a fixture class Foo, but TEST\_F(Foo, Bar) gives me error "no matching function for call to Foo::Foo()". Why? ## @@ -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](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](../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](../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. diff --git a/googletest/docs/Primer.md b/googletest/docs/Primer.md index b57ed4aa..9218fd51 100644 --- a/googletest/docs/Primer.md +++ b/googletest/docs/Primer.md @@ -147,7 +147,7 @@ but it's no longer necessary since v1.6.0 (if `<<` is supported, it will be called to print the arguments when the assertion fails; otherwise Google Test will attempt to print them in the best way it can. For more details and how to customize the printing of the -arguments, see this Google Mock [recipe](http://code.google.com/p/googlemock/wiki/CookBook#Teaching_Google_Mock_How_to_Print_Your_Values).). +arguments, see this Google Mock [recipe](../../googlemock/docs/CookBook.md#teaching-google-mock-how-to-print-your-values).). These assertions can work with a user-defined type, but only if you define the corresponding comparison operator (e.g. `==`, `<`, etc). If the corresponding @@ -256,7 +256,7 @@ To create a fixture, just: 1. Derive a class from `::testing::Test` . Start its body with `protected:` or `public:` as we'll want to access fixture members from sub-classes. 1. Inside the class, declare any objects you plan to use. 1. If necessary, write a default constructor or `SetUp()` function to prepare the objects for each test. A common mistake is to spell `SetUp()` as `Setup()` with a small `u` - don't let that happen to you. - 1. If necessary, write a destructor or `TearDown()` function to release any resources you allocated in `SetUp()` . To learn when you should use the constructor/destructor and when you should use `SetUp()/TearDown()`, read this [FAQ entry](http://code.google.com/p/googletest/wiki/FAQ#Should_I_use_the_constructor/destructor_of_the_test_fixture_or_t). + 1. If necessary, write a destructor or `TearDown()` function to release any resources you allocated in `SetUp()` . To learn when you should use the constructor/destructor and when you should use `SetUp()/TearDown()`, read this [FAQ entry](FAQ.md#should-i-use-the-constructordestructor-of-the-test-fixture-or-the-set-uptear-down-function). 1. If needed, define subroutines for your tests to share. When using a fixture, use `TEST_F()` instead of `TEST()` as it allows you to diff --git a/googletest/docs/V1_5_AdvancedGuide.md b/googletest/docs/V1_5_AdvancedGuide.md index 2c3fc1a4..9511f226 100644 --- a/googletest/docs/V1_5_AdvancedGuide.md +++ b/googletest/docs/V1_5_AdvancedGuide.md @@ -123,7 +123,7 @@ c is 10<br> **Notes:** - 1. If you see a compiler error "no matching function to call" when using `ASSERT_PRED*` or `EXPECT_PRED*`, please see [this](http://code.google.com/p/googletest/wiki/V1_5_FAQ#The_compiler_complains_%22no_matching_function_to_call%22) for how to resolve it. + 1. If you see a compiler error "no matching function to call" when using `ASSERT_PRED*` or `EXPECT_PRED*`, please see [this](V1_5_FAQ.md#the-compiler-complains-about-undefined-references-to-some-static-const-member-variables-but-i-did-define-them-in-the-class-body-whats-wrong) for how to resolve it. 1. Currently we only provide predicate assertions of arity <= 5. If you need a higher-arity assertion, let us know. _Availability_: Linux, Windows, Mac @@ -263,7 +263,7 @@ int SmallestPrimeCommonDivisor(int m, int n) { ... } int n) { if (MutuallyPrime(m, n)) return ::testing::AssertionSuccess(); - + return ::testing::AssertionFailure() << m_expr << " and " << n_expr << " (" << m << " and " << n << ") are not mutually prime, " << "as they have a common divisor " @@ -444,7 +444,7 @@ Since these precondition checks cause the processes to die, we call such tests _death tests_. More generally, any test that checks that a program terminates in an expected fashion is also a death test. -If you want to test `EXPECT_*()/ASSERT_*()` failures in your test code, see [Catching Failures](#Catching_Failures.md). +If you want to test `EXPECT_*()/ASSERT_*()` failures in your test code, see [Catching Failures](#catching-failures). ## How to Write a Death Test ## @@ -729,7 +729,7 @@ For example, 11: EXPECT_EQ(1, Bar(n)); 12: EXPECT_EQ(2, Bar(n + 1)); 13: } -14: +14: 15: TEST(FooTest, Bar) { 16: { 17: SCOPED_TRACE("A"); // This trace point will be included in @@ -1114,9 +1114,9 @@ which are all in the `testing` namespace: | `Values(v1, v2, ..., vN)` | Yields values `{v1, v2, ..., vN}`. | | `ValuesIn(container)` and `ValuesIn(begin, end)` | Yields values from a C-style array, an STL-style container, or an iterator range `[begin, end)`. | | `Bool()` | Yields sequence `{false, true}`. | -| `Combine(g1, g2, ..., gN)` | Yields all combinations (the Cartesian product for the math savvy) of the values generated by the `N` generators. This is only available if your system provides the `<tr1/tuple>` header. If you are sure your system does, and Google Test disagrees, you can override it by defining `GTEST_HAS_TR1_TUPLE=1`. See comments in [include/gtest/internal/gtest-port.h](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/internal/gtest-port.h) for more information. | +| `Combine(g1, g2, ..., gN)` | Yields all combinations (the Cartesian product for the math savvy) of the values generated by the `N` generators. This is only available if your system provides the `<tr1/tuple>` header. If you are sure your system does, and Google Test disagrees, you can override it by defining `GTEST_HAS_TR1_TUPLE=1`. See comments in [include/gtest/internal/gtest-port.h](../include/gtest/internal/gtest-port.h) for more information. | -For more details, see the comments at the definitions of these functions in the [source code](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/gtest-param-test.h). +For more details, see the comments at the definitions of these functions in the [source code](../include/gtest/gtest-param-test.h). The following statement will instantiate tests from the `FooTest` test case each with parameter values `"meeny"`, `"miny"`, and `"moe"`. @@ -1141,7 +1141,7 @@ names: * `InstantiationName/FooTest.HasBlahBlah/1` for `"miny"` * `InstantiationName/FooTest.HasBlahBlah/2` for `"moe"` -You can use these names in [--gtest\_filter](#Running_a_Subset_of_the_Tests.md). +You can use these names in [--gtest\-filter](#running-a-subset-of-the-tests). This statement will instantiate all tests from `FooTest` again, each with parameter values `"cat"` and `"dog"`: @@ -1164,8 +1164,8 @@ tests in the given test case, whether their definitions come before or _after_ the `INSTANTIATE_TEST_CASE_P` statement. You can see -[these](http://code.google.com/p/googletest/source/browse/trunk/samples/sample7_unittest.cc) -[files](http://code.google.com/p/googletest/source/browse/trunk/samples/sample8_unittest.cc) for more examples. +[these](../samples/sample7_unittest.cc) +[files](../samples/sample8_unittest.cc) for more examples. _Availability_: Linux, Windows (requires MSVC 8.0 or above), Mac; since version 1.2.0. @@ -1561,8 +1561,8 @@ _Availability:_ Linux, Windows, Mac; since v1.4.0. ## Defining Event Listeners ## To define a event listener, you subclass either -[testing::TestEventListener](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/gtest.h#855) -or [testing::EmptyTestEventListener](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/gtest.h#905). +[testing::TestEventListener](../include/gtest/gtest.h#L855) +or [testing::EmptyTestEventListener](../include/gtest/gtest.h#L905). The former is an (abstract) interface, where <i>each pure virtual method<br> can be overridden to handle a test event</i> (For example, when a test starts, the `OnTestStart()` method will be called.). The latter provides @@ -1571,10 +1571,10 @@ subclass only needs to override the methods it cares about. When an event is fired, its context is passed to the handler function as an argument. The following argument types are used: - * [UnitTest](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/gtest.h#1007) reflects the state of the entire test program, - * [TestCase](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/gtest.h#689) has information about a test case, which can contain one or more tests, - * [TestInfo](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/gtest.h#599) contains the state of a test, and - * [TestPartResult](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/gtest-test-part.h#42) represents the result of a test assertion. + * [UnitTest](../include/gtest/gtest.h#L1007) reflects the state of the entire test program, + * [TestCase](../include/gtest/gtest.h#L689) has information about a test case, which can contain one or more tests, + * [TestInfo](../include/gtest/gtest.h#L599) contains the state of a test, and + * [TestPartResult](../include/gtest/gtest-test-part.h#L42) represents the result of a test assertion. An event handler function can examine the argument it receives to find out interesting information about the event and the test program's @@ -1610,7 +1610,7 @@ state. Here's an example: To use the event listener you have defined, add an instance of it to the Google Test event listener list (represented by class -[TestEventListeners](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/gtest.h#929) +[TestEventListeners](../include/gtest/gtest.h#L929) - note the "s" at the end of the name) in your `main()` function, before calling `RUN_ALL_TESTS()`: ``` @@ -1638,7 +1638,7 @@ event listener list and delete it. You can do so by adding one line: Now, sit back and enjoy a completely different output from your tests. For more details, you can read this -[sample](http://code.google.com/p/googletest/source/browse/trunk/samples/sample9_unittest.cc). +[sample](../samples/sample9_unittest.cc). You may append more than one listener to the list. When an `On*Start()` or `OnTestPartResult()` event is fired, the listeners will receive it in @@ -1663,7 +1663,7 @@ failures. This ensures that failures generated by the latter are attributed to the right test by the former. We have a sample of failure-raising listener -[here](http://code.google.com/p/googletest/source/browse/trunk/samples/sample10_unittest.cc). +[here](../samples/sample10_unittest.cc). # Running Test Programs: Advanced Options # @@ -1783,12 +1783,12 @@ _Availability:_ Linux, Windows, Mac. ### Temporarily Enabling Disabled Tests ### -To include [disabled tests](#Temporarily_Disabling_Tests.md) in test +To include [disabled tests](#temporarily-disabling-tests) in test execution, just invoke the test program with the `--gtest_also_run_disabled_tests` flag or set the `GTEST_ALSO_RUN_DISABLED_TESTS` environment variable to a value other than `0`. You can combine this with the -[--gtest\_filter](#Running_a_Subset_of_the_Tests.md) flag to further select +[--gtest\_filter](#running-a-subset-of-the-tests) flag to further select which disabled tests to run. _Availability:_ Linux, Windows, Mac; since version 1.3.0. @@ -2086,11 +2086,11 @@ and you should see an `OUTPUT_DIR` directory being created with files `gtest/gtest.h` and `gtest/gtest-all.cc` in it. These files contain everything you need to use Google Test. Just copy them to anywhere you want and you are ready to write tests. You can use the -[scrpts/test/Makefile](http://code.google.com/p/googletest/source/browse/trunk/scripts/test/Makefile) +[scrpts/test/Makefile](../scripts/test/Makefile) file as an example on how to compile your tests against them. # Where to Go from Here # Congratulations! You've now learned more advanced Google Test tools and are ready to tackle more complex testing tasks. If you want to dive even deeper, you -can read the [FAQ](V1_5_FAQ.md).
\ No newline at end of file +can read the [FAQ](V1_5_FAQ.md). diff --git a/googletest/docs/V1_5_FAQ.md b/googletest/docs/V1_5_FAQ.md index 014dba20..e870aff0 100644 --- a/googletest/docs/V1_5_FAQ.md +++ b/googletest/docs/V1_5_FAQ.md @@ -104,7 +104,7 @@ we don't have a convention on the order of the two arguments for twice in the implementation, making it even harder to understand and maintain. We believe the benefit doesn't justify the cost. -Finally, with the growth of Google Mock's [matcher](http://code.google.com/p/googlemock/wiki/CookBook#Using_Matchers_in_Google_Test_Assertions) library, we are +Finally, with the growth of Google Mock's [matcher](../../CookBook.md#using-matchers-in-google-test-assertions) library, we are encouraging people to use the unified `EXPECT_THAT(value, matcher)` syntax more often in tests. One significant advantage of the matcher approach is that matchers can be easily combined to form new matchers, @@ -651,7 +651,7 @@ EXPECT_TRUE(internal::Func(12345)); ## I would like to run a test several times with different parameters. Do I need to write several similar copies of it? ## -No. You can use a feature called [value-parameterized tests](V1_5_AdvancedGuide#Value_Parameterized_Tests.md) which +No. You can use a feature called [value-parameterized tests](V1_5_AdvancedGuide.md#Value_Parameterized_Tests) which lets you repeat your tests with different parameters, without defining it more than once. ## How do I test a file that defines main()? ## @@ -701,6 +701,7 @@ reference global and/or local variables, and can be: * a compound statement. > Some examples are shown here: + ``` // A death test can be a simple function call. TEST(MyDeathTest, FunctionCall) { @@ -744,7 +745,7 @@ On POSIX systems, Google Test uses the POSIX Extended regular expression syntax (http://en.wikipedia.org/wiki/Regular_expression#POSIX_Extended_Regular_Expressions). On Windows, it uses a limited variant of regular expression syntax. For -more details, see the [regular expression syntax](V1_5_AdvancedGuide#Regular_Expression_Syntax.md). +more details, see the [regular expression syntax](V1_5_AdvancedGuide.md#Regular_Expression_Syntax). ## I have a fixture class Foo, but TEST\_F(Foo, Bar) gives me error "no matching function for call to Foo::Foo()". Why? ## @@ -851,7 +852,7 @@ 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](V1_5_Primer#Important_note_for_Visual_C++_users.md) on +[warning](V1_5_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. ## @@ -882,4 +883,4 @@ not enough information in your question): * 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. diff --git a/googletest/docs/V1_5_Primer.md b/googletest/docs/V1_5_Primer.md index 5c42e0b8..6960d2ce 100644 --- a/googletest/docs/V1_5_Primer.md +++ b/googletest/docs/V1_5_Primer.md @@ -251,7 +251,7 @@ To create a fixture, just: 1. Derive a class from `::testing::Test` . Start its body with `protected:` or `public:` as we'll want to access fixture members from sub-classes. 1. Inside the class, declare any objects you plan to use. 1. If necessary, write a default constructor or `SetUp()` function to prepare the objects for each test. A common mistake is to spell `SetUp()` as `Setup()` with a small `u` - don't let that happen to you. - 1. If necessary, write a destructor or `TearDown()` function to release any resources you allocated in `SetUp()` . To learn when you should use the constructor/destructor and when you should use `SetUp()/TearDown()`, read this [FAQ entry](http://code.google.com/p/googletest/wiki/V1_5_FAQ#Should_I_use_the_constructor/destructor_of_the_test_fixture_or_t). + 1. If necessary, write a destructor or `TearDown()` function to release any resources you allocated in `SetUp()` . To learn when you should use the constructor/destructor and when you should use `SetUp()/TearDown()`, read this [FAQ entry](V1_5_FAQ.md#should-i-use-the-constructordestructor-of-the-test-fixture-or-the-set-uptear-down-function). 1. If needed, define subroutines for your tests to share. When using a fixture, use `TEST_F()` instead of `TEST()` as it allows you to @@ -494,4 +494,4 @@ is currently _unsafe_ to use Google Test assertions from two threads concurrently on other systems (e.g. Windows). In most tests this is not an issue as usually the assertions are done in the main thread. If you want to help, you can volunteer to implement the necessary -synchronization primitives in `gtest-port.h` for your platform.
\ No newline at end of file +synchronization primitives in `gtest-port.h` for your platform. diff --git a/googletest/docs/V1_6_AdvancedGuide.md b/googletest/docs/V1_6_AdvancedGuide.md index 44e0d6f5..5225341a 100644 --- a/googletest/docs/V1_6_AdvancedGuide.md +++ b/googletest/docs/V1_6_AdvancedGuide.md @@ -123,7 +123,7 @@ c is 10<br> **Notes:** - 1. If you see a compiler error "no matching function to call" when using `ASSERT_PRED*` or `EXPECT_PRED*`, please see [this](http://code.google.com/p/googletest/wiki/V1_6_FAQ#The_compiler_complains_%22no_matching_function_to_call%22) for how to resolve it. + 1. If you see a compiler error "no matching function to call" when using `ASSERT_PRED*` or `EXPECT_PRED*`, please see [this](v1_6_FAQ.md#ithe-compiler-complains-about-undefined-references-to-some-static-const-member-variables-but-i-did-define-them-in-the-class-body-whats-wrong) for how to resolve it. 1. Currently we only provide predicate assertions of arity <= 5. If you need a higher-arity assertion, let us know. _Availability_: Linux, Windows, Mac @@ -263,7 +263,7 @@ int SmallestPrimeCommonDivisor(int m, int n) { ... } int n) { if (MutuallyPrime(m, n)) return ::testing::AssertionSuccess(); - + return ::testing::AssertionFailure() << m_expr << " and " << n_expr << " (" << m << " and " << n << ") are not mutually prime, " << "as they have a common divisor " @@ -515,9 +515,9 @@ _death tests_. More generally, any test that checks that a program terminates Note that if a piece of code throws an exception, we don't consider it "death" for the purpose of death tests, as the caller of the code could catch the exception and avoid the crash. If you want to verify exceptions thrown by your code, -see [Exception Assertions](#Exception_Assertions.md). +see [Exception Assertions](#exception-assertions). -If you want to test `EXPECT_*()/ASSERT_*()` failures in your test code, see [Catching Failures](#Catching_Failures.md). +If you want to test `EXPECT_*()/ASSERT_*()` failures in your test code, see [Catching Failures](#catching-failures). ## How to Write a Death Test ## @@ -801,7 +801,7 @@ For example, 11: EXPECT_EQ(1, Bar(n)); 12: EXPECT_EQ(2, Bar(n + 1)); 13: } -14: +14: 15: TEST(FooTest, Bar) { 16: { 17: SCOPED_TRACE("A"); // This trace point will be included in @@ -1196,9 +1196,9 @@ which are all in the `testing` namespace: | `Values(v1, v2, ..., vN)` | Yields values `{v1, v2, ..., vN}`. | | `ValuesIn(container)` and `ValuesIn(begin, end)` | Yields values from a C-style array, an STL-style container, or an iterator range `[begin, end)`. `container`, `begin`, and `end` can be expressions whose values are determined at run time. | | `Bool()` | Yields sequence `{false, true}`. | -| `Combine(g1, g2, ..., gN)` | Yields all combinations (the Cartesian product for the math savvy) of the values generated by the `N` generators. This is only available if your system provides the `<tr1/tuple>` header. If you are sure your system does, and Google Test disagrees, you can override it by defining `GTEST_HAS_TR1_TUPLE=1`. See comments in [include/gtest/internal/gtest-port.h](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/internal/gtest-port.h) for more information. | +| `Combine(g1, g2, ..., gN)` | Yields all combinations (the Cartesian product for the math savvy) of the values generated by the `N` generators. This is only available if your system provides the `<tr1/tuple>` header. If you are sure your system does, and Google Test disagrees, you can override it by defining `GTEST_HAS_TR1_TUPLE=1`. See comments in [include/gtest/internal/gtest-port.h](../include/gtest/internal/gtest-port.h) for more information. | -For more details, see the comments at the definitions of these functions in the [source code](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/gtest-param-test.h). +For more details, see the comments at the definitions of these functions in the [source code](../include/gtest/gtest-param-test.h). The following statement will instantiate tests from the `FooTest` test case each with parameter values `"meeny"`, `"miny"`, and `"moe"`. @@ -1223,7 +1223,7 @@ names: * `InstantiationName/FooTest.HasBlahBlah/1` for `"miny"` * `InstantiationName/FooTest.HasBlahBlah/2` for `"moe"` -You can use these names in [--gtest\_filter](#Running_a_Subset_of_the_Tests.md). +You can use these names in [--gtest\-filter](#running-a-subset-of-the-tests). This statement will instantiate all tests from `FooTest` again, each with parameter values `"cat"` and `"dog"`: @@ -1246,8 +1246,8 @@ tests in the given test case, whether their definitions come before or _after_ the `INSTANTIATE_TEST_CASE_P` statement. You can see -[these](http://code.google.com/p/googletest/source/browse/trunk/samples/sample7_unittest.cc) -[files](http://code.google.com/p/googletest/source/browse/trunk/samples/sample8_unittest.cc) for more examples. +[these](../samples/sample7_unittest.cc) +[files](../samples/sample8_unittest.cc) for more examples. _Availability_: Linux, Windows (requires MSVC 8.0 or above), Mac; since version 1.2.0. @@ -1643,8 +1643,8 @@ _Availability:_ Linux, Windows, Mac; since v1.4.0. ## Defining Event Listeners ## To define a event listener, you subclass either -[testing::TestEventListener](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/gtest.h#855) -or [testing::EmptyTestEventListener](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/gtest.h#905). +[testing::TestEventListener](../include/gtest/gtest.h#L855) +or [testing::EmptyTestEventListener](../include/gtest/gtest.h#L905). The former is an (abstract) interface, where <i>each pure virtual method<br> can be overridden to handle a test event</i> (For example, when a test starts, the `OnTestStart()` method will be called.). The latter provides @@ -1653,10 +1653,10 @@ subclass only needs to override the methods it cares about. When an event is fired, its context is passed to the handler function as an argument. The following argument types are used: - * [UnitTest](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/gtest.h#1007) reflects the state of the entire test program, - * [TestCase](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/gtest.h#689) has information about a test case, which can contain one or more tests, - * [TestInfo](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/gtest.h#599) contains the state of a test, and - * [TestPartResult](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/gtest-test-part.h#42) represents the result of a test assertion. + * [UnitTest](../include/gtest/gtest.h#L1007) reflects the state of the entire test program, + * [TestCase](../include/gtest/gtest.h#L689) has information about a test case, which can contain one or more tests, + * [TestInfo](../include/gtest/gtest.h#L599) contains the state of a test, and + * [TestPartResult](../include/gtest/gtest-test-part.h#L42) represents the result of a test assertion. An event handler function can examine the argument it receives to find out interesting information about the event and the test program's @@ -1692,7 +1692,7 @@ state. Here's an example: To use the event listener you have defined, add an instance of it to the Google Test event listener list (represented by class -[TestEventListeners](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/gtest.h#929) +[TestEventListeners](../include/gtest/gtest.h#L929) - note the "s" at the end of the name) in your `main()` function, before calling `RUN_ALL_TESTS()`: ``` @@ -1720,7 +1720,7 @@ event listener list and delete it. You can do so by adding one line: Now, sit back and enjoy a completely different output from your tests. For more details, you can read this -[sample](http://code.google.com/p/googletest/source/browse/trunk/samples/sample9_unittest.cc). +[sample](../samples/sample9_unittest.cc). You may append more than one listener to the list. When an `On*Start()` or `OnTestPartResult()` event is fired, the listeners will receive it in @@ -1745,7 +1745,7 @@ failures. This ensures that failures generated by the latter are attributed to the right test by the former. We have a sample of failure-raising listener -[here](http://code.google.com/p/googletest/source/browse/trunk/samples/sample10_unittest.cc). +[here](../samples/sample10_unittest.cc). # Running Test Programs: Advanced Options # @@ -1865,12 +1865,12 @@ _Availability:_ Linux, Windows, Mac. ### Temporarily Enabling Disabled Tests ### -To include [disabled tests](#Temporarily_Disabling_Tests.md) in test +To include [disabled tests](#temporarily-disabling-tests) in test execution, just invoke the test program with the `--gtest_also_run_disabled_tests` flag or set the `GTEST_ALSO_RUN_DISABLED_TESTS` environment variable to a value other than `0`. You can combine this with the -[--gtest\_filter](#Running_a_Subset_of_the_Tests.md) flag to further select +[--gtest\-filter](#running-a-subset-of-the_tests) flag to further select which disabled tests to run. _Availability:_ Linux, Windows, Mac; since version 1.3.0. @@ -2168,11 +2168,11 @@ and you should see an `OUTPUT_DIR` directory being created with files `gtest/gtest.h` and `gtest/gtest-all.cc` in it. These files contain everything you need to use Google Test. Just copy them to anywhere you want and you are ready to write tests. You can use the -[scripts/test/Makefile](http://code.google.com/p/googletest/source/browse/trunk/scripts/test/Makefile) +[scripts/test/Makefile](../scripts/test/Makefile) file as an example on how to compile your tests against them. # Where to Go from Here # Congratulations! You've now learned more advanced Google Test tools and are ready to tackle more complex testing tasks. If you want to dive even deeper, you -can read the [Frequently-Asked Questions](V1_6_FAQ.md).
\ No newline at end of file +can read the [Frequently-Asked Questions](V1_6_FAQ.md). diff --git a/googletest/docs/V1_6_FAQ.md b/googletest/docs/V1_6_FAQ.md index 61677a68..6d5d128a 100644 --- a/googletest/docs/V1_6_FAQ.md +++ b/googletest/docs/V1_6_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/V1_6_AdvancedGuide#Global_Set-Up_and_Tear-Down) and tests parameterized by [values](http://code.google.com/p/googletest/wiki/V1_6_AdvancedGuide#Value_Parameterized_Tests) or [types](http://code.google.com/p/googletest/wiki/V1_6_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/V1_6_AdvancedGuide#Predicate_Assertions_for_Better_Error_Messages), - * teach Google Test how to [print your types](http://code.google.com/p/googletest/wiki/V1_6_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/V1_6_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/V1_6_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](V1_6_AdvancedGuide.md#Global_Set-Up_and_Tear-Down) and tests parameterized by [values](V1_6_AdvancedGuide.md#value-parameterized-tests) or [types](V1_6_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](V1_6_AdvancedGuide.md#predicate-assertions-for-better-error-messages), + * teach Google Test how to [print your types](V1_6_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](V1_6_AdvancedGuide.md#catching-failures), and + * reflect on the test cases or change the test output format by intercepting the [test events](V1_6_AdvancedGuide.md#extending-google-test-by-handling-test-events). ## I'm getting warnings when compiling Google Test. Would you fix them? ## @@ -201,7 +201,7 @@ we don't have a convention on the order of the two arguments for twice in the implementation, making it even harder to understand and maintain. We believe the benefit doesn't justify the cost. -Finally, with the growth of Google Mock's [matcher](http://code.google.com/p/googlemock/wiki/CookBook#Using_Matchers_in_Google_Test_Assertions) library, we are +Finally, with the growth of Google Mock's [matcher](../../CookBook.md#using-matchers-in-google-test-assertions) library, we are encouraging people to use the unified `EXPECT_THAT(value, matcher)` syntax more often in tests. One significant advantage of the matcher approach is that matchers can be easily combined to form new matchers, @@ -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](../samples/sample5_unittest.cc). ## My compiler complains "void value not ignored as it ought to be." What does this mean? ## @@ -748,7 +748,7 @@ EXPECT_TRUE(internal::Func(12345)); ## I would like to run a test several times with different parameters. Do I need to write several similar copies of it? ## -No. You can use a feature called [value-parameterized tests](V1_6_AdvancedGuide#Value_Parameterized_Tests.md) which +No. You can use a feature called [value-parameterized tests](V1_6_AdvancedGuide.md#Value_Parameterized_Tests) which lets you repeat your tests with different parameters, without defining it more than once. ## How do I test a file that defines main()? ## @@ -798,6 +798,7 @@ reference global and/or local variables, and can be: * a compound statement. > Some examples are shown here: + ``` // A death test can be a simple function call. TEST(MyDeathTest, FunctionCall) { @@ -842,7 +843,7 @@ expression syntax (http://en.wikipedia.org/wiki/Regular_expression#POSIX_Extended_Regular_Expressions). On Windows, it uses a limited variant of regular expression syntax. For more details, see the -[regular expression syntax](V1_6_AdvancedGuide#Regular_Expression_Syntax.md). +[regular expression syntax](V1_6_AdvancedGuide.md#Regular_Expression_Syntax). ## I have a fixture class Foo, but TEST\_F(Foo, Bar) gives me error "no matching function for call to Foo::Foo()". Why? ## @@ -949,7 +950,7 @@ 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/V1_6_Primer#Important_note_for_Visual_C++_users) on +[warning](V1_6_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. ## @@ -1034,4 +1035,4 @@ not enough information in your question): * 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. diff --git a/googletest/docs/V1_6_Primer.md b/googletest/docs/V1_6_Primer.md index 2c51a210..8d840ef4 100644 --- a/googletest/docs/V1_6_Primer.md +++ b/googletest/docs/V1_6_Primer.md @@ -146,7 +146,7 @@ but it's no longer necessary since v1.6.0 (if `<<` is supported, it will be called to print the arguments when the assertion fails; otherwise Google Test will attempt to print them in the best way it can. For more details and how to customize the printing of the -arguments, see this Google Mock [recipe](http://code.google.com/p/googlemock/wiki/CookBook#Teaching_Google_Mock_How_to_Print_Your_Values).). +arguments, see this Google Mock [recipe](../../googlemock/docs/CookBook.md#teaching-google-mock-how-to-print-your-values).). These assertions can work with a user-defined type, but only if you define the corresponding comparison operator (e.g. `==`, `<`, etc). If the corresponding @@ -255,7 +255,7 @@ To create a fixture, just: 1. Derive a class from `::testing::Test` . Start its body with `protected:` or `public:` as we'll want to access fixture members from sub-classes. 1. Inside the class, declare any objects you plan to use. 1. If necessary, write a default constructor or `SetUp()` function to prepare the objects for each test. A common mistake is to spell `SetUp()` as `Setup()` with a small `u` - don't let that happen to you. - 1. If necessary, write a destructor or `TearDown()` function to release any resources you allocated in `SetUp()` . To learn when you should use the constructor/destructor and when you should use `SetUp()/TearDown()`, read this [FAQ entry](http://code.google.com/p/googletest/wiki/V1_6_FAQ#Should_I_use_the_constructor/destructor_of_the_test_fixture_or_t). + 1. If necessary, write a destructor or `TearDown()` function to release any resources you allocated in `SetUp()` . To learn when you should use the constructor/destructor and when you should use `SetUp()/TearDown()`, read this [FAQ entry](V1_6_FAQ.md#should-i-use-the-constructordestructor-of-the-test-fixture-or-the-set-uptear-down-function). 1. If needed, define subroutines for your tests to share. When using a fixture, use `TEST_F()` instead of `TEST()` as it allows you to @@ -498,4 +498,4 @@ is currently _unsafe_ to use Google Test assertions from two threads concurrently on other systems (e.g. Windows). In most tests this is not an issue as usually the assertions are done in the main thread. If you want to help, you can volunteer to implement the necessary -synchronization primitives in `gtest-port.h` for your platform.
\ No newline at end of file +synchronization primitives in `gtest-port.h` for your platform. diff --git a/googletest/docs/V1_6_PumpManual.md b/googletest/docs/V1_6_PumpManual.md index cf6cf56b..8184f153 100644 --- a/googletest/docs/V1_6_PumpManual.md +++ b/googletest/docs/V1_6_PumpManual.md @@ -161,7 +161,7 @@ exp ::= simple_expression_in_Python_syntax ## Code ## -You can find the source code of Pump in [scripts/pump.py](http://code.google.com/p/googletest/source/browse/trunk/scripts/pump.py). It is still +You can find the source code of Pump in [scripts/pump.py](../scripts/pump.py). It is still very unpolished and lacks automated tests, although it has been successfully used many times. If you find a chance to use it in your project, please let us know what you think! We also welcome help on @@ -174,4 +174,4 @@ You can find real-world applications of Pump in [Google Test](http://www.google. ## Tips ## * If a meta variable is followed by a letter or digit, you can separate them using `[[]]`, which inserts an empty string. For example `Foo$j[[]]Helper` generate `Foo1Helper` when `j` is 1. - * To avoid extra-long Pump source lines, you can break a line anywhere you want by inserting `[[]]` followed by a new line. Since any new-line character next to `[[` or `]]` is ignored, the generated code won't contain this new line.
\ No newline at end of file + * To avoid extra-long Pump source lines, you can break a line anywhere you want by inserting `[[]]` followed by a new line. Since any new-line character next to `[[` or `]]` is ignored, the generated code won't contain this new line. diff --git a/googletest/docs/V1_6_Samples.md b/googletest/docs/V1_6_Samples.md index 81225694..f21d2005 100644 --- a/googletest/docs/V1_6_Samples.md +++ b/googletest/docs/V1_6_Samples.md @@ -1,14 +1,14 @@ If you're like us, you'd like to look at some Google Test sample code. The -[samples folder](http://code.google.com/p/googletest/source/browse/#svn/trunk/samples) has a number of well-commented samples showing how to use a +[samples folder](../samples) has a number of well-commented samples showing how to use a variety of Google Test features. - * [Sample #1](http://code.google.com/p/googletest/source/browse/trunk/samples/sample1_unittest.cc) shows the basic steps of using Google Test to test C++ functions. - * [Sample #2](http://code.google.com/p/googletest/source/browse/trunk/samples/sample2_unittest.cc) shows a more complex unit test for a class with multiple member functions. - * [Sample #3](http://code.google.com/p/googletest/source/browse/trunk/samples/sample3_unittest.cc) uses a test fixture. - * [Sample #4](http://code.google.com/p/googletest/source/browse/trunk/samples/sample4_unittest.cc) is another basic example of using Google Test. - * [Sample #5](http://code.google.com/p/googletest/source/browse/trunk/samples/sample5_unittest.cc) teaches how to reuse a test fixture in multiple test cases by deriving sub-fixtures from it. - * [Sample #6](http://code.google.com/p/googletest/source/browse/trunk/samples/sample6_unittest.cc) demonstrates type-parameterized tests. - * [Sample #7](http://code.google.com/p/googletest/source/browse/trunk/samples/sample7_unittest.cc) teaches the basics of value-parameterized tests. - * [Sample #8](http://code.google.com/p/googletest/source/browse/trunk/samples/sample8_unittest.cc) shows using `Combine()` in value-parameterized tests. - * [Sample #9](http://code.google.com/p/googletest/source/browse/trunk/samples/sample9_unittest.cc) shows use of the listener API to modify Google Test's console output and the use of its reflection API to inspect test results. - * [Sample #10](http://code.google.com/p/googletest/source/browse/trunk/samples/sample10_unittest.cc) shows use of the listener API to implement a primitive memory leak checker.
\ No newline at end of file + * [Sample #1](../samples/sample1_unittest.cc) shows the basic steps of using Google Test to test C++ functions. + * [Sample #2](../samples/sample2_unittest.cc) shows a more complex unit test for a class with multiple member functions. + * [Sample #3](../samples/sample3_unittest.cc) uses a test fixture. + * [Sample #4](../samples/sample4_unittest.cc) is another basic example of using Google Test. + * [Sample #5](../samples/sample5_unittest.cc) teaches how to reuse a test fixture in multiple test cases by deriving sub-fixtures from it. + * [Sample #6](../samples/sample6_unittest.cc) demonstrates type-parameterized tests. + * [Sample #7](../samples/sample7_unittest.cc) teaches the basics of value-parameterized tests. + * [Sample #8](../samples/sample8_unittest.cc) shows using `Combine()` in value-parameterized tests. + * [Sample #9](../samples/sample9_unittest.cc) shows use of the listener API to modify Google Test's console output and the use of its reflection API to inspect test results. + * [Sample #10](../samples/sample10_unittest.cc) shows use of the listener API to implement a primitive memory leak checker. diff --git a/googletest/docs/V1_7_AdvancedGuide.md b/googletest/docs/V1_7_AdvancedGuide.md index a3d64624..83a8f798 100644 --- a/googletest/docs/V1_7_AdvancedGuide.md +++ b/googletest/docs/V1_7_AdvancedGuide.md @@ -123,7 +123,7 @@ c is 10<br> **Notes:** - 1. If you see a compiler error "no matching function to call" when using `ASSERT_PRED*` or `EXPECT_PRED*`, please see [this](http://code.google.com/p/googletest/wiki/V1_7_FAQ#The_compiler_complains_%22no_matching_function_to_call%22) for how to resolve it. + 1. If you see a compiler error "no matching function to call" when using `ASSERT_PRED*` or `EXPECT_PRED*`, please see [this](V1_7_FAQ.md#the-compiler-complains-about-undefined-references-to-some-static-const-member-variables-but-i-did-define-them-in-the-class-body-whats-wrong) for how to resolve it. 1. Currently we only provide predicate assertions of arity <= 5. If you need a higher-arity assertion, let us know. _Availability_: Linux, Windows, Mac @@ -263,7 +263,7 @@ int SmallestPrimeCommonDivisor(int m, int n) { ... } int n) { if (MutuallyPrime(m, n)) return ::testing::AssertionSuccess(); - + return ::testing::AssertionFailure() << m_expr << " and " << n_expr << " (" << m << " and " << n << ") are not mutually prime, " << "as they have a common divisor " @@ -515,9 +515,9 @@ _death tests_. More generally, any test that checks that a program terminates Note that if a piece of code throws an exception, we don't consider it "death" for the purpose of death tests, as the caller of the code could catch the exception and avoid the crash. If you want to verify exceptions thrown by your code, -see [Exception Assertions](#Exception_Assertions.md). +see [Exception Assertions](#exception-assertions). -If you want to test `EXPECT_*()/ASSERT_*()` failures in your test code, see [Catching Failures](#Catching_Failures.md). +If you want to test `EXPECT_*()/ASSERT_*()` failures in your test code, see [Catching Failures](#catching-failures). ## How to Write a Death Test ## @@ -802,7 +802,7 @@ For example, 11: EXPECT_EQ(1, Bar(n)); 12: EXPECT_EQ(2, Bar(n + 1)); 13: } -14: +14: 15: TEST(FooTest, Bar) { 16: { 17: SCOPED_TRACE("A"); // This trace point will be included in @@ -1197,9 +1197,9 @@ which are all in the `testing` namespace: | `Values(v1, v2, ..., vN)` | Yields values `{v1, v2, ..., vN}`. | | `ValuesIn(container)` and `ValuesIn(begin, end)` | Yields values from a C-style array, an STL-style container, or an iterator range `[begin, end)`. `container`, `begin`, and `end` can be expressions whose values are determined at run time. | | `Bool()` | Yields sequence `{false, true}`. | -| `Combine(g1, g2, ..., gN)` | Yields all combinations (the Cartesian product for the math savvy) of the values generated by the `N` generators. This is only available if your system provides the `<tr1/tuple>` header. If you are sure your system does, and Google Test disagrees, you can override it by defining `GTEST_HAS_TR1_TUPLE=1`. See comments in [include/gtest/internal/gtest-port.h](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/internal/gtest-port.h) for more information. | +| `Combine(g1, g2, ..., gN)` | Yields all combinations (the Cartesian product for the math savvy) of the values generated by the `N` generators. This is only available if your system provides the `<tr1/tuple>` header. If you are sure your system does, and Google Test disagrees, you can override it by defining `GTEST_HAS_TR1_TUPLE=1`. See comments in [include/gtest/internal/gtest-port.h](../include/gtest/internal/gtest-port.h) for more information. | -For more details, see the comments at the definitions of these functions in the [source code](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/gtest-param-test.h). +For more details, see the comments at the definitions of these functions in the [source code](../include/gtest/gtest-param-test.h). The following statement will instantiate tests from the `FooTest` test case each with parameter values `"meeny"`, `"miny"`, and `"moe"`. @@ -1224,7 +1224,7 @@ names: * `InstantiationName/FooTest.HasBlahBlah/1` for `"miny"` * `InstantiationName/FooTest.HasBlahBlah/2` for `"moe"` -You can use these names in [--gtest\_filter](#Running_a_Subset_of_the_Tests.md). +You can use these names in [--gtest\_filter](#running-a-subset-of-the-tests). This statement will instantiate all tests from `FooTest` again, each with parameter values `"cat"` and `"dog"`: @@ -1247,8 +1247,8 @@ tests in the given test case, whether their definitions come before or _after_ the `INSTANTIATE_TEST_CASE_P` statement. You can see -[these](http://code.google.com/p/googletest/source/browse/trunk/samples/sample7_unittest.cc) -[files](http://code.google.com/p/googletest/source/browse/trunk/samples/sample8_unittest.cc) for more examples. +[these](../samples/sample7_unittest.cc) +[files](../samples/sample8_unittest.cc) for more examples. _Availability_: Linux, Windows (requires MSVC 8.0 or above), Mac; since version 1.2.0. @@ -1644,8 +1644,8 @@ _Availability:_ Linux, Windows, Mac; since v1.4.0. ## Defining Event Listeners ## To define a event listener, you subclass either -[testing::TestEventListener](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/gtest.h#855) -or [testing::EmptyTestEventListener](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/gtest.h#905). +[testing::TestEventListener](../include/gtest/gtest.h#L855) +or [testing::EmptyTestEventListener](../include/gtest/gtest.h#L905). The former is an (abstract) interface, where <i>each pure virtual method<br> can be overridden to handle a test event</i> (For example, when a test starts, the `OnTestStart()` method will be called.). The latter provides @@ -1654,10 +1654,10 @@ subclass only needs to override the methods it cares about. When an event is fired, its context is passed to the handler function as an argument. The following argument types are used: - * [UnitTest](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/gtest.h#1007) reflects the state of the entire test program, - * [TestCase](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/gtest.h#689) has information about a test case, which can contain one or more tests, - * [TestInfo](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/gtest.h#599) contains the state of a test, and - * [TestPartResult](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/gtest-test-part.h#42) represents the result of a test assertion. + * [UnitTest](../include/gtest/gtest.h#L1007) reflects the state of the entire test program, + * [TestCase](../include/gtest/gtest.h#L689) has information about a test case, which can contain one or more tests, + * [TestInfo](../include/gtest/gtest.h#L599) contains the state of a test, and + * [TestPartResult](../include/gtest/gtest-test-part.h#L42) represents the result of a test assertion. An event handler function can examine the argument it receives to find out interesting information about the event and the test program's @@ -1693,7 +1693,7 @@ state. Here's an example: To use the event listener you have defined, add an instance of it to the Google Test event listener list (represented by class -[TestEventListeners](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/gtest.h#929) +[TestEventListeners](../include/gtest/gtest.h#L929) - note the "s" at the end of the name) in your `main()` function, before calling `RUN_ALL_TESTS()`: ``` @@ -1721,7 +1721,7 @@ event listener list and delete it. You can do so by adding one line: Now, sit back and enjoy a completely different output from your tests. For more details, you can read this -[sample](http://code.google.com/p/googletest/source/browse/trunk/samples/sample9_unittest.cc). +[sample](../samples/sample9_unittest.cc). You may append more than one listener to the list. When an `On*Start()` or `OnTestPartResult()` event is fired, the listeners will receive it in @@ -1746,7 +1746,7 @@ failures. This ensures that failures generated by the latter are attributed to the right test by the former. We have a sample of failure-raising listener -[here](http://code.google.com/p/googletest/source/browse/trunk/samples/sample10_unittest.cc). +[here](../samples/sample10_unittest.cc). # Running Test Programs: Advanced Options # @@ -1866,12 +1866,12 @@ _Availability:_ Linux, Windows, Mac. ### Temporarily Enabling Disabled Tests ### -To include [disabled tests](#Temporarily_Disabling_Tests.md) in test +To include [disabled tests](#temporarily-disabling-tests) in test execution, just invoke the test program with the `--gtest_also_run_disabled_tests` flag or set the `GTEST_ALSO_RUN_DISABLED_TESTS` environment variable to a value other than `0`. You can combine this with the -[--gtest\_filter](#Running_a_Subset_of_the_Tests.md) flag to further select +[--gtest\_filter](#running-a-subset-of-the-tests) flag to further select which disabled tests to run. _Availability:_ Linux, Windows, Mac; since version 1.3.0. @@ -2171,11 +2171,11 @@ and you should see an `OUTPUT_DIR` directory being created with files `gtest/gtest.h` and `gtest/gtest-all.cc` in it. These files contain everything you need to use Google Test. Just copy them to anywhere you want and you are ready to write tests. You can use the -[scripts/test/Makefile](http://code.google.com/p/googletest/source/browse/trunk/scripts/test/Makefile) +[scripts/test/Makefile](../scripts/test/Makefile) file as an example on how to compile your tests against them. # Where to Go from Here # Congratulations! You've now learned more advanced Google Test tools and are ready to tackle more complex testing tasks. If you want to dive even deeper, you -can read the [Frequently-Asked Questions](V1_7_FAQ.md).
\ No newline at end of file +can read the [Frequently-Asked Questions](V1_7_FAQ.md). diff --git a/googletest/docs/V1_7_FAQ.md b/googletest/docs/V1_7_FAQ.md index b5d547ce..ded1a48b 100644 --- a/googletest/docs/V1_7_FAQ.md +++ b/googletest/docs/V1_7_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/V1_7_AdvancedGuide#Global_Set-Up_and_Tear-Down) and tests parameterized by [values](http://code.google.com/p/googletest/wiki/V1_7_AdvancedGuide#Value_Parameterized_Tests) or [types](http://code.google.com/p/googletest/wiki/V1_7_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/V1_7_AdvancedGuide#Predicate_Assertions_for_Better_Error_Messages), - * teach Google Test how to [print your types](http://code.google.com/p/googletest/wiki/V1_7_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/V1_7_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/V1_7_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](V1_7_AdvancedGuide.md#global-set-up-and-tear-down) and tests parameterized by [values](V1_7_AdvancedGuide.md#value-parameterized-tests) or [types](V1_7_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](V1_7_AdvancedGuide.md#predicate-assertions-for-better-error-messages), + * teach Google Test how to [print your types](V1_7_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](V1_7_AdvancedGuide.md#catching-failures), and + * reflect on the test cases or change the test output format by intercepting the [test events](V1_7_AdvancedGuide.md#extending-google-test-by-handling-test-events). ## I'm getting warnings when compiling Google Test. Would you fix them? ## @@ -201,7 +201,7 @@ we don't have a convention on the order of the two arguments for twice in the implementation, making it even harder to understand and maintain. We believe the benefit doesn't justify the cost. -Finally, with the growth of Google Mock's [matcher](http://code.google.com/p/googlemock/wiki/CookBook#Using_Matchers_in_Google_Test_Assertions) library, we are +Finally, with the growth of Google Mock's [matcher](../../CookBook.md#using-matchers-in-google-test-assertions) library, we are encouraging people to use the unified `EXPECT_THAT(value, matcher)` syntax more often in tests. One significant advantage of the matcher approach is that matchers can be easily combined to form new matchers, @@ -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](../samples/sample5_unittest.cc). ## My compiler complains "void value not ignored as it ought to be." What does this mean? ## @@ -748,7 +748,7 @@ EXPECT_TRUE(internal::Func(12345)); ## I would like to run a test several times with different parameters. Do I need to write several similar copies of it? ## -No. You can use a feature called [value-parameterized tests](V1_7_AdvancedGuide#Value_Parameterized_Tests.md) which +No. You can use a feature called [value-parameterized tests](V1_7_AdvancedGuide.md#Value_Parameterized_Tests) which lets you repeat your tests with different parameters, without defining it more than once. ## How do I test a file that defines main()? ## @@ -798,6 +798,7 @@ reference global and/or local variables, and can be: * a compound statement. > Some examples are shown here: + ``` // A death test can be a simple function call. TEST(MyDeathTest, FunctionCall) { @@ -842,7 +843,7 @@ expression syntax (http://en.wikipedia.org/wiki/Regular_expression#POSIX_Extended_Regular_Expressions). On Windows, it uses a limited variant of regular expression syntax. For more details, see the -[regular expression syntax](V1_7_AdvancedGuide#Regular_Expression_Syntax.md). +[regular expression syntax](V1_7_AdvancedGuide.md#Regular_Expression_Syntax). ## I have a fixture class Foo, but TEST\_F(Foo, Bar) gives me error "no matching function for call to Foo::Foo()". Why? ## @@ -949,7 +950,7 @@ 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/V1_7_Primer#Important_note_for_Visual_C++_users) on +[warning](V1_7_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. ## @@ -1053,7 +1054,7 @@ 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](../../README.MD) file on how to resolve this. ## My question is not covered in your FAQ! ## @@ -1078,4 +1079,4 @@ not enough information in your question): * 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. diff --git a/googletest/docs/V1_7_Primer.md b/googletest/docs/V1_7_Primer.md index 1de5080a..b1827c73 100644 --- a/googletest/docs/V1_7_Primer.md +++ b/googletest/docs/V1_7_Primer.md @@ -146,7 +146,7 @@ but it's no longer necessary since v1.6.0 (if `<<` is supported, it will be called to print the arguments when the assertion fails; otherwise Google Test will attempt to print them in the best way it can. For more details and how to customize the printing of the -arguments, see this Google Mock [recipe](http://code.google.com/p/googlemock/wiki/CookBook#Teaching_Google_Mock_How_to_Print_Your_Values).). +arguments, see this Google Mock [recipe](../../googlemock/docs/CookBook.md#teaching-google-mock-how-to-print-your-values).). These assertions can work with a user-defined type, but only if you define the corresponding comparison operator (e.g. `==`, `<`, etc). If the corresponding @@ -255,7 +255,7 @@ To create a fixture, just: 1. Derive a class from `::testing::Test` . Start its body with `protected:` or `public:` as we'll want to access fixture members from sub-classes. 1. Inside the class, declare any objects you plan to use. 1. If necessary, write a default constructor or `SetUp()` function to prepare the objects for each test. A common mistake is to spell `SetUp()` as `Setup()` with a small `u` - don't let that happen to you. - 1. If necessary, write a destructor or `TearDown()` function to release any resources you allocated in `SetUp()` . To learn when you should use the constructor/destructor and when you should use `SetUp()/TearDown()`, read this [FAQ entry](http://code.google.com/p/googletest/wiki/V1_7_FAQ#Should_I_use_the_constructor/destructor_of_the_test_fixture_or_t). + 1. If necessary, write a destructor or `TearDown()` function to release any resources you allocated in `SetUp()` . To learn when you should use the constructor/destructor and when you should use `SetUp()/TearDown()`, read this [FAQ entry](V1_7_FAQ.md#should-i-use-the-constructordestructor-of-the-test-fixture-or-the-set-uptear-down-function). 1. If needed, define subroutines for your tests to share. When using a fixture, use `TEST_F()` instead of `TEST()` as it allows you to @@ -498,4 +498,4 @@ is currently _unsafe_ to use Google Test assertions from two threads concurrently on other systems (e.g. Windows). In most tests this is not an issue as usually the assertions are done in the main thread. If you want to help, you can volunteer to implement the necessary -synchronization primitives in `gtest-port.h` for your platform.
\ No newline at end of file +synchronization primitives in `gtest-port.h` for your platform. diff --git a/googletest/docs/V1_7_PumpManual.md b/googletest/docs/V1_7_PumpManual.md index cf6cf56b..8184f153 100644 --- a/googletest/docs/V1_7_PumpManual.md +++ b/googletest/docs/V1_7_PumpManual.md @@ -161,7 +161,7 @@ exp ::= simple_expression_in_Python_syntax ## Code ## -You can find the source code of Pump in [scripts/pump.py](http://code.google.com/p/googletest/source/browse/trunk/scripts/pump.py). It is still +You can find the source code of Pump in [scripts/pump.py](../scripts/pump.py). It is still very unpolished and lacks automated tests, although it has been successfully used many times. If you find a chance to use it in your project, please let us know what you think! We also welcome help on @@ -174,4 +174,4 @@ You can find real-world applications of Pump in [Google Test](http://www.google. ## Tips ## * If a meta variable is followed by a letter or digit, you can separate them using `[[]]`, which inserts an empty string. For example `Foo$j[[]]Helper` generate `Foo1Helper` when `j` is 1. - * To avoid extra-long Pump source lines, you can break a line anywhere you want by inserting `[[]]` followed by a new line. Since any new-line character next to `[[` or `]]` is ignored, the generated code won't contain this new line.
\ No newline at end of file + * To avoid extra-long Pump source lines, you can break a line anywhere you want by inserting `[[]]` followed by a new line. Since any new-line character next to `[[` or `]]` is ignored, the generated code won't contain this new line. diff --git a/googletest/docs/V1_7_Samples.md b/googletest/docs/V1_7_Samples.md index 81225694..f21d2005 100644 --- a/googletest/docs/V1_7_Samples.md +++ b/googletest/docs/V1_7_Samples.md @@ -1,14 +1,14 @@ If you're like us, you'd like to look at some Google Test sample code. The -[samples folder](http://code.google.com/p/googletest/source/browse/#svn/trunk/samples) has a number of well-commented samples showing how to use a +[samples folder](../samples) has a number of well-commented samples showing how to use a variety of Google Test features. - * [Sample #1](http://code.google.com/p/googletest/source/browse/trunk/samples/sample1_unittest.cc) shows the basic steps of using Google Test to test C++ functions. - * [Sample #2](http://code.google.com/p/googletest/source/browse/trunk/samples/sample2_unittest.cc) shows a more complex unit test for a class with multiple member functions. - * [Sample #3](http://code.google.com/p/googletest/source/browse/trunk/samples/sample3_unittest.cc) uses a test fixture. - * [Sample #4](http://code.google.com/p/googletest/source/browse/trunk/samples/sample4_unittest.cc) is another basic example of using Google Test. - * [Sample #5](http://code.google.com/p/googletest/source/browse/trunk/samples/sample5_unittest.cc) teaches how to reuse a test fixture in multiple test cases by deriving sub-fixtures from it. - * [Sample #6](http://code.google.com/p/googletest/source/browse/trunk/samples/sample6_unittest.cc) demonstrates type-parameterized tests. - * [Sample #7](http://code.google.com/p/googletest/source/browse/trunk/samples/sample7_unittest.cc) teaches the basics of value-parameterized tests. - * [Sample #8](http://code.google.com/p/googletest/source/browse/trunk/samples/sample8_unittest.cc) shows using `Combine()` in value-parameterized tests. - * [Sample #9](http://code.google.com/p/googletest/source/browse/trunk/samples/sample9_unittest.cc) shows use of the listener API to modify Google Test's console output and the use of its reflection API to inspect test results. - * [Sample #10](http://code.google.com/p/googletest/source/browse/trunk/samples/sample10_unittest.cc) shows use of the listener API to implement a primitive memory leak checker.
\ No newline at end of file + * [Sample #1](../samples/sample1_unittest.cc) shows the basic steps of using Google Test to test C++ functions. + * [Sample #2](../samples/sample2_unittest.cc) shows a more complex unit test for a class with multiple member functions. + * [Sample #3](../samples/sample3_unittest.cc) uses a test fixture. + * [Sample #4](../samples/sample4_unittest.cc) is another basic example of using Google Test. + * [Sample #5](../samples/sample5_unittest.cc) teaches how to reuse a test fixture in multiple test cases by deriving sub-fixtures from it. + * [Sample #6](../samples/sample6_unittest.cc) demonstrates type-parameterized tests. + * [Sample #7](../samples/sample7_unittest.cc) teaches the basics of value-parameterized tests. + * [Sample #8](../samples/sample8_unittest.cc) shows using `Combine()` in value-parameterized tests. + * [Sample #9](../samples/sample9_unittest.cc) shows use of the listener API to modify Google Test's console output and the use of its reflection API to inspect test results. + * [Sample #10](../samples/sample10_unittest.cc) shows use of the listener API to implement a primitive memory leak checker. diff --git a/googletest/include/gtest/internal/gtest-port.h b/googletest/include/gtest/internal/gtest-port.h index 141d4579..a8d81ff7 100644 --- a/googletest/include/gtest/internal/gtest-port.h +++ b/googletest/include/gtest/internal/gtest-port.h @@ -358,8 +358,9 @@ # define GTEST_HAS_STD_FUNCTION_ 1 # define GTEST_HAS_STD_INITIALIZER_LIST_ 1 # define GTEST_HAS_STD_MOVE_ 1 -# define GTEST_HAS_STD_UNIQUE_PTR_ 1 # define GTEST_HAS_STD_SHARED_PTR_ 1 +# define GTEST_HAS_STD_TYPE_TRAITS_ 1 +# define GTEST_HAS_STD_UNIQUE_PTR_ 1 #endif // C++11 specifies that <tuple> provides std::tuple. @@ -920,14 +921,14 @@ using ::std::tuple_size; #endif // GTEST_HAS_SEH #ifdef _MSC_VER - # if GTEST_LINKED_AS_SHARED_LIBRARY # define GTEST_API_ __declspec(dllimport) # elif GTEST_CREATE_SHARED_LIBRARY # define GTEST_API_ __declspec(dllexport) # endif - -#endif // _MSC_VER +#elif __GNUC__ >= 4 || defined(__clang__) +# define GTEST_API_ __attribute__((visibility ("default"))) +#endif // _MSC_VER #ifndef GTEST_API_ # define GTEST_API_ @@ -1968,13 +1969,8 @@ class MutexBase { extern ::testing::internal::MutexBase mutex // Defines and statically (i.e. at link time) initializes a static mutex. -// The initialization list here does not explicitly initialize each field, -// instead relying on default initialization for the unspecified fields. In -// particular, the owner_ field (a pthread_t) is not explicitly initialized. -// This allows initialization to work whether pthread_t is a scalar or struct. -// The flag -Wmissing-field-initializers must not be specified for this to work. # define GTEST_DEFINE_STATIC_MUTEX_(mutex) \ - ::testing::internal::MutexBase mutex = { PTHREAD_MUTEX_INITIALIZER, false } + ::testing::internal::MutexBase mutex = { PTHREAD_MUTEX_INITIALIZER, false, pthread_t() } // The Mutex class can only be used for mutexes created at runtime. It // shares its API with MutexBase otherwise. diff --git a/googletest/src/gtest-internal-inl.h b/googletest/src/gtest-internal-inl.h index 56c8a20c..ed8a682a 100644 --- a/googletest/src/gtest-internal-inl.h +++ b/googletest/src/gtest-internal-inl.h @@ -1032,7 +1032,7 @@ class TestResultAccessor { #if GTEST_CAN_STREAM_RESULTS_ // Streams test results to the given port on the given host machine. -class StreamingListener : public EmptyTestEventListener { +class GTEST_API_ StreamingListener : public EmptyTestEventListener { public: // Abstract base class for writing strings to a socket. class AbstractSocketWriter { diff --git a/googletest/test/gtest-port_test.cc b/googletest/test/gtest-port_test.cc index d17bad00..6ea607bc 100644 --- a/googletest/test/gtest-port_test.cc +++ b/googletest/test/gtest-port_test.cc @@ -75,8 +75,8 @@ TEST(IsXDigitTest, WorksForNarrowAscii) { } TEST(IsXDigitTest, ReturnsFalseForNarrowNonAscii) { - EXPECT_FALSE(IsXDigit(static_cast<char>(0x80))); - EXPECT_FALSE(IsXDigit(static_cast<char>('0' | 0x80))); + EXPECT_FALSE(IsXDigit('\x80')); + EXPECT_FALSE(IsXDigit(static_cast<char>('0' | '\x80'))); } TEST(IsXDigitTest, WorksForWideAscii) { |