update googletests (nw)

This commit is contained in:
Miodrag Milanovic 2016-03-08 11:38:27 +01:00
parent 62709182b2
commit dfad813239
60 changed files with 760 additions and 682 deletions

2
3rdparty/googletest/.gitignore vendored Normal file
View File

@ -0,0 +1,2 @@
# Ignore CI build directory
build/

View File

@ -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

16
3rdparty/googletest/CMakeLists.txt vendored Normal file
View File

@ -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()

View File

@ -14,6 +14,9 @@ mailing list for questions, discussions, and development. There is
also an IRC channel on OFTC (irc.oftc.net) #gtest available. Please
join us!
Getting started information for **Google Test** is available in the
[Google Test Primer](googletest/docs/Primer.md) documentation.
**Google Mock** is an extension to Google Test for writing and using C++ mock
classes. See the separate [Google Mock documentation](googlemock/README.md).
@ -53,7 +56,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 +69,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 ##
@ -102,7 +105,7 @@ package (as described below):
### Mac OS X Requirements ###
* Mac OS X v10.4 Tiger or newer
* XCode Developer Tools
* Xcode Developer Tools
### Requirements for Contributors ###
@ -110,9 +113,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 ##

View File

@ -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.

View File

@ -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 ###

View File

@ -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. |
| `--gmock_verbose=LEVEL` | Sets the default verbosity level (`info`, `warning`, or `error`) of Google Mock messages. |

View File

@ -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.
printing your particular type than to dump the bytes.

View File

@ -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/).
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/).

View File

@ -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.
* [Pump Manual](../googletest/docs/PumpManual.md) -- how we generate some of Google Mock's source files.

View File

@ -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).
@ -44,7 +44,7 @@ We encourage you to use Google Mock as:
* a _testing_ tool to cut your tests' outbound dependencies and probe the interaction between your module and its collaborators.
# Getting Started #
Using Google Mock is easy! Inside your C++ source file, just #include `"gtest/gtest.h"` and `"gmock/gmock.h"`, and you are ready to go.
Using Google Mock is easy! Inside your C++ source file, just `#include` `"gtest/gtest.h"` and `"gmock/gmock.h"`, and you are ready to go.
# A Case for Mock Turtles #
Let's look at an example. Suppose you are developing a graphics program that relies on a LOGO-like API for drawing. How would you test that it does the right thing? Well, you can run it and compare the screen with a golden screen snapshot, but let's admit it: tests like this are expensive to run and fragile (What if you just upgraded to a shiny new graphics card that has better anti-aliasing? Suddenly you have to update all your golden images.). It would be too painful if all your tests are like this. Fortunately, you learned about Dependency Injection and know the right thing to do: instead of having your application talk to the drawing API directly, wrap the API in an interface (say, `Turtle`) and code to that interface:
@ -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.
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.

View File

@ -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.
* the _actual_ code (ideally, a minimal but complete program) that has the problem you encounter.

View File

@ -44,7 +44,7 @@ We encourage you to use Google Mock as:
* a _testing_ tool to cut your tests' outbound dependencies and probe the interaction between your module and its collaborators.
# Getting Started #
Using Google Mock is easy! Inside your C++ source file, just #include `<gtest/gtest.h>` and `<gmock/gmock.h>`, and you are ready to go.
Using Google Mock is easy! Inside your C++ source file, just `#include` `<gtest/gtest.h>` and `<gmock/gmock.h>`, and you are ready to go.
# A Case for Mock Turtles #
Let's look at an example. Suppose you are developing a graphics program that relies on a LOGO-like API for drawing. How would you test that it does the right thing? Well, you can run it and compare the screen with a golden screen snapshot, but let's admit it: tests like this are expensive to run and fragile (What if you just upgraded to a shiny new graphics card that has better anti-aliasing? Suddenly you have to update all your golden images.). It would be too painful if all your tests are like this. Fortunately, you learned about Dependency Injection and know the right thing to do: instead of having your application talk to the drawing API directly, wrap the API in an interface (say, `Turtle`) and code to that interface:

View File

@ -44,7 +44,7 @@ We encourage you to use Google Mock as:
* a _testing_ tool to cut your tests' outbound dependencies and probe the interaction between your module and its collaborators.
# Getting Started #
Using Google Mock is easy! Inside your C++ source file, just #include `"gtest/gtest.h"` and `"gmock/gmock.h"`, and you are ready to go.
Using Google Mock is easy! Inside your C++ source file, just `#include` `"gtest/gtest.h"` and `"gmock/gmock.h"`, and you are ready to go.
# A Case for Mock Turtles #
Let's look at an example. Suppose you are developing a graphics program that relies on a LOGO-like API for drawing. How would you test that it does the right thing? Well, you can run it and compare the screen with a golden screen snapshot, but let's admit it: tests like this are expensive to run and fragile (What if you just upgraded to a shiny new graphics card that has better anti-aliasing? Suddenly you have to update all your golden images.). It would be too painful if all your tests are like this. Fortunately, you learned about Dependency Injection and know the right thing to do: instead of having your application talk to the drawing API directly, wrap the API in an interface (say, `Turtle`) and code to that interface:

View File

@ -44,7 +44,7 @@ We encourage you to use Google Mock as:
* a _testing_ tool to cut your tests' outbound dependencies and probe the interaction between your module and its collaborators.
# Getting Started #
Using Google Mock is easy! Inside your C++ source file, just #include `"gtest/gtest.h"` and `"gmock/gmock.h"`, and you are ready to go.
Using Google Mock is easy! Inside your C++ source file, just `#include` `"gtest/gtest.h"` and `"gmock/gmock.h"`, and you are ready to go.
# A Case for Mock Turtles #
Let's look at an example. Suppose you are developing a graphics program that relies on a LOGO-like API for drawing. How would you test that it does the right thing? Well, you can run it and compare the screen with a golden screen snapshot, but let's admit it: tests like this are expensive to run and fragile (What if you just upgraded to a shiny new graphics card that has better anti-aliasing? Suddenly you have to update all your golden images.). It would be too painful if all your tests are like this. Fortunately, you learned about Dependency Injection and know the right thing to do: instead of having your application talk to the drawing API directly, wrap the API in an interface (say, `Turtle`) and code to that interface:

View File

@ -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

View File

@ -17,7 +17,7 @@
# Points to the root of Google Test, relative to where this file is.
# Remember to tweak this if you move this file, or if you want to use
# a copy of Google Test at a different location.
GTEST_DIR = ../../googletest
GTEST_DIR = ../gtest
# Points to the root of Google Mock, relative to where this file is.
# Remember to tweak this if you move this file.

View File

@ -258,8 +258,8 @@ void ReportUninterestingCall(CallReaction reaction, const string& msg) {
"\nNOTE: You can safely ignore the above warning unless this "
"call should not happen. Do not suppress it by blindly adding "
"an EXPECT_CALL() if you don't mean to enforce the call. "
"See http://code.google.com/p/googlemock/wiki/CookBook#"
"Knowing_When_to_Expect for details.\n",
"See https://github.com/google/googletest/blob/master/googlemock/docs/CookBook.md#"
"knowing-when-to-expect for details.\n",
stack_frames_to_skip);
break;
default: // FAIL

View File

@ -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());

View File

@ -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 {

View File

@ -2117,8 +2117,8 @@ class GMockVerboseFlagTest : public VerboseFlagPreservingFixture {
"NOTE: You can safely ignore the above warning unless this "
"call should not happen. Do not suppress it by blindly adding "
"an EXPECT_CALL() if you don't mean to enforce the call. "
"See http://code.google.com/p/googlemock/wiki/CookBook#"
"Knowing_When_to_Expect for details.";
"See https://github.com/google/googletest/blob/master/googlemock/docs/CookBook.md#"
"knowing-when-to-expect for details.";
// A void-returning function.
CaptureStdout();

View File

@ -75,14 +75,14 @@ GMOCK WARNING:
Uninteresting mock function call - returning default value.
Function call: Bar2(0, 1)
Returns: false
NOTE: You can safely ignore the above warning unless this call should not happen. Do not suppress it by blindly adding an EXPECT_CALL() if you don't mean to enforce the call. See http://code.google.com/p/googlemock/wiki/CookBook#Knowing_When_to_Expect for details.
NOTE: You can safely ignore the above warning unless this call should not happen. Do not suppress it by blindly adding an EXPECT_CALL() if you don't mean to enforce the call. See https://github.com/google/googletest/blob/master/googlemock/docs/CookBook.md#knowing-when-to-expect for details.
[ OK ] GMockOutputTest.UninterestingCall
[ RUN ] GMockOutputTest.UninterestingCallToVoidFunction
GMOCK WARNING:
Uninteresting mock function call - returning directly.
Function call: Bar3(0, 1)
NOTE: You can safely ignore the above warning unless this call should not happen. Do not suppress it by blindly adding an EXPECT_CALL() if you don't mean to enforce the call. See http://code.google.com/p/googlemock/wiki/CookBook#Knowing_When_to_Expect for details.
NOTE: You can safely ignore the above warning unless this call should not happen. Do not suppress it by blindly adding an EXPECT_CALL() if you don't mean to enforce the call. See https://github.com/google/googletest/blob/master/googlemock/docs/CookBook.md#knowing-when-to-expect for details.
[ OK ] GMockOutputTest.UninterestingCallToVoidFunction
[ RUN ] GMockOutputTest.RetiredExpectation
unknown file: Failure
@ -266,14 +266,14 @@ Uninteresting mock function call - taking default action specified at:
FILE:#:
Function call: Bar2(2, 2)
Returns: true
NOTE: You can safely ignore the above warning unless this call should not happen. Do not suppress it by blindly adding an EXPECT_CALL() if you don't mean to enforce the call. See http://code.google.com/p/googlemock/wiki/CookBook#Knowing_When_to_Expect for details.
NOTE: You can safely ignore the above warning unless this call should not happen. Do not suppress it by blindly adding an EXPECT_CALL() if you don't mean to enforce the call. See https://github.com/google/googletest/blob/master/googlemock/docs/CookBook.md#knowing-when-to-expect for details.
GMOCK WARNING:
Uninteresting mock function call - taking default action specified at:
FILE:#:
Function call: Bar2(1, 1)
Returns: false
NOTE: You can safely ignore the above warning unless this call should not happen. Do not suppress it by blindly adding an EXPECT_CALL() if you don't mean to enforce the call. See http://code.google.com/p/googlemock/wiki/CookBook#Knowing_When_to_Expect for details.
NOTE: You can safely ignore the above warning unless this call should not happen. Do not suppress it by blindly adding an EXPECT_CALL() if you don't mean to enforce the call. See https://github.com/google/googletest/blob/master/googlemock/docs/CookBook.md#knowing-when-to-expect for details.
[ OK ] GMockOutputTest.UninterestingCallWithDefaultAction
[ RUN ] GMockOutputTest.ExplicitActionsRunOutWithDefaultAction

View File

@ -0,0 +1,2 @@
# python
*.pyc

View File

@ -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.

View File

@ -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 ###
@ -221,7 +221,7 @@ your build script.
### Avoiding Macro Name Clashes ###
In C++, macros don't obey namespaces. Therefore two libraries that
both define a macro of the same name will clash if you #include both
both define a macro of the same name will clash if you `#include` both
definitions. In case a Google Test macro clashes with another
library, you can force Google Test to rename its macro to avoid the
conflict.

View File

@ -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 "
@ -312,8 +312,8 @@ want to learn more, see
| **Fatal assertion** | **Nonfatal assertion** | **Verifies** |
|:--------------------|:-----------------------|:-------------|
| `ASSERT_FLOAT_EQ(`_expected, actual_`);` | `EXPECT_FLOAT_EQ(`_expected, actual_`);` | the two `float` values are almost equal |
| `ASSERT_DOUBLE_EQ(`_expected, actual_`);` | `EXPECT_DOUBLE_EQ(`_expected, actual_`);` | the two `double` values are almost equal |
| `ASSERT_FLOAT_EQ(`_val1, val2_`);` | `EXPECT_FLOAT_EQ(`_val1, val2_`);` | the two `float` values are almost equal |
| `ASSERT_DOUBLE_EQ(`_val1, val2_`);` | `EXPECT_DOUBLE_EQ(`_val1, val2_`);` | the two `double` values are almost equal |
By "almost equal", we mean the two values are within 4 ULP's from each
other.
@ -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](https://github.com/google/googletest/blob/master/googletest/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](https://github.com/google/googletest/blob/master/googletest/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"`.
@ -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](https://github.com/google/googletest/blob/master/googletest/samples/sample7_unittest.cc)
[files](https://github.com/google/googletest/blob/master/googletest/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.
@ -1450,7 +1450,7 @@ two cases to consider:
Both static functions and definitions/declarations in an unnamed namespace are
only visible within the same translation unit. To test them, you can `#include`
the entire `.cc` file being tested in your `*_test.cc` file. (#including `.cc`
the entire `.cc` file being tested in your `*_test.cc` file. (`#include`ing `.cc`
files is not a good way to reuse code - you should not do this in production
code!)
@ -1551,8 +1551,8 @@ exception, you could catch the exception and assert on it. But Google
Test doesn't use exceptions, so how do we test that a piece of code
generates an expected failure?
`"gtest/gtest-spi.h"` contains some constructs to do this. After
#including this header, you can use
`"gtest/gtest-spi.h"` contains some constructs to do this. After
`#include`ing this header, you can use
| `EXPECT_FATAL_FAILURE(`_statement, substring_`);` |
|:--------------------------------------------------|
@ -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](https://github.com/google/googletest/blob/master/googletest/include/gtest/gtest.h#L991)
or [testing::EmptyTestEventListener](https://github.com/google/googletest/blob/master/googletest/include/gtest/gtest.h#L1044).
[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](https://github.com/google/googletest/blob/master/googletest/include/gtest/gtest.h#L1151) reflects the state of the entire test program,
* [TestCase](https://github.com/google/googletest/blob/master/googletest/include/gtest/gtest.h#L778) has information about a test case, which can contain one or more tests,
* [TestInfo](https://github.com/google/googletest/blob/master/googletest/include/gtest/gtest.h#L644) contains the state of a test, and
* [TestPartResult](https://github.com/google/googletest/blob/master/googletest/include/gtest/gtest-test-part.h#L47) 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](https://github.com/google/googletest/blob/master/googletest/include/gtest/gtest.h#L1064)
[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](https://github.com/google/googletest/blob/master/googletest/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](https://github.com/google/googletest/blob/master/googletest/samples/sample10_unittest.cc).
[here](../samples/sample10_unittest.cc).
# Running Test Programs: Advanced Options #
@ -2173,7 +2173,7 @@ 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](https://github.com/google/googletest/blob/master/googletest/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 #

View File

@ -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/).
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/).

View File

@ -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.
@ -994,7 +994,7 @@ you can use the _horrible_ hack of sniffing your executable name
## Google Test defines a macro that clashes with one defined by another library. How do I deal with that? ##
In C++, macros don't obey namespaces. Therefore two libraries that
both define a macro of the same name will clash if you #include both
both define a macro of the same name will clash if you `#include` both
definitions. In case a Google Test macro clashes with another
library, you can force Google Test to rename its macro to avoid the
conflict.
@ -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.
* the _actual_ code (ideally, a minimal but complete program) that has the problem you encounter.

View File

@ -127,18 +127,14 @@ This section describes assertions that compare two values.
| **Fatal assertion** | **Nonfatal assertion** | **Verifies** |
|:--------------------|:-----------------------|:-------------|
|`ASSERT_EQ(`_expected_`, `_actual_`);`|`EXPECT_EQ(`_expected_`, `_actual_`);`| _expected_ `==` _actual_ |
|`ASSERT_NE(`_val1_`, `_val2_`);` |`EXPECT_NE(`_val1_`, `_val2_`);` | _val1_ `!=` _val2_ |
|`ASSERT_LT(`_val1_`, `_val2_`);` |`EXPECT_LT(`_val1_`, `_val2_`);` | _val1_ `<` _val2_ |
|`ASSERT_LE(`_val1_`, `_val2_`);` |`EXPECT_LE(`_val1_`, `_val2_`);` | _val1_ `<=` _val2_ |
|`ASSERT_GT(`_val1_`, `_val2_`);` |`EXPECT_GT(`_val1_`, `_val2_`);` | _val1_ `>` _val2_ |
|`ASSERT_GE(`_val1_`, `_val2_`);` |`EXPECT_GE(`_val1_`, `_val2_`);` | _val1_ `>=` _val2_ |
|`ASSERT_EQ(`_val1_`, `_val2_`);`|`EXPECT_EQ(`_val1_`, `_val2_`);`| _val1_ `==` _val2_ |
|`ASSERT_NE(`_val1_`, `_val2_`);`|`EXPECT_NE(`_val1_`, `_val2_`);`| _val1_ `!=` _val2_ |
|`ASSERT_LT(`_val1_`, `_val2_`);`|`EXPECT_LT(`_val1_`, `_val2_`);`| _val1_ `<` _val2_ |
|`ASSERT_LE(`_val1_`, `_val2_`);`|`EXPECT_LE(`_val1_`, `_val2_`);`| _val1_ `<=` _val2_ |
|`ASSERT_GT(`_val1_`, `_val2_`);`|`EXPECT_GT(`_val1_`, `_val2_`);`| _val1_ `>` _val2_ |
|`ASSERT_GE(`_val1_`, `_val2_`);`|`EXPECT_GE(`_val1_`, `_val2_`);`| _val1_ `>=` _val2_ |
In the event of a failure, Google Test prints both _val1_ and _val2_
. In `ASSERT_EQ*` and `EXPECT_EQ*` (and all other equality assertions
we'll introduce later), you should put the expression you want to test
in the position of _actual_, and put its expected value in _expected_,
as Google Test's failure messages are optimized for this convention.
In the event of a failure, Google Test prints both _val1_ and _val2_.
Value arguments must be comparable by the assertion's comparison
operator or you'll get a compiler error. We used to require the
@ -147,7 +143,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
@ -172,6 +168,10 @@ and `wstring`).
_Availability_: Linux, Windows, Mac.
_Historical note_: Before February 2016 `*_EQ` had a convention of calling it as
`ASSERT_EQ(expected, actual)`, so lots of existing code uses this order.
Now `*_EQ` treats both parameters in the same way.
## String Comparison ##
The assertions in this group compare two **C strings**. If you want to compare
@ -179,9 +179,9 @@ two `string` objects, use `EXPECT_EQ`, `EXPECT_NE`, and etc instead.
| **Fatal assertion** | **Nonfatal assertion** | **Verifies** |
|:--------------------|:-----------------------|:-------------|
| `ASSERT_STREQ(`_expected\_str_`, `_actual\_str_`);` | `EXPECT_STREQ(`_expected\_str_`, `_actual\_str_`);` | the two C strings have the same content |
| `ASSERT_STREQ(`_str1_`, `_str2_`);` | `EXPECT_STREQ(`_str1_`, `_str_2`);` | the two C strings have the same content |
| `ASSERT_STRNE(`_str1_`, `_str2_`);` | `EXPECT_STRNE(`_str1_`, `_str2_`);` | the two C strings have different content |
| `ASSERT_STRCASEEQ(`_expected\_str_`, `_actual\_str_`);`| `EXPECT_STRCASEEQ(`_expected\_str_`, `_actual\_str_`);` | the two C strings have the same content, ignoring case |
| `ASSERT_STRCASEEQ(`_str1_`, `_str2_`);`| `EXPECT_STRCASEEQ(`_str1_`, `_str2_`);` | the two C strings have the same content, ignoring case |
| `ASSERT_STRCASENE(`_str1_`, `_str2_`);`| `EXPECT_STRCASENE(`_str1_`, `_str2_`);` | the two C strings have different content, ignoring case |
Note that "CASE" in an assertion name means that case is ignored.
@ -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

View File

@ -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.
@ -1365,7 +1365,7 @@ two cases to consider:
Both static functions and definitions/declarations in an unnamed namespace are
only visible within the same translation unit. To test them, you can `#include`
the entire `.cc` file being tested in your `*_test.cc` file. (#including `.cc`
the entire `.cc` file being tested in your `*_test.cc` file. (`#include`ing `.cc`
files is not a good way to reuse code - you should not do this in production
code!)
@ -1467,7 +1467,7 @@ Test doesn't use exceptions, so how do we test that a piece of code
generates an expected failure?
`<gtest/gtest-spi.h>` contains some constructs to do this. After
#including this header, you can use
`#include`ing this header, you can use
| `EXPECT_FATAL_FAILURE(`_statement, substring_`);` |
|:--------------------------------------------------|
@ -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).
can read the [FAQ](V1_5_FAQ.md).

View File

@ -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.
* the _actual_ code (ideally, a minimal but complete program) that has the problem you encounter.

View File

@ -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.
synchronization primitives in `gtest-port.h` for your platform.

View File

@ -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.
@ -1447,7 +1447,7 @@ two cases to consider:
Both static functions and definitions/declarations in an unnamed namespace are
only visible within the same translation unit. To test them, you can `#include`
the entire `.cc` file being tested in your `*_test.cc` file. (#including `.cc`
the entire `.cc` file being tested in your `*_test.cc` file. (`#include`ing `.cc`
files is not a good way to reuse code - you should not do this in production
code!)
@ -1549,7 +1549,7 @@ Test doesn't use exceptions, so how do we test that a piece of code
generates an expected failure?
`"gtest/gtest-spi.h"` contains some constructs to do this. After
#including this header, you can use
`#include`ing this header, you can use
| `EXPECT_FATAL_FAILURE(`_statement, substring_`);` |
|:--------------------------------------------------|
@ -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).
can read the [Frequently-Asked Questions](V1_6_FAQ.md).

View File

@ -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. ##
@ -988,7 +989,7 @@ you can use the _horrible_ hack of sniffing your executable name
## Google Test defines a macro that clashes with one defined by another library. How do I deal with that? ##
In C++, macros don't obey namespaces. Therefore two libraries that
both define a macro of the same name will clash if you #include both
both define a macro of the same name will clash if you `#include` both
definitions. In case a Google Test macro clashes with another
library, you can force Google Test to rename its macro to avoid the
conflict.
@ -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.
* the _actual_ code (ideally, a minimal but complete program) that has the problem you encounter.

View File

@ -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.
synchronization primitives in `gtest-port.h` for your platform.

View File

@ -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.
* 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.

View File

@ -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.
* [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.

View File

@ -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.
@ -1448,7 +1448,7 @@ two cases to consider:
Both static functions and definitions/declarations in an unnamed namespace are
only visible within the same translation unit. To test them, you can `#include`
the entire `.cc` file being tested in your `*_test.cc` file. (#including `.cc`
the entire `.cc` file being tested in your `*_test.cc` file. (`#include`ing `.cc`
files is not a good way to reuse code - you should not do this in production
code!)
@ -1550,7 +1550,7 @@ Test doesn't use exceptions, so how do we test that a piece of code
generates an expected failure?
`"gtest/gtest-spi.h"` contains some constructs to do this. After
#including this header, you can use
`#include`ing this header, you can use
| `EXPECT_FATAL_FAILURE(`_statement, substring_`);` |
|:--------------------------------------------------|
@ -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).
can read the [Frequently-Asked Questions](V1_7_FAQ.md).

View File

@ -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. ##
@ -988,7 +989,7 @@ you can use the _horrible_ hack of sniffing your executable name
## Google Test defines a macro that clashes with one defined by another library. How do I deal with that? ##
In C++, macros don't obey namespaces. Therefore two libraries that
both define a macro of the same name will clash if you #include both
both define a macro of the same name will clash if you `#include` both
definitions. In case a Google Test macro clashes with another
library, you can force Google Test to rename its macro to avoid the
conflict.
@ -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.
* the _actual_ code (ideally, a minimal but complete program) that has the problem you encounter.

View File

@ -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.
synchronization primitives in `gtest-port.h` for your platform.

View File

@ -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.
* 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.

View File

@ -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.
* [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.

View File

@ -1372,39 +1372,38 @@ namespace internal {
// frame size of CmpHelperEQ. This helps reduce the overhead of some sanitizers
// when calling EXPECT_* in a tight loop.
template <typename T1, typename T2>
AssertionResult CmpHelperEQFailure(const char* expected_expression,
const char* actual_expression,
const T1& expected, const T2& actual) {
return EqFailure(expected_expression,
actual_expression,
FormatForComparisonFailureMessage(expected, actual),
FormatForComparisonFailureMessage(actual, expected),
AssertionResult CmpHelperEQFailure(const char* lhs_expression,
const char* rhs_expression,
const T1& lhs, const T2& rhs) {
return EqFailure(lhs_expression,
rhs_expression,
FormatForComparisonFailureMessage(lhs, rhs),
FormatForComparisonFailureMessage(rhs, lhs),
false);
}
// The helper function for {ASSERT|EXPECT}_EQ.
template <typename T1, typename T2>
AssertionResult CmpHelperEQ(const char* expected_expression,
const char* actual_expression,
const T1& expected,
const T2& actual) {
AssertionResult CmpHelperEQ(const char* lhs_expression,
const char* rhs_expression,
const T1& lhs,
const T2& rhs) {
GTEST_DISABLE_MSC_WARNINGS_PUSH_(4389 /* signed/unsigned mismatch */)
if (expected == actual) {
if (lhs == rhs) {
return AssertionSuccess();
}
GTEST_DISABLE_MSC_WARNINGS_POP_()
return CmpHelperEQFailure(expected_expression, actual_expression, expected,
actual);
return CmpHelperEQFailure(lhs_expression, rhs_expression, lhs, rhs);
}
// With this overloaded version, we allow anonymous enums to be used
// in {ASSERT|EXPECT}_EQ when compiled with gcc 4, as anonymous enums
// can be implicitly cast to BiggestInt.
GTEST_API_ AssertionResult CmpHelperEQ(const char* expected_expression,
const char* actual_expression,
BiggestInt expected,
BiggestInt actual);
GTEST_API_ AssertionResult CmpHelperEQ(const char* lhs_expression,
const char* rhs_expression,
BiggestInt lhs,
BiggestInt rhs);
// The helper class for {ASSERT|EXPECT}_EQ. The template argument
// lhs_is_null_literal is true iff the first argument to ASSERT_EQ()
@ -1415,12 +1414,11 @@ class EqHelper {
public:
// This templatized version is for the general case.
template <typename T1, typename T2>
static AssertionResult Compare(const char* expected_expression,
const char* actual_expression,
const T1& expected,
const T2& actual) {
return CmpHelperEQ(expected_expression, actual_expression, expected,
actual);
static AssertionResult Compare(const char* lhs_expression,
const char* rhs_expression,
const T1& lhs,
const T2& rhs) {
return CmpHelperEQ(lhs_expression, rhs_expression, lhs, rhs);
}
// With this overloaded version, we allow anonymous enums to be used
@ -1429,12 +1427,11 @@ class EqHelper {
//
// Even though its body looks the same as the above version, we
// cannot merge the two, as it will make anonymous enums unhappy.
static AssertionResult Compare(const char* expected_expression,
const char* actual_expression,
BiggestInt expected,
BiggestInt actual) {
return CmpHelperEQ(expected_expression, actual_expression, expected,
actual);
static AssertionResult Compare(const char* lhs_expression,
const char* rhs_expression,
BiggestInt lhs,
BiggestInt rhs) {
return CmpHelperEQ(lhs_expression, rhs_expression, lhs, rhs);
}
};
@ -1449,37 +1446,36 @@ class EqHelper<true> {
// EXPECT_EQ(false, a_bool).
template <typename T1, typename T2>
static AssertionResult Compare(
const char* expected_expression,
const char* actual_expression,
const T1& expected,
const T2& actual,
const char* lhs_expression,
const char* rhs_expression,
const T1& lhs,
const T2& rhs,
// The following line prevents this overload from being considered if T2
// is not a pointer type. We need this because ASSERT_EQ(NULL, my_ptr)
// expands to Compare("", "", NULL, my_ptr), which requires a conversion
// to match the Secret* in the other overload, which would otherwise make
// this template match better.
typename EnableIf<!is_pointer<T2>::value>::type* = 0) {
return CmpHelperEQ(expected_expression, actual_expression, expected,
actual);
return CmpHelperEQ(lhs_expression, rhs_expression, lhs, rhs);
}
// This version will be picked when the second argument to ASSERT_EQ() is a
// pointer, e.g. ASSERT_EQ(NULL, a_pointer).
template <typename T>
static AssertionResult Compare(
const char* expected_expression,
const char* actual_expression,
const char* lhs_expression,
const char* rhs_expression,
// We used to have a second template parameter instead of Secret*. That
// template parameter would deduce to 'long', making this a better match
// than the first overload even without the first overload's EnableIf.
// Unfortunately, gcc with -Wconversion-null warns when "passing NULL to
// non-pointer argument" (even a deduced integral argument), so the old
// implementation caused warnings in user code.
Secret* /* expected (NULL) */,
T* actual) {
// We already know that 'expected' is a null pointer.
return CmpHelperEQ(expected_expression, actual_expression,
static_cast<T*>(NULL), actual);
Secret* /* lhs (NULL) */,
T* rhs) {
// We already know that 'lhs' is a null pointer.
return CmpHelperEQ(lhs_expression, rhs_expression,
static_cast<T*>(NULL), rhs);
}
};
@ -1538,18 +1534,18 @@ GTEST_IMPL_CMP_HELPER_(GT, >);
// The helper function for {ASSERT|EXPECT}_STREQ.
//
// INTERNAL IMPLEMENTATION - DO NOT USE IN A USER PROGRAM.
GTEST_API_ AssertionResult CmpHelperSTREQ(const char* expected_expression,
const char* actual_expression,
const char* expected,
const char* actual);
GTEST_API_ AssertionResult CmpHelperSTREQ(const char* s1_expression,
const char* s2_expression,
const char* s1,
const char* s2);
// The helper function for {ASSERT|EXPECT}_STRCASEEQ.
//
// INTERNAL IMPLEMENTATION - DO NOT USE IN A USER PROGRAM.
GTEST_API_ AssertionResult CmpHelperSTRCASEEQ(const char* expected_expression,
const char* actual_expression,
const char* expected,
const char* actual);
GTEST_API_ AssertionResult CmpHelperSTRCASEEQ(const char* s1_expression,
const char* s2_expression,
const char* s1,
const char* s2);
// The helper function for {ASSERT|EXPECT}_STRNE.
//
@ -1571,10 +1567,10 @@ GTEST_API_ AssertionResult CmpHelperSTRCASENE(const char* s1_expression,
// Helper function for *_STREQ on wide strings.
//
// INTERNAL IMPLEMENTATION - DO NOT USE IN A USER PROGRAM.
GTEST_API_ AssertionResult CmpHelperSTREQ(const char* expected_expression,
const char* actual_expression,
const wchar_t* expected,
const wchar_t* actual);
GTEST_API_ AssertionResult CmpHelperSTREQ(const char* s1_expression,
const char* s2_expression,
const wchar_t* s1,
const wchar_t* s2);
// Helper function for *_STRNE on wide strings.
//
@ -1632,28 +1628,28 @@ namespace internal {
//
// INTERNAL IMPLEMENTATION - DO NOT USE IN A USER PROGRAM.
template <typename RawType>
AssertionResult CmpHelperFloatingPointEQ(const char* expected_expression,
const char* actual_expression,
RawType expected,
RawType actual) {
const FloatingPoint<RawType> lhs(expected), rhs(actual);
AssertionResult CmpHelperFloatingPointEQ(const char* lhs_expression,
const char* rhs_expression,
RawType lhs_value,
RawType rhs_value) {
const FloatingPoint<RawType> lhs(lhs_value), rhs(rhs_value);
if (lhs.AlmostEquals(rhs)) {
return AssertionSuccess();
}
::std::stringstream expected_ss;
expected_ss << std::setprecision(std::numeric_limits<RawType>::digits10 + 2)
<< expected;
::std::stringstream lhs_ss;
lhs_ss << std::setprecision(std::numeric_limits<RawType>::digits10 + 2)
<< lhs_value;
::std::stringstream actual_ss;
actual_ss << std::setprecision(std::numeric_limits<RawType>::digits10 + 2)
<< actual;
::std::stringstream rhs_ss;
rhs_ss << std::setprecision(std::numeric_limits<RawType>::digits10 + 2)
<< rhs_value;
return EqFailure(expected_expression,
actual_expression,
StringStreamToString(&expected_ss),
StringStreamToString(&actual_ss),
return EqFailure(lhs_expression,
rhs_expression,
StringStreamToString(&lhs_ss),
StringStreamToString(&rhs_ss),
false);
}
@ -1879,12 +1875,12 @@ class TestWithParam : public Test, public WithParamInterface<T> {
// Macros for testing equalities and inequalities.
//
// * {ASSERT|EXPECT}_EQ(expected, actual): Tests that expected == actual
// * {ASSERT|EXPECT}_NE(v1, v2): Tests that v1 != v2
// * {ASSERT|EXPECT}_LT(v1, v2): Tests that v1 < v2
// * {ASSERT|EXPECT}_LE(v1, v2): Tests that v1 <= v2
// * {ASSERT|EXPECT}_GT(v1, v2): Tests that v1 > v2
// * {ASSERT|EXPECT}_GE(v1, v2): Tests that v1 >= v2
// * {ASSERT|EXPECT}_EQ(v1, v2): Tests that v1 == v2
// * {ASSERT|EXPECT}_NE(v1, v2): Tests that v1 != v2
// * {ASSERT|EXPECT}_LT(v1, v2): Tests that v1 < v2
// * {ASSERT|EXPECT}_LE(v1, v2): Tests that v1 <= v2
// * {ASSERT|EXPECT}_GT(v1, v2): Tests that v1 > v2
// * {ASSERT|EXPECT}_GE(v1, v2): Tests that v1 >= v2
//
// When they are not, Google Test prints both the tested expressions and
// their actual values. The values must be compatible built-in types,
@ -1906,8 +1902,8 @@ class TestWithParam : public Test, public WithParamInterface<T> {
// are related, not how their content is related. To compare two C
// strings by content, use {ASSERT|EXPECT}_STR*().
//
// 3. {ASSERT|EXPECT}_EQ(expected, actual) is preferred to
// {ASSERT|EXPECT}_TRUE(expected == actual), as the former tells you
// 3. {ASSERT|EXPECT}_EQ(v1, v2) is preferred to
// {ASSERT|EXPECT}_TRUE(v1 == v2), as the former tells you
// what the actual value is when it fails, and similarly for the
// other comparisons.
//
@ -1923,12 +1919,12 @@ class TestWithParam : public Test, public WithParamInterface<T> {
// ASSERT_LT(i, array_size);
// ASSERT_GT(records.size(), 0) << "There is no record left.";
#define EXPECT_EQ(expected, actual) \
#define EXPECT_EQ(val1, val2) \
EXPECT_PRED_FORMAT2(::testing::internal:: \
EqHelper<GTEST_IS_NULL_LITERAL_(expected)>::Compare, \
expected, actual)
#define EXPECT_NE(expected, actual) \
EXPECT_PRED_FORMAT2(::testing::internal::CmpHelperNE, expected, actual)
EqHelper<GTEST_IS_NULL_LITERAL_(val1)>::Compare, \
val1, val2)
#define EXPECT_NE(val1, val2) \
EXPECT_PRED_FORMAT2(::testing::internal::CmpHelperNE, val1, val2)
#define EXPECT_LE(val1, val2) \
EXPECT_PRED_FORMAT2(::testing::internal::CmpHelperLE, val1, val2)
#define EXPECT_LT(val1, val2) \
@ -1938,10 +1934,10 @@ class TestWithParam : public Test, public WithParamInterface<T> {
#define EXPECT_GT(val1, val2) \
EXPECT_PRED_FORMAT2(::testing::internal::CmpHelperGT, val1, val2)
#define GTEST_ASSERT_EQ(expected, actual) \
#define GTEST_ASSERT_EQ(val1, val2) \
ASSERT_PRED_FORMAT2(::testing::internal:: \
EqHelper<GTEST_IS_NULL_LITERAL_(expected)>::Compare, \
expected, actual)
EqHelper<GTEST_IS_NULL_LITERAL_(val1)>::Compare, \
val1, val2)
#define GTEST_ASSERT_NE(val1, val2) \
ASSERT_PRED_FORMAT2(::testing::internal::CmpHelperNE, val1, val2)
#define GTEST_ASSERT_LE(val1, val2) \
@ -1996,29 +1992,29 @@ class TestWithParam : public Test, public WithParamInterface<T> {
//
// These macros evaluate their arguments exactly once.
#define EXPECT_STREQ(expected, actual) \
EXPECT_PRED_FORMAT2(::testing::internal::CmpHelperSTREQ, expected, actual)
#define EXPECT_STREQ(s1, s2) \
EXPECT_PRED_FORMAT2(::testing::internal::CmpHelperSTREQ, s1, s2)
#define EXPECT_STRNE(s1, s2) \
EXPECT_PRED_FORMAT2(::testing::internal::CmpHelperSTRNE, s1, s2)
#define EXPECT_STRCASEEQ(expected, actual) \
EXPECT_PRED_FORMAT2(::testing::internal::CmpHelperSTRCASEEQ, expected, actual)
#define EXPECT_STRCASEEQ(s1, s2) \
EXPECT_PRED_FORMAT2(::testing::internal::CmpHelperSTRCASEEQ, s1, s2)
#define EXPECT_STRCASENE(s1, s2)\
EXPECT_PRED_FORMAT2(::testing::internal::CmpHelperSTRCASENE, s1, s2)
#define ASSERT_STREQ(expected, actual) \
ASSERT_PRED_FORMAT2(::testing::internal::CmpHelperSTREQ, expected, actual)
#define ASSERT_STREQ(s1, s2) \
ASSERT_PRED_FORMAT2(::testing::internal::CmpHelperSTREQ, s1, s2)
#define ASSERT_STRNE(s1, s2) \
ASSERT_PRED_FORMAT2(::testing::internal::CmpHelperSTRNE, s1, s2)
#define ASSERT_STRCASEEQ(expected, actual) \
ASSERT_PRED_FORMAT2(::testing::internal::CmpHelperSTRCASEEQ, expected, actual)
#define ASSERT_STRCASEEQ(s1, s2) \
ASSERT_PRED_FORMAT2(::testing::internal::CmpHelperSTRCASEEQ, s1, s2)
#define ASSERT_STRCASENE(s1, s2)\
ASSERT_PRED_FORMAT2(::testing::internal::CmpHelperSTRCASENE, s1, s2)
// Macros for comparing floating-point numbers.
//
// * {ASSERT|EXPECT}_FLOAT_EQ(expected, actual):
// * {ASSERT|EXPECT}_FLOAT_EQ(val1, val2):
// Tests that two float values are almost equal.
// * {ASSERT|EXPECT}_DOUBLE_EQ(expected, actual):
// * {ASSERT|EXPECT}_DOUBLE_EQ(val1, val2):
// Tests that two double values are almost equal.
// * {ASSERT|EXPECT}_NEAR(v1, v2, abs_error):
// Tests that v1 and v2 are within the given distance to each other.
@ -2028,21 +2024,21 @@ class TestWithParam : public Test, public WithParamInterface<T> {
// FloatingPoint template class in gtest-internal.h if you are
// interested in the implementation details.
#define EXPECT_FLOAT_EQ(expected, actual)\
#define EXPECT_FLOAT_EQ(val1, val2)\
EXPECT_PRED_FORMAT2(::testing::internal::CmpHelperFloatingPointEQ<float>, \
expected, actual)
val1, val2)
#define EXPECT_DOUBLE_EQ(expected, actual)\
#define EXPECT_DOUBLE_EQ(val1, val2)\
EXPECT_PRED_FORMAT2(::testing::internal::CmpHelperFloatingPointEQ<double>, \
expected, actual)
val1, val2)
#define ASSERT_FLOAT_EQ(expected, actual)\
#define ASSERT_FLOAT_EQ(val1, val2)\
ASSERT_PRED_FORMAT2(::testing::internal::CmpHelperFloatingPointEQ<float>, \
expected, actual)
val1, val2)
#define ASSERT_DOUBLE_EQ(expected, actual)\
#define ASSERT_DOUBLE_EQ(val1, val2)\
ASSERT_PRED_FORMAT2(::testing::internal::CmpHelperFloatingPointEQ<double>, \
expected, actual)
val1, val2)
#define EXPECT_NEAR(val1, val2, abs_error)\
EXPECT_PRED_FORMAT3(::testing::internal::DoubleNearPredFormat, \

View File

@ -287,7 +287,7 @@
# define GTEST_FLAG_PREFIX_DASH_ "gtest-"
# define GTEST_FLAG_PREFIX_UPPER_ "GTEST_"
# define GTEST_NAME_ "Google Test"
# define GTEST_PROJECT_URL_ "http://code.google.com/p/googletest/"
# define GTEST_PROJECT_URL_ "https://github.com/google/googletest/"
#endif // !defined(GTEST_DEV_EMAIL_)
#if !defined(GTEST_INIT_GOOGLE_TEST_NAME_)
@ -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.

View File

@ -60,7 +60,10 @@ __author__ = 'wan@google.com (Zhanyong Wan)'
import os
import re
import sets
try:
from sets import Set as set # For Python 2.3 compatibility
except ImportError:
pass
import sys
# We assume that this file is in the scripts/ directory in the Google
@ -90,10 +93,10 @@ def VerifyFileExists(directory, relative_path):
"""
if not os.path.isfile(os.path.join(directory, relative_path)):
print 'ERROR: Cannot find %s in directory %s.' % (relative_path,
directory)
print ('Please either specify a valid project root directory '
'or omit it on the command line.')
print('ERROR: Cannot find %s in directory %s.' % (relative_path,
directory))
print('Please either specify a valid project root directory '
'or omit it on the command line.')
sys.exit(1)
@ -119,11 +122,11 @@ def VerifyOutputFile(output_dir, relative_path):
# TODO(wan@google.com): The following user-interaction doesn't
# work with automated processes. We should provide a way for the
# Makefile to force overwriting the files.
print ('%s already exists in directory %s - overwrite it? (y/N) ' %
(relative_path, output_dir))
print('%s already exists in directory %s - overwrite it? (y/N) ' %
(relative_path, output_dir))
answer = sys.stdin.readline().strip()
if answer not in ['y', 'Y']:
print 'ABORTED.'
print('ABORTED.')
sys.exit(1)
# Makes sure the directory holding the output file exists; creates
@ -146,8 +149,8 @@ def ValidateOutputDir(output_dir):
def FuseGTestH(gtest_root, output_dir):
"""Scans folder gtest_root to generate gtest/gtest.h in output_dir."""
output_file = file(os.path.join(output_dir, GTEST_H_OUTPUT), 'w')
processed_files = sets.Set() # Holds all gtest headers we've processed.
output_file = open(os.path.join(output_dir, GTEST_H_OUTPUT), 'w')
processed_files = set() # Holds all gtest headers we've processed.
def ProcessFile(gtest_header_path):
"""Processes the given gtest header file."""
@ -159,7 +162,7 @@ def FuseGTestH(gtest_root, output_dir):
processed_files.add(gtest_header_path)
# Reads each line in the given gtest header.
for line in file(os.path.join(gtest_root, gtest_header_path), 'r'):
for line in open(os.path.join(gtest_root, gtest_header_path), 'r'):
m = INCLUDE_GTEST_FILE_REGEX.match(line)
if m:
# It's '#include "gtest/..."' - let's process it recursively.
@ -175,7 +178,7 @@ def FuseGTestH(gtest_root, output_dir):
def FuseGTestAllCcToFile(gtest_root, output_file):
"""Scans folder gtest_root to generate gtest/gtest-all.cc in output_file."""
processed_files = sets.Set()
processed_files = set()
def ProcessFile(gtest_source_file):
"""Processes the given gtest source file."""
@ -187,7 +190,7 @@ def FuseGTestAllCcToFile(gtest_root, output_file):
processed_files.add(gtest_source_file)
# Reads each line in the given gtest source file.
for line in file(os.path.join(gtest_root, gtest_source_file), 'r'):
for line in open(os.path.join(gtest_root, gtest_source_file), 'r'):
m = INCLUDE_GTEST_FILE_REGEX.match(line)
if m:
if 'include/' + m.group(1) == GTEST_SPI_H_SEED:
@ -218,7 +221,7 @@ def FuseGTestAllCcToFile(gtest_root, output_file):
def FuseGTestAllCc(gtest_root, output_dir):
"""Scans folder gtest_root to generate gtest/gtest-all.cc in output_dir."""
output_file = file(os.path.join(output_dir, GTEST_ALL_CC_OUTPUT), 'w')
output_file = open(os.path.join(output_dir, GTEST_ALL_CC_OUTPUT), 'w')
FuseGTestAllCcToFile(gtest_root, output_file)
output_file.close()
@ -242,7 +245,7 @@ def main():
# fuse_gtest_files.py GTEST_ROOT_DIR OUTPUT_DIR
FuseGTest(sys.argv[1], sys.argv[2])
else:
print __doc__
print(__doc__)
sys.exit(1)

View File

@ -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 {

View File

@ -58,6 +58,11 @@
# include <sys/procfs.h>
#endif // GTEST_OS_QNX
#if GTEST_OS_AIX
# include <procinfo.h>
# include <sys/types.h>
#endif // GTEST_OS_AIX
#include "gtest/gtest-spi.h"
#include "gtest/gtest-message.h"
#include "gtest/internal/gtest-internal.h"
@ -146,6 +151,19 @@ size_t GetThreadCount() {
}
}
#elif GTEST_OS_AIX
size_t GetThreadCount() {
struct procentry64 entry;
pid_t pid = getpid();
int status = getprocs64(&entry, sizeof(entry), NULL, 0, &pid, 1);
if (status == 1) {
return entry.pi_thcount;
} else {
return 0;
}
}
#else
size_t GetThreadCount() {

View File

@ -339,12 +339,7 @@ void PrintTo(const wchar_t* s, ostream* os) {
*os << "NULL";
} else {
*os << ImplicitCast_<const void*>(s) << " pointing to ";
#ifndef __OS2__
PrintCharsAsStringTo(s, std::wcslen(s), os);
#else
// OS/2 gcc does not declare wcslen() in std namesapce.
PrintCharsAsStringTo(s, wcslen(s), os);
#endif
}
}
#endif // wchar_t is native

View File

@ -1301,41 +1301,41 @@ std::vector<std::string> SplitEscapedString(const std::string& str) {
// and their values, as strings. For example, for ASSERT_EQ(foo, bar)
// where foo is 5 and bar is 6, we have:
//
// expected_expression: "foo"
// actual_expression: "bar"
// expected_value: "5"
// actual_value: "6"
// lhs_expression: "foo"
// rhs_expression: "bar"
// lhs_value: "5"
// rhs_value: "6"
//
// The ignoring_case parameter is true iff the assertion is a
// *_STRCASEEQ*. When it's true, the string " (ignoring case)" will
// *_STRCASEEQ*. When it's true, the string "Ignoring case" will
// be inserted into the message.
AssertionResult EqFailure(const char* expected_expression,
const char* actual_expression,
const std::string& expected_value,
const std::string& actual_value,
AssertionResult EqFailure(const char* lhs_expression,
const char* rhs_expression,
const std::string& lhs_value,
const std::string& rhs_value,
bool ignoring_case) {
Message msg;
msg << "Value of: " << actual_expression;
if (actual_value != actual_expression) {
msg << "\n Actual: " << actual_value;
msg << " Expected: " << lhs_expression;
if (lhs_value != lhs_expression) {
msg << "\n Which is: " << lhs_value;
}
msg << "\nTo be equal to: " << rhs_expression;
if (rhs_value != rhs_expression) {
msg << "\n Which is: " << rhs_value;
}
msg << "\nExpected: " << expected_expression;
if (ignoring_case) {
msg << " (ignoring case)";
}
if (expected_value != expected_expression) {
msg << "\nWhich is: " << expected_value;
msg << "\nIgnoring case";
}
if (!expected_value.empty() && !actual_value.empty()) {
const std::vector<std::string> expected_lines =
SplitEscapedString(expected_value);
const std::vector<std::string> actual_lines =
SplitEscapedString(actual_value);
if (expected_lines.size() > 1 || actual_lines.size() > 1) {
if (!lhs_value.empty() && !rhs_value.empty()) {
const std::vector<std::string> lhs_lines =
SplitEscapedString(lhs_value);
const std::vector<std::string> rhs_lines =
SplitEscapedString(rhs_value);
if (lhs_lines.size() > 1 || rhs_lines.size() > 1) {
msg << "\nWith diff:\n"
<< edit_distance::CreateUnifiedDiff(expected_lines, actual_lines);
<< edit_distance::CreateUnifiedDiff(lhs_lines, rhs_lines);
}
}
@ -1434,18 +1434,18 @@ namespace internal {
// The helper function for {ASSERT|EXPECT}_EQ with int or enum
// arguments.
AssertionResult CmpHelperEQ(const char* expected_expression,
const char* actual_expression,
BiggestInt expected,
BiggestInt actual) {
if (expected == actual) {
AssertionResult CmpHelperEQ(const char* lhs_expression,
const char* rhs_expression,
BiggestInt lhs,
BiggestInt rhs) {
if (lhs == rhs) {
return AssertionSuccess();
}
return EqFailure(expected_expression,
actual_expression,
FormatForComparisonFailureMessage(expected, actual),
FormatForComparisonFailureMessage(actual, expected),
return EqFailure(lhs_expression,
rhs_expression,
FormatForComparisonFailureMessage(lhs, rhs),
FormatForComparisonFailureMessage(rhs, lhs),
false);
}
@ -1484,34 +1484,34 @@ GTEST_IMPL_CMP_HELPER_(GT, > )
#undef GTEST_IMPL_CMP_HELPER_
// The helper function for {ASSERT|EXPECT}_STREQ.
AssertionResult CmpHelperSTREQ(const char* expected_expression,
const char* actual_expression,
const char* expected,
const char* actual) {
if (String::CStringEquals(expected, actual)) {
AssertionResult CmpHelperSTREQ(const char* lhs_expression,
const char* rhs_expression,
const char* lhs,
const char* rhs) {
if (String::CStringEquals(lhs, rhs)) {
return AssertionSuccess();
}
return EqFailure(expected_expression,
actual_expression,
PrintToString(expected),
PrintToString(actual),
return EqFailure(lhs_expression,
rhs_expression,
PrintToString(lhs),
PrintToString(rhs),
false);
}
// The helper function for {ASSERT|EXPECT}_STRCASEEQ.
AssertionResult CmpHelperSTRCASEEQ(const char* expected_expression,
const char* actual_expression,
const char* expected,
const char* actual) {
if (String::CaseInsensitiveCStringEquals(expected, actual)) {
AssertionResult CmpHelperSTRCASEEQ(const char* lhs_expression,
const char* rhs_expression,
const char* lhs,
const char* rhs) {
if (String::CaseInsensitiveCStringEquals(lhs, rhs)) {
return AssertionSuccess();
}
return EqFailure(expected_expression,
actual_expression,
PrintToString(expected),
PrintToString(actual),
return EqFailure(lhs_expression,
rhs_expression,
PrintToString(lhs),
PrintToString(rhs),
true);
}
@ -1866,18 +1866,18 @@ bool String::WideCStringEquals(const wchar_t * lhs, const wchar_t * rhs) {
}
// Helper function for *_STREQ on wide strings.
AssertionResult CmpHelperSTREQ(const char* expected_expression,
const char* actual_expression,
const wchar_t* expected,
const wchar_t* actual) {
if (String::WideCStringEquals(expected, actual)) {
AssertionResult CmpHelperSTREQ(const char* lhs_expression,
const char* rhs_expression,
const wchar_t* lhs,
const wchar_t* rhs) {
if (String::WideCStringEquals(lhs, rhs)) {
return AssertionSuccess();
}
return EqFailure(expected_expression,
actual_expression,
PrintToString(expected),
PrintToString(actual),
return EqFailure(lhs_expression,
rhs_expression,
PrintToString(lhs),
PrintToString(rhs),
false);
}
@ -2930,6 +2930,8 @@ bool ShouldUseColor(bool stdout_is_tty) {
String::CStringEquals(term, "xterm-256color") ||
String::CStringEquals(term, "screen") ||
String::CStringEquals(term, "screen-256color") ||
String::CStringEquals(term, "tmux") ||
String::CStringEquals(term, "tmux-256color") ||
String::CStringEquals(term, "rxvt-unicode") ||
String::CStringEquals(term, "rxvt-unicode-256color") ||
String::CStringEquals(term, "linux") ||

View File

@ -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) {

View File

@ -47,8 +47,8 @@ environ = os.environ.copy()
def AssertEq(expected, actual):
if expected != actual:
print 'Expected: %s' % (expected,)
print ' Actual: %s' % (actual,)
print('Expected: %s' % (expected,))
print(' Actual: %s' % (actual,))
raise AssertionError

View File

@ -44,7 +44,10 @@ __author__ = 'wan@google.com (Zhanyong Wan)'
import os
import re
import sets
try:
from sets import Set as set # For Python 2.3 compatibility
except ImportError:
pass
import sys
import gtest_test_utils
@ -58,7 +61,7 @@ import gtest_test_utils
# exception is thrown if the input is anything other than 'True' nor 'False'.
os.environ['EMPTY_VAR'] = ''
child = gtest_test_utils.Subprocess(
[sys.executable, '-c', 'import os; print \'EMPTY_VAR\' in os.environ'])
[sys.executable, '-c', 'import os; print(\'EMPTY_VAR\' in os.environ)'])
CAN_PASS_EMPTY_ENV = eval(child.output)
@ -71,7 +74,7 @@ CAN_PASS_EMPTY_ENV = eval(child.output)
os.environ['UNSET_VAR'] = 'X'
del os.environ['UNSET_VAR']
child = gtest_test_utils.Subprocess(
[sys.executable, '-c', 'import os; print \'UNSET_VAR\' not in os.environ'])
[sys.executable, '-c', 'import os; print(\'UNSET_VAR\' not in os.environ)'])
CAN_UNSET_ENV = eval(child.output)
@ -243,14 +246,14 @@ class GTestFilterUnitTest(gtest_test_utils.TestCase):
for slice_var in list_of_sets:
full_partition.extend(slice_var)
self.assertEqual(len(set_var), len(full_partition))
self.assertEqual(sets.Set(set_var), sets.Set(full_partition))
self.assertEqual(set(set_var), set(full_partition))
def AdjustForParameterizedTests(self, tests_to_run):
"""Adjust tests_to_run in case value parameterized tests are disabled."""
global param_tests_present
if not param_tests_present:
return list(sets.Set(tests_to_run) - sets.Set(PARAM_TESTS))
return list(set(tests_to_run) - set(PARAM_TESTS))
else:
return tests_to_run

View File

@ -279,7 +279,7 @@ class GTestOutputTest(gtest_test_utils.TestCase):
def testOutput(self):
output = GetOutputOfAllCommands()
golden_file = open(GOLDEN_PATH, 'rb')
golden_file = open(GOLDEN_PATH, 'r')
# A mis-configured source control system can cause \r appear in EOL
# sequences when we read the golden file irrespective of an operating
# system used. Therefore, we need to strip those \r's from newlines

View File

@ -5,8 +5,8 @@ Value of: false
Actual: false
Expected: true
gtest_output_test_.cc:#: Failure
Value of: 3
Expected: 2
Expected: 2
To be equal to: 3
[==========] Running 66 tests from 29 test cases.
[----------] Global test environment set-up.
FooEnvironment::SetUp() called.
@ -34,21 +34,21 @@ BarEnvironment::SetUp() called.
[----------] 2 tests from NonfatalFailureTest
[ RUN ] NonfatalFailureTest.EscapesStringOperands
gtest_output_test_.cc:#: Failure
Value of: actual
Actual: "actual \"string\""
Expected: kGoldenString
Which is: "\"Line"
Expected: kGoldenString
Which is: "\"Line"
To be equal to: actual
Which is: "actual \"string\""
gtest_output_test_.cc:#: Failure
Value of: actual
Actual: "actual \"string\""
Expected: golden
Which is: "\"Line"
Expected: golden
Which is: "\"Line"
To be equal to: actual
Which is: "actual \"string\""
[ FAILED ] NonfatalFailureTest.EscapesStringOperands
[ RUN ] NonfatalFailureTest.DiffForLongStrings
gtest_output_test_.cc:#: Failure
Value of: "Line 2"
Expected: golden_str
Which is: "\"Line\0 1\"\nLine 2"
Expected: golden_str
Which is: "\"Line\0 1\"\nLine 2"
To be equal to: "Line 2"
With diff:
@@ -1,2 @@
-\"Line\0 1\"
@ -59,16 +59,16 @@ With diff:
[ RUN ] FatalFailureTest.FatalFailureInSubroutine
(expecting a failure that x should be 1)
gtest_output_test_.cc:#: Failure
Value of: x
Actual: 2
Expected: 1
Expected: 1
To be equal to: x
Which is: 2
[ FAILED ] FatalFailureTest.FatalFailureInSubroutine
[ RUN ] FatalFailureTest.FatalFailureInNestedSubroutine
(expecting a failure that x should be 1)
gtest_output_test_.cc:#: Failure
Value of: x
Actual: 2
Expected: 1
Expected: 1
To be equal to: x
Which is: 2
[ FAILED ] FatalFailureTest.FatalFailureInNestedSubroutine
[ RUN ] FatalFailureTest.NonfatalFailureInSubroutine
(expecting a failure on false)
@ -107,39 +107,39 @@ This failure is expected, and shouldn't have a trace.
[ RUN ] SCOPED_TRACETest.WorksInLoop
(expected to fail)
gtest_output_test_.cc:#: Failure
Value of: n
Actual: 1
Expected: 2
Expected: 2
To be equal to: n
Which is: 1
Google Test trace:
gtest_output_test_.cc:#: i = 1
gtest_output_test_.cc:#: Failure
Value of: n
Actual: 2
Expected: 1
Expected: 1
To be equal to: n
Which is: 2
Google Test trace:
gtest_output_test_.cc:#: i = 2
[ FAILED ] SCOPED_TRACETest.WorksInLoop
[ RUN ] SCOPED_TRACETest.WorksInSubroutine
(expected to fail)
gtest_output_test_.cc:#: Failure
Value of: n
Actual: 1
Expected: 2
Expected: 2
To be equal to: n
Which is: 1
Google Test trace:
gtest_output_test_.cc:#: n = 1
gtest_output_test_.cc:#: Failure
Value of: n
Actual: 2
Expected: 1
Expected: 1
To be equal to: n
Which is: 2
Google Test trace:
gtest_output_test_.cc:#: n = 2
[ FAILED ] SCOPED_TRACETest.WorksInSubroutine
[ RUN ] SCOPED_TRACETest.CanBeNested
(expected to fail)
gtest_output_test_.cc:#: Failure
Value of: n
Actual: 2
Expected: 1
Expected: 1
To be equal to: n
Which is: 2
Google Test trace:
gtest_output_test_.cc:#: n = 2
gtest_output_test_.cc:#:
@ -437,9 +437,9 @@ Expected: 1 fatal failure
[ OK ] TypedTest/0.Success
[ RUN ] TypedTest/0.Failure
gtest_output_test_.cc:#: Failure
Value of: TypeParam()
Actual: 0
Expected: 1
Expected: 1
To be equal to: TypeParam()
Which is: 0
Expected failure
[ FAILED ] TypedTest/0.Failure, where TypeParam = int
[----------] 2 tests from Unsigned/TypedTestP/0, where TypeParam = unsigned char
@ -447,10 +447,10 @@ Expected failure
[ OK ] Unsigned/TypedTestP/0.Success
[ RUN ] Unsigned/TypedTestP/0.Failure
gtest_output_test_.cc:#: Failure
Value of: TypeParam()
Actual: '\0'
Expected: 1U
Which is: 1
Expected: 1U
Which is: 1
To be equal to: TypeParam()
Which is: '\0'
Expected failure
[ FAILED ] Unsigned/TypedTestP/0.Failure, where TypeParam = unsigned char
[----------] 2 tests from Unsigned/TypedTestP/1, where TypeParam = unsigned int
@ -458,10 +458,10 @@ Expected failure
[ OK ] Unsigned/TypedTestP/1.Success
[ RUN ] Unsigned/TypedTestP/1.Failure
gtest_output_test_.cc:#: Failure
Value of: TypeParam()
Actual: 0
Expected: 1U
Which is: 1
Expected: 1U
Which is: 1
To be equal to: TypeParam()
Which is: 0
Expected failure
[ FAILED ] Unsigned/TypedTestP/1.Failure, where TypeParam = unsigned int
[----------] 4 tests from ExpectFailureTest
@ -597,18 +597,18 @@ Expected non-fatal failure.
[----------] 1 test from PrintingFailingParams/FailingParamTest
[ RUN ] PrintingFailingParams/FailingParamTest.Fails/0
gtest_output_test_.cc:#: Failure
Value of: GetParam()
Actual: 2
Expected: 1
Expected: 1
To be equal to: GetParam()
Which is: 2
[ FAILED ] PrintingFailingParams/FailingParamTest.Fails/0, where GetParam() = 2
[----------] 2 tests from PrintingStrings/ParamTest
[ RUN ] PrintingStrings/ParamTest.Success/a
[ OK ] PrintingStrings/ParamTest.Success/a
[ RUN ] PrintingStrings/ParamTest.Failure/a
gtest_output_test_.cc:#: Failure
Value of: GetParam()
Actual: "a"
Expected: "b"
Expected: "b"
To be equal to: GetParam()
Which is: "a"
Expected failure
[ FAILED ] PrintingStrings/ParamTest.Failure/a, where GetParam() = "a"
[----------] Global test environment tear-down
@ -678,16 +678,16 @@ Expected fatal failure.
[ RUN ] FatalFailureTest.FatalFailureInSubroutine
(expecting a failure that x should be 1)
gtest_output_test_.cc:#: Failure
Value of: x
Actual: 2
Expected: 1
Expected: 1
To be equal to: x
Which is: 2
[ FAILED ] FatalFailureTest.FatalFailureInSubroutine (? ms)
[ RUN ] FatalFailureTest.FatalFailureInNestedSubroutine
(expecting a failure that x should be 1)
gtest_output_test_.cc:#: Failure
Value of: x
Actual: 2
Expected: 1
Expected: 1
To be equal to: x
Which is: 2
[ FAILED ] FatalFailureTest.FatalFailureInNestedSubroutine (? ms)
[ RUN ] FatalFailureTest.NonfatalFailureInSubroutine
(expecting a failure on false)

View File

@ -178,7 +178,7 @@ def GetTestExecutablePath(executable_name, build_dir=None):
'Unable to find the test binary "%s". Please make sure to provide\n'
'a path to the binary via the --build_dir flag or the BUILD_DIR\n'
'environment variable.' % path)
print >> sys.stderr, message
sys.stdout.write(message)
sys.exit(1)
return path

View File

@ -70,7 +70,7 @@ def SetEnvVar(env_var, value):
def Run(command):
"""Runs a command; returns True/False if its exit code is/isn't 0."""
print 'Running "%s". . .' % ' '.join(command)
print('Running "%s". . .' % ' '.join(command))
p = gtest_test_utils.Subprocess(command)
return p.exited and p.exit_code == 0

View File

@ -46,8 +46,8 @@ def Assert(condition):
def AssertEq(expected, actual):
if expected != actual:
print 'Expected: %s' % (expected,)
print ' Actual: %s' % (actual,)
print('Expected: %s' % (expected,))
print(' Actual: %s' % (actual,))
raise AssertionError

View File

@ -2466,7 +2466,7 @@ TEST(StringAssertionTest, ASSERT_STRCASEEQ) {
ASSERT_STRCASEEQ("", "");
EXPECT_FATAL_FAILURE(ASSERT_STRCASEEQ("Hi", "hi2"),
"(ignoring case)");
"Ignoring case");
}
// Tests ASSERT_STRCASENE.
@ -3260,7 +3260,7 @@ TEST_F(SingleEvaluationTest, ASSERT_STR) {
// failed EXPECT_STRCASEEQ
EXPECT_NONFATAL_FAILURE(EXPECT_STRCASEEQ(p1_++, p2_++),
"ignoring case");
"Ignoring case");
EXPECT_EQ(s1_ + 2, p1_);
EXPECT_EQ(s2_ + 2, p2_);
}
@ -3528,35 +3528,35 @@ TEST(AssertionTest, EqFailure) {
EqFailure("foo", "bar", foo_val, bar_val, false)
.failure_message());
EXPECT_STREQ(
"Value of: bar\n"
" Actual: 6\n"
"Expected: foo\n"
"Which is: 5",
" Expected: foo\n"
" Which is: 5\n"
"To be equal to: bar\n"
" Which is: 6",
msg1.c_str());
const std::string msg2(
EqFailure("foo", "6", foo_val, bar_val, false)
.failure_message());
EXPECT_STREQ(
"Value of: 6\n"
"Expected: foo\n"
"Which is: 5",
" Expected: foo\n"
" Which is: 5\n"
"To be equal to: 6",
msg2.c_str());
const std::string msg3(
EqFailure("5", "bar", foo_val, bar_val, false)
.failure_message());
EXPECT_STREQ(
"Value of: bar\n"
" Actual: 6\n"
"Expected: 5",
" Expected: 5\n"
"To be equal to: bar\n"
" Which is: 6",
msg3.c_str());
const std::string msg4(
EqFailure("5", "6", foo_val, bar_val, false).failure_message());
EXPECT_STREQ(
"Value of: 6\n"
"Expected: 5",
" Expected: 5\n"
"To be equal to: 6",
msg4.c_str());
const std::string msg5(
@ -3564,10 +3564,11 @@ TEST(AssertionTest, EqFailure) {
std::string("\"x\""), std::string("\"y\""),
true).failure_message());
EXPECT_STREQ(
"Value of: bar\n"
" Actual: \"y\"\n"
"Expected: foo (ignoring case)\n"
"Which is: \"x\"",
" Expected: foo\n"
" Which is: \"x\"\n"
"To be equal to: bar\n"
" Which is: \"y\"\n"
"Ignoring case",
msg5.c_str());
}
@ -3579,11 +3580,11 @@ TEST(AssertionTest, EqFailureWithDiff) {
const std::string msg1(
EqFailure("left", "right", left, right, false).failure_message());
EXPECT_STREQ(
"Value of: right\n"
" Actual: 1\\n2\\n3\\n4\\n5\\n6\\n7\\n8\\n9\\n11\\n12\\n13\\n14\n"
"Expected: left\n"
"Which is: "
" Expected: left\n"
" Which is: "
"1\\n2XXX\\n3\\n5\\n6\\n7\\n8\\n9\\n10\\n11\\n12XXX\\n13\\n14\\n15\n"
"To be equal to: right\n"
" Which is: 1\\n2\\n3\\n4\\n5\\n6\\n7\\n8\\n9\\n11\\n12\\n13\\n14\n"
"With diff:\n@@ -1,5 +1,6 @@\n 1\n-2XXX\n+2\n 3\n+4\n 5\n 6\n"
"@@ -7,8 +8,6 @@\n 8\n 9\n-10\n 11\n-12XXX\n+12\n 13\n 14\n-15\n",
msg1.c_str());
@ -3678,9 +3679,9 @@ TEST(ExpectTest, ASSERT_EQ_Double) {
TEST(AssertionTest, ASSERT_EQ) {
ASSERT_EQ(5, 2 + 3);
EXPECT_FATAL_FAILURE(ASSERT_EQ(5, 2*3),
"Value of: 2*3\n"
" Actual: 6\n"
"Expected: 5");
" Expected: 5\n"
"To be equal to: 2*3\n"
" Which is: 6");
}
// Tests ASSERT_EQ(NULL, pointer).
@ -3697,7 +3698,7 @@ TEST(AssertionTest, ASSERT_EQ_NULL) {
// A failure.
static int n = 0;
EXPECT_FATAL_FAILURE(ASSERT_EQ(NULL, &n),
"Value of: &n\n");
"To be equal to: &n\n");
}
#endif // GTEST_CAN_COMPARE_NULL
@ -3812,7 +3813,7 @@ void TestEq1(int x) {
// Tests calling a test subroutine that's not part of a fixture.
TEST(AssertionTest, NonFixtureSubroutine) {
EXPECT_FATAL_FAILURE(TestEq1(2),
"Value of: x");
"To be equal to: x");
}
// An uncopyable class.
@ -3861,7 +3862,7 @@ TEST(AssertionTest, AssertWorksWithUncopyableObject) {
EXPECT_FATAL_FAILURE(TestAssertNonPositive(),
"IsPositiveUncopyable(y) evaluates to false, where\ny evaluates to -1");
EXPECT_FATAL_FAILURE(TestAssertEqualsUncopyable(),
"Value of: y\n Actual: -1\nExpected: x\nWhich is: 5");
"Expected: x\n Which is: 5\nTo be equal to: y\n Which is: -1");
}
// Tests that uncopyable objects can be used in expects.
@ -3873,7 +3874,7 @@ TEST(AssertionTest, ExpectWorksWithUncopyableObject) {
"IsPositiveUncopyable(y) evaluates to false, where\ny evaluates to -1");
EXPECT_EQ(x, x);
EXPECT_NONFATAL_FAILURE(EXPECT_EQ(x, y),
"Value of: y\n Actual: -1\nExpected: x\nWhich is: 5");
"Expected: x\n Which is: 5\nTo be equal to: y\n Which is: -1");
}
enum NamedEnum {
@ -3885,7 +3886,7 @@ TEST(AssertionTest, NamedEnum) {
EXPECT_EQ(kE1, kE1);
EXPECT_LT(kE1, kE2);
EXPECT_NONFATAL_FAILURE(EXPECT_EQ(kE1, kE2), "Which is: 0");
EXPECT_NONFATAL_FAILURE(EXPECT_EQ(kE1, kE2), "Actual: 1");
EXPECT_NONFATAL_FAILURE(EXPECT_EQ(kE1, kE2), "Which is: 1");
}
// The version of gcc used in XCode 2.2 has a bug and doesn't allow
@ -3949,9 +3950,9 @@ TEST(AssertionTest, AnonymousEnum) {
// ICE's in C++Builder.
EXPECT_FATAL_FAILURE(ASSERT_EQ(kCaseA, kCaseB),
"Value of: kCaseB");
"To be equal to: kCaseB");
EXPECT_FATAL_FAILURE(ASSERT_EQ(kCaseA, kCaseC),
"Actual: 42");
"Which is: 42");
# endif
EXPECT_FATAL_FAILURE(ASSERT_EQ(kCaseA, kCaseC),
@ -4389,9 +4390,9 @@ TEST(ExpectTest, ExpectFalseWithAssertionResult) {
TEST(ExpectTest, EXPECT_EQ) {
EXPECT_EQ(5, 2 + 3);
EXPECT_NONFATAL_FAILURE(EXPECT_EQ(5, 2*3),
"Value of: 2*3\n"
" Actual: 6\n"
"Expected: 5");
" Expected: 5\n"
"To be equal to: 2*3\n"
" Which is: 6");
EXPECT_NONFATAL_FAILURE(EXPECT_EQ(5, 2 - 3),
"2 - 3");
}
@ -4422,7 +4423,7 @@ TEST(ExpectTest, EXPECT_EQ_NULL) {
// A failure.
int n = 0;
EXPECT_NONFATAL_FAILURE(EXPECT_EQ(NULL, &n),
"Value of: &n\n");
"To be equal to: &n\n");
}
#endif // GTEST_CAN_COMPARE_NULL
@ -4538,7 +4539,7 @@ TEST(ExpectTest, EXPECT_ANY_THROW) {
TEST(ExpectTest, ExpectPrecedence) {
EXPECT_EQ(1 < 2, true);
EXPECT_NONFATAL_FAILURE(EXPECT_EQ(true, true && false),
"Value of: true && false");
"To be equal to: true && false");
}
@ -4685,7 +4686,7 @@ TEST(EqAssertionTest, Bool) {
EXPECT_FATAL_FAILURE({
bool false_value = false;
ASSERT_EQ(false_value, true);
}, "Value of: true");
}, "To be equal to: true");
}
// Tests using int values in {EXPECT|ASSERT}_EQ.
@ -4719,10 +4720,10 @@ TEST(EqAssertionTest, WideChar) {
EXPECT_EQ(L'b', L'b');
EXPECT_NONFATAL_FAILURE(EXPECT_EQ(L'\0', L'x'),
"Value of: L'x'\n"
" Actual: L'x' (120, 0x78)\n"
"Expected: L'\0'\n"
"Which is: L'\0' (0, 0x0)");
" Expected: L'\0'\n"
" Which is: L'\0' (0, 0x0)\n"
"To be equal to: L'x'\n"
" Which is: L'x' (120, 0x78)");
static wchar_t wchar;
wchar = L'b';
@ -4730,7 +4731,7 @@ TEST(EqAssertionTest, WideChar) {
"wchar");
wchar = 0x8119;
EXPECT_FATAL_FAILURE(ASSERT_EQ(static_cast<wchar_t>(0x8120), wchar),
"Value of: wchar");
"To be equal to: wchar");
}
// Tests using ::std::string values in {EXPECT|ASSERT}_EQ.
@ -4759,8 +4760,8 @@ TEST(EqAssertionTest, StdString) {
static ::std::string str3(str1);
str3.at(2) = '\0';
EXPECT_FATAL_FAILURE(ASSERT_EQ(str1, str3),
"Value of: str3\n"
" Actual: \"A \\0 in the middle\"");
"To be equal to: str3\n"
" Which is: \"A \\0 in the middle\"");
}
#if GTEST_HAS_STD_WSTRING
@ -4880,7 +4881,7 @@ TEST(EqAssertionTest, CharPointer) {
ASSERT_EQ(p1, p1);
EXPECT_NONFATAL_FAILURE(EXPECT_EQ(p0, p2),
"Value of: p2");
"To be equal to: p2");
EXPECT_NONFATAL_FAILURE(EXPECT_EQ(p1, p2),
"p2");
EXPECT_FATAL_FAILURE(ASSERT_EQ(reinterpret_cast<char*>(0x1234),
@ -4902,7 +4903,7 @@ TEST(EqAssertionTest, WideCharPointer) {
EXPECT_EQ(p0, p0);
EXPECT_NONFATAL_FAILURE(EXPECT_EQ(p0, p2),
"Value of: p2");
"To be equal to: p2");
EXPECT_NONFATAL_FAILURE(EXPECT_EQ(p1, p2),
"p2");
void* pv3 = (void*)0x1234; // NOLINT
@ -6840,6 +6841,12 @@ TEST(ColoredOutputTest, UsesColorsWhenTermSupportsColors) {
SetEnv("TERM", "screen-256color"); // TERM supports colors.
EXPECT_TRUE(ShouldUseColor(true)); // Stdout is a TTY.
SetEnv("TERM", "tmux"); // TERM supports colors.
EXPECT_TRUE(ShouldUseColor(true)); // Stdout is a TTY.
SetEnv("TERM", "tmux-256color"); // TERM supports colors.
EXPECT_TRUE(ShouldUseColor(true)); // Stdout is a TTY.
SetEnv("TERM", "rxvt-unicode"); // TERM supports colors.
EXPECT_TRUE(ShouldUseColor(true)); // Stdout is a TTY.

View File

@ -64,20 +64,20 @@ EXPECTED_NON_EMPTY_XML = """<?xml version="1.0" encoding="UTF-8"?>
</testsuite>
<testsuite name="FailedTest" tests="1" failures="1" disabled="0" errors="0" time="*">
<testcase name="Fails" status="run" time="*" classname="FailedTest">
<failure message="gtest_xml_output_unittest_.cc:*&#x0A;Value of: 2&#x0A;Expected: 1" type=""><![CDATA[gtest_xml_output_unittest_.cc:*
Value of: 2
Expected: 1%(stack)s]]></failure>
<failure message="gtest_xml_output_unittest_.cc:*&#x0A; Expected: 1&#x0A;To be equal to: 2" type=""><![CDATA[gtest_xml_output_unittest_.cc:*
Expected: 1
To be equal to: 2%(stack)s]]></failure>
</testcase>
</testsuite>
<testsuite name="MixedResultTest" tests="3" failures="1" disabled="1" errors="0" time="*">
<testcase name="Succeeds" status="run" time="*" classname="MixedResultTest"/>
<testcase name="Fails" status="run" time="*" classname="MixedResultTest">
<failure message="gtest_xml_output_unittest_.cc:*&#x0A;Value of: 2&#x0A;Expected: 1" type=""><![CDATA[gtest_xml_output_unittest_.cc:*
Value of: 2
Expected: 1%(stack)s]]></failure>
<failure message="gtest_xml_output_unittest_.cc:*&#x0A;Value of: 3&#x0A;Expected: 2" type=""><![CDATA[gtest_xml_output_unittest_.cc:*
Value of: 3
Expected: 2%(stack)s]]></failure>
<failure message="gtest_xml_output_unittest_.cc:*&#x0A; Expected: 1&#x0A;To be equal to: 2" type=""><![CDATA[gtest_xml_output_unittest_.cc:*
Expected: 1
To be equal to: 2%(stack)s]]></failure>
<failure message="gtest_xml_output_unittest_.cc:*&#x0A; Expected: 2&#x0A;To be equal to: 3" type=""><![CDATA[gtest_xml_output_unittest_.cc:*
Expected: 2
To be equal to: 3%(stack)s]]></failure>
</testcase>
<testcase name="DISABLED_test" status="notrun" time="*" classname="MixedResultTest"/>
</testsuite>
@ -209,7 +209,8 @@ class GTestXMLOutputUnitTest(gtest_xml_test_utils.GTestXMLTestCase):
'gtest_no_test_unittest')
try:
os.remove(output_file)
except OSError, e:
except OSError:
e = sys.exc_info()[1]
if e.errno != errno.ENOENT:
raise

View File

@ -101,7 +101,7 @@ class GTestXMLTestCase(gtest_test_utils.TestCase):
self.assertEquals(
len(expected_children), len(actual_children),
'number of child elements differ in element ' + actual_node.tagName)
for child_id, child in expected_children.iteritems():
for child_id, child in expected_children.items():
self.assert_(child_id in actual_children,
'<%s> is not in <%s> (in element %s)' %
(child_id, actual_children, actual_node.tagName))