mirror of
https://github.com/jbeder/yaml-cpp.git
synced 2025-12-12 10:41:43 +00:00
test: Upgrade googlemock 1.7.0 to googletest 1.8.0
Note that with the release of 1.8.0, googlemock and googletest are unified into a single release.
This commit is contained in:
Roger Leigh
@@ -8,7 +8,7 @@ EXAMPLE_PATH =
|
||||
|
||||
# One or more directories and files to exclude from documentation generation.
|
||||
# Use relative paths with respect to the repository root directory.
|
||||
EXCLUDE = test/gmock-1.7.0/
|
||||
EXCLUDE = test/gtest-1.8.0/
|
||||
|
||||
# One or more wildcard patterns to exclude files and directories from document
|
||||
# generation.
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
set(gtest_force_shared_crt ${MSVC_SHARED_RT} CACHE BOOL
|
||||
"Use shared (DLL) run-time lib even when Google Test built as a static lib.")
|
||||
add_subdirectory(gmock-1.7.0)
|
||||
include_directories(SYSTEM gmock-1.7.0/gtest/include)
|
||||
include_directories(SYSTEM gmock-1.7.0/include)
|
||||
add_subdirectory(gtest-1.8.0)
|
||||
include_directories(SYSTEM gtest-1.8.0/googlemock/include)
|
||||
include_directories(SYSTEM gtest-1.8.0/googletest/include)
|
||||
|
||||
if(WIN32 AND BUILD_SHARED_LIBS)
|
||||
add_definitions("-DGTEST_LINKED_AS_SHARED_LIBRARY")
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@@ -1,369 +0,0 @@
|
||||
Google C++ Mocking Framework
|
||||
============================
|
||||
|
||||
http://code.google.com/p/googlemock/
|
||||
|
||||
Overview
|
||||
--------
|
||||
|
||||
Google's framework for writing and using C++ mock classes on a variety
|
||||
of platforms (Linux, Mac OS X, Windows, Windows CE, Symbian, etc).
|
||||
Inspired by jMock, EasyMock, and Hamcrest, and designed with C++'s
|
||||
specifics in mind, it can help you derive better designs of your
|
||||
system and write better tests.
|
||||
|
||||
Google Mock:
|
||||
|
||||
- provides a declarative syntax for defining mocks,
|
||||
- can easily define partial (hybrid) mocks, which are a cross of real
|
||||
and mock objects,
|
||||
- handles functions of arbitrary types and overloaded functions,
|
||||
- comes with a rich set of matchers for validating function arguments,
|
||||
- uses an intuitive syntax for controlling the behavior of a mock,
|
||||
- does automatic verification of expectations (no record-and-replay
|
||||
needed),
|
||||
- allows arbitrary (partial) ordering constraints on
|
||||
function calls to be expressed,
|
||||
- lets a user extend it by defining new matchers and actions.
|
||||
- does not use exceptions, and
|
||||
- is easy to learn and use.
|
||||
|
||||
Please see the project page above for more information as well as the
|
||||
mailing list for questions, discussions, and development. There is
|
||||
also an IRC channel on OFTC (irc.oftc.net) #gtest available. Please
|
||||
join us!
|
||||
|
||||
Please note that code under scripts/generator/ is from the cppclean
|
||||
project (http://code.google.com/p/cppclean/) and under the Apache
|
||||
License, which is different from Google Mock's license.
|
||||
|
||||
Requirements for End Users
|
||||
--------------------------
|
||||
|
||||
Google Mock is implemented on top of the Google Test C++ testing
|
||||
framework (http://code.google.com/p/googletest/), and includes the
|
||||
latter as part of the SVN repositary and distribution package. You
|
||||
must use the bundled version of Google Test when using Google Mock, or
|
||||
you may get compiler/linker errors.
|
||||
|
||||
You can also easily configure Google Mock to work with another testing
|
||||
framework of your choice; although it will still need Google Test as
|
||||
an internal dependency. Please read
|
||||
http://code.google.com/p/googlemock/wiki/ForDummies#Using_Google_Mock_with_Any_Testing_Framework
|
||||
for how to do it.
|
||||
|
||||
Google Mock depends on advanced C++ features and thus requires a more
|
||||
modern compiler. The following are needed to use Google Mock:
|
||||
|
||||
### Linux Requirements ###
|
||||
|
||||
These are the base requirements to build and use Google Mock from a source
|
||||
package (as described below):
|
||||
|
||||
* GNU-compatible Make or "gmake"
|
||||
* POSIX-standard shell
|
||||
* POSIX(-2) Regular Expressions (regex.h)
|
||||
* C++98-standard-compliant compiler (e.g. GCC 3.4 or newer)
|
||||
|
||||
### Windows Requirements ###
|
||||
|
||||
* Microsoft Visual C++ 8.0 SP1 or newer
|
||||
|
||||
### Mac OS X Requirements ###
|
||||
|
||||
* Mac OS X 10.4 Tiger or newer
|
||||
* Developer Tools Installed
|
||||
|
||||
Requirements for Contributors
|
||||
-----------------------------
|
||||
|
||||
We welcome patches. If you plan to contribute a patch, you need to
|
||||
build Google Mock and its own tests from an SVN checkout (described
|
||||
below), which has further requirements:
|
||||
|
||||
* Automake version 1.9 or newer
|
||||
* Autoconf version 2.59 or newer
|
||||
* Libtool / Libtoolize
|
||||
* Python version 2.3 or newer (for running some of the tests and
|
||||
re-generating certain source files from templates)
|
||||
|
||||
Getting the Source
|
||||
------------------
|
||||
|
||||
There are two primary ways of getting Google Mock's source code: you
|
||||
can download a stable source release in your preferred archive format,
|
||||
or directly check out the source from our Subversion (SVN) repositary.
|
||||
The SVN checkout requires a few extra steps and some extra software
|
||||
packages on your system, but lets you track development and make
|
||||
patches much more easily, so we highly encourage it.
|
||||
|
||||
### Source Package ###
|
||||
|
||||
Google Mock is released in versioned source packages which can be
|
||||
downloaded from the download page [1]. Several different archive
|
||||
formats are provided, but the only difference is the tools needed to
|
||||
extract their contents, and the size of the resulting file. Download
|
||||
whichever you are most comfortable with.
|
||||
|
||||
[1] http://code.google.com/p/googlemock/downloads/list
|
||||
|
||||
Once downloaded expand the archive using whichever tools you prefer
|
||||
for that type. This will always result in a new directory with the
|
||||
name "gmock-X.Y.Z" which contains all of the source code. Here are
|
||||
some examples on Linux:
|
||||
|
||||
tar -xvzf gmock-X.Y.Z.tar.gz
|
||||
tar -xvjf gmock-X.Y.Z.tar.bz2
|
||||
unzip gmock-X.Y.Z.zip
|
||||
|
||||
### SVN Checkout ###
|
||||
|
||||
To check out the main branch (also known as the "trunk") of Google
|
||||
Mock, run the following Subversion command:
|
||||
|
||||
svn checkout http://googlemock.googlecode.com/svn/trunk/ gmock-svn
|
||||
|
||||
If you are using a *nix system and plan to use the GNU Autotools build
|
||||
system to build Google Mock (described below), you'll need to
|
||||
configure it now. Otherwise you are done with getting the source
|
||||
files.
|
||||
|
||||
To prepare the Autotools build system, enter the target directory of
|
||||
the checkout command you used ('gmock-svn') and proceed with the
|
||||
following command:
|
||||
|
||||
autoreconf -fvi
|
||||
|
||||
Once you have completed this step, you are ready to build the library.
|
||||
Note that you should only need to complete this step once. The
|
||||
subsequent 'make' invocations will automatically re-generate the bits
|
||||
of the build system that need to be changed.
|
||||
|
||||
If your system uses older versions of the autotools, the above command
|
||||
will fail. You may need to explicitly specify a version to use. For
|
||||
instance, if you have both GNU Automake 1.4 and 1.9 installed and
|
||||
'automake' would invoke the 1.4, use instead:
|
||||
|
||||
AUTOMAKE=automake-1.9 ACLOCAL=aclocal-1.9 autoreconf -fvi
|
||||
|
||||
Make sure you're using the same version of automake and aclocal.
|
||||
|
||||
Setting up the Build
|
||||
--------------------
|
||||
|
||||
To build Google Mock and your tests that use it, you need to tell your
|
||||
build system where to find its headers and source files. The exact
|
||||
way to do it depends on which build system you use, and is usually
|
||||
straightforward.
|
||||
|
||||
### Generic Build Instructions ###
|
||||
|
||||
This section shows how you can integrate Google Mock into your
|
||||
existing build system.
|
||||
|
||||
Suppose you put Google Mock in directory ${GMOCK_DIR} and Google Test
|
||||
in ${GTEST_DIR} (the latter is ${GMOCK_DIR}/gtest by default). To
|
||||
build Google Mock, create a library build target (or a project as
|
||||
called by Visual Studio and Xcode) to compile
|
||||
|
||||
${GTEST_DIR}/src/gtest-all.cc and ${GMOCK_DIR}/src/gmock-all.cc
|
||||
|
||||
with
|
||||
|
||||
${GTEST_DIR}/include and ${GMOCK_DIR}/include
|
||||
|
||||
in the system header search path, and
|
||||
|
||||
${GTEST_DIR} and ${GMOCK_DIR}
|
||||
|
||||
in the normal header search path. Assuming a Linux-like system and gcc,
|
||||
something like the following will do:
|
||||
|
||||
g++ -isystem ${GTEST_DIR}/include -I${GTEST_DIR} \
|
||||
-isystem ${GMOCK_DIR}/include -I${GMOCK_DIR} \
|
||||
-pthread -c ${GTEST_DIR}/src/gtest-all.cc
|
||||
g++ -isystem ${GTEST_DIR}/include -I${GTEST_DIR} \
|
||||
-isystem ${GMOCK_DIR}/include -I${GMOCK_DIR} \
|
||||
-pthread -c ${GMOCK_DIR}/src/gmock-all.cc
|
||||
ar -rv libgmock.a gtest-all.o gmock-all.o
|
||||
|
||||
(We need -pthread as Google Test and Google Mock use threads.)
|
||||
|
||||
Next, you should compile your test source file with
|
||||
${GTEST_DIR}/include and ${GMOCK_DIR}/include in the header search
|
||||
path, and link it with gmock and any other necessary libraries:
|
||||
|
||||
g++ -isystem ${GTEST_DIR}/include -isystem ${GMOCK_DIR}/include \
|
||||
-pthread path/to/your_test.cc libgmock.a -o your_test
|
||||
|
||||
As an example, the make/ directory contains a Makefile that you can
|
||||
use to build Google Mock on systems where GNU make is available
|
||||
(e.g. Linux, Mac OS X, and Cygwin). It doesn't try to build Google
|
||||
Mock's own tests. Instead, it just builds the Google Mock library and
|
||||
a sample test. You can use it as a starting point for your own build
|
||||
script.
|
||||
|
||||
If the default settings are correct for your environment, the
|
||||
following commands should succeed:
|
||||
|
||||
cd ${GMOCK_DIR}/make
|
||||
make
|
||||
./gmock_test
|
||||
|
||||
If you see errors, try to tweak the contents of make/Makefile to make
|
||||
them go away. There are instructions in make/Makefile on how to do
|
||||
it.
|
||||
|
||||
### Windows ###
|
||||
|
||||
The msvc/2005 directory contains VC++ 2005 projects and the msvc/2010
|
||||
directory contains VC++ 2010 projects for building Google Mock and
|
||||
selected tests.
|
||||
|
||||
Change to the appropriate directory and run "msbuild gmock.sln" to
|
||||
build the library and tests (or open the gmock.sln in the MSVC IDE).
|
||||
If you want to create your own project to use with Google Mock, you'll
|
||||
have to configure it to use the gmock_config propety sheet. For that:
|
||||
|
||||
* Open the Property Manager window (View | Other Windows | Property Manager)
|
||||
* Right-click on your project and select "Add Existing Property Sheet..."
|
||||
* Navigate to gmock_config.vsprops or gmock_config.props and select it.
|
||||
* In Project Properties | Configuration Properties | General | Additional
|
||||
Include Directories, type <path to Google Mock>/include.
|
||||
|
||||
Tweaking Google Mock
|
||||
--------------------
|
||||
|
||||
Google Mock can be used in diverse environments. The default
|
||||
configuration may not work (or may not work well) out of the box in
|
||||
some environments. However, you can easily tweak Google Mock by
|
||||
defining control macros on the compiler command line. Generally,
|
||||
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 ${GTEST_DIR}/include/gtest/internal/gtest-port.h.
|
||||
|
||||
### Choosing a TR1 Tuple Library ###
|
||||
|
||||
Google Mock uses the C++ Technical Report 1 (TR1) tuple library
|
||||
heavily. Unfortunately TR1 tuple is not yet widely available with all
|
||||
compilers. The good news is that Google Test 1.4.0+ implements a
|
||||
subset of TR1 tuple that's enough for Google Mock's need. Google Mock
|
||||
will automatically use that implementation when the compiler doesn't
|
||||
provide TR1 tuple.
|
||||
|
||||
Usually you don't need to care about which tuple library Google Test
|
||||
and Google Mock use. However, if your project already uses TR1 tuple,
|
||||
you need to tell Google Test and Google Mock to use the same TR1 tuple
|
||||
library the rest of your project uses, or the two tuple
|
||||
implementations will clash. To do that, add
|
||||
|
||||
-DGTEST_USE_OWN_TR1_TUPLE=0
|
||||
|
||||
to the compiler flags while compiling Google Test, Google Mock, and
|
||||
your tests. If you want to force Google Test and Google Mock to use
|
||||
their own tuple library, just add
|
||||
|
||||
-DGTEST_USE_OWN_TR1_TUPLE=1
|
||||
|
||||
to the compiler flags instead.
|
||||
|
||||
If you want to use Boost's TR1 tuple library with Google Mock, please
|
||||
refer to the Boost website (http://www.boost.org/) for how to obtain
|
||||
it and set it up.
|
||||
|
||||
### As a Shared Library (DLL) ###
|
||||
|
||||
Google Mock is compact, so most users can build and link it as a static
|
||||
library for the simplicity. Google Mock can be used as a DLL, but the
|
||||
same DLL must contain Google Test as well. See Google Test's README
|
||||
file for instructions on how to set up necessary compiler settings.
|
||||
|
||||
### Tweaking Google Mock ###
|
||||
|
||||
Most of Google Test's control macros apply to Google Mock as well.
|
||||
Please see file ${GTEST_DIR}/README for how to tweak them.
|
||||
|
||||
Upgrading from an Earlier Version
|
||||
---------------------------------
|
||||
|
||||
We strive to keep Google Mock releases backward compatible.
|
||||
Sometimes, though, we have to make some breaking changes for the
|
||||
users' long-term benefits. This section describes what you'll need to
|
||||
do if you are upgrading from an earlier version of Google Mock.
|
||||
|
||||
### Upgrading from 1.1.0 or Earlier ###
|
||||
|
||||
You may need to explicitly enable or disable Google Test's own TR1
|
||||
tuple library. See the instructions in section "Choosing a TR1 Tuple
|
||||
Library".
|
||||
|
||||
### Upgrading from 1.4.0 or Earlier ###
|
||||
|
||||
On platforms where the pthread library is available, Google Test and
|
||||
Google Mock use it in order to be thread-safe. For this to work, you
|
||||
may need to tweak your compiler and/or linker flags. Please see the
|
||||
"Multi-threaded Tests" section in file ${GTEST_DIR}/README for what
|
||||
you may need to do.
|
||||
|
||||
If you have custom matchers defined using MatcherInterface or
|
||||
MakePolymorphicMatcher(), you'll need to update their definitions to
|
||||
use the new matcher API [2]. Matchers defined using MATCHER() or
|
||||
MATCHER_P*() aren't affected.
|
||||
|
||||
[2] http://code.google.com/p/googlemock/wiki/CookBook#Writing_New_Monomorphic_Matchers,
|
||||
http://code.google.com/p/googlemock/wiki/CookBook#Writing_New_Polymorphic_Matchers
|
||||
|
||||
Developing Google Mock
|
||||
----------------------
|
||||
|
||||
This section discusses how to make your own changes to Google Mock.
|
||||
|
||||
### Testing Google Mock Itself ###
|
||||
|
||||
To make sure your changes work as intended and don't break existing
|
||||
functionality, you'll want to compile and run Google Test's own tests.
|
||||
For that you'll need Autotools. First, make sure you have followed
|
||||
the instructions in section "SVN Checkout" to configure Google Mock.
|
||||
Then, create a build output directory and enter it. Next,
|
||||
|
||||
${GMOCK_DIR}/configure # Standard GNU configure script, --help for more info
|
||||
|
||||
Once you have successfully configured Google Mock, the build steps are
|
||||
standard for GNU-style OSS packages.
|
||||
|
||||
make # Standard makefile following GNU conventions
|
||||
make check # Builds and runs all tests - all should pass.
|
||||
|
||||
Note that when building your project against Google Mock, you are building
|
||||
against Google Test as well. There is no need to configure Google Test
|
||||
separately.
|
||||
|
||||
### Regenerating Source Files ###
|
||||
|
||||
Some of Google Mock's source files are generated from templates (not
|
||||
in the C++ sense) using a script. A template file is named FOO.pump,
|
||||
where FOO is the name of the file it will generate. For example, the
|
||||
file include/gmock/gmock-generated-actions.h.pump is used to generate
|
||||
gmock-generated-actions.h in the same directory.
|
||||
|
||||
Normally you don't need to worry about regenerating the source files,
|
||||
unless you need to modify them. In that case, you should modify the
|
||||
corresponding .pump files instead and run the 'pump' script (for Pump
|
||||
is Useful for Meta Programming) to regenerate them. You can find
|
||||
pump.py in the ${GTEST_DIR}/scripts/ directory. Read the Pump manual
|
||||
[3] for how to use it.
|
||||
|
||||
[3] http://code.google.com/p/googletest/wiki/PumpManual.
|
||||
|
||||
### Contributing a Patch ###
|
||||
|
||||
We welcome patches. Please read the Google Mock developer's guide [4]
|
||||
for how you can contribute. In particular, make sure you have signed
|
||||
the Contributor License Agreement, or we won't be able to accept the
|
||||
patch.
|
||||
|
||||
[4] http://code.google.com/p/googlemock/wiki/DevGuide
|
||||
|
||||
Happy testing!
|
||||
9799
test/gmock-1.7.0/aclocal.m4
vendored
9799
test/gmock-1.7.0/aclocal.m4
vendored
File diff suppressed because it is too large
Load Diff
1530
test/gmock-1.7.0/build-aux/config.guess
vendored
1530
test/gmock-1.7.0/build-aux/config.guess
vendored
File diff suppressed because it is too large
Load Diff
@@ -1,69 +0,0 @@
|
||||
/* build-aux/config.h.in. Generated from configure.ac by autoheader. */
|
||||
|
||||
/* Define to 1 if you have the <dlfcn.h> header file. */
|
||||
#undef HAVE_DLFCN_H
|
||||
|
||||
/* Define to 1 if you have the <inttypes.h> header file. */
|
||||
#undef HAVE_INTTYPES_H
|
||||
|
||||
/* Define to 1 if you have the <memory.h> header file. */
|
||||
#undef HAVE_MEMORY_H
|
||||
|
||||
/* Define if you have POSIX threads libraries and header files. */
|
||||
#undef HAVE_PTHREAD
|
||||
|
||||
/* Define to 1 if you have the <stdint.h> header file. */
|
||||
#undef HAVE_STDINT_H
|
||||
|
||||
/* Define to 1 if you have the <stdlib.h> header file. */
|
||||
#undef HAVE_STDLIB_H
|
||||
|
||||
/* Define to 1 if you have the <strings.h> header file. */
|
||||
#undef HAVE_STRINGS_H
|
||||
|
||||
/* Define to 1 if you have the <string.h> header file. */
|
||||
#undef HAVE_STRING_H
|
||||
|
||||
/* Define to 1 if you have the <sys/stat.h> header file. */
|
||||
#undef HAVE_SYS_STAT_H
|
||||
|
||||
/* Define to 1 if you have the <sys/types.h> header file. */
|
||||
#undef HAVE_SYS_TYPES_H
|
||||
|
||||
/* Define to 1 if you have the <unistd.h> header file. */
|
||||
#undef HAVE_UNISTD_H
|
||||
|
||||
/* Define to the sub-directory in which libtool stores uninstalled libraries.
|
||||
*/
|
||||
#undef LT_OBJDIR
|
||||
|
||||
/* Name of package */
|
||||
#undef PACKAGE
|
||||
|
||||
/* Define to the address where bug reports for this package should be sent. */
|
||||
#undef PACKAGE_BUGREPORT
|
||||
|
||||
/* Define to the full name of this package. */
|
||||
#undef PACKAGE_NAME
|
||||
|
||||
/* Define to the full name and version of this package. */
|
||||
#undef PACKAGE_STRING
|
||||
|
||||
/* Define to the one symbol short name of this package. */
|
||||
#undef PACKAGE_TARNAME
|
||||
|
||||
/* Define to the home page for this package. */
|
||||
#undef PACKAGE_URL
|
||||
|
||||
/* Define to the version of this package. */
|
||||
#undef PACKAGE_VERSION
|
||||
|
||||
/* Define to necessary symbol if this constant uses a non-standard name on
|
||||
your system. */
|
||||
#undef PTHREAD_CREATE_JOINABLE
|
||||
|
||||
/* Define to 1 if you have the ANSI C header files. */
|
||||
#undef STDC_HEADERS
|
||||
|
||||
/* Version number of package */
|
||||
#undef VERSION
|
||||
1773
test/gmock-1.7.0/build-aux/config.sub
vendored
1773
test/gmock-1.7.0/build-aux/config.sub
vendored
File diff suppressed because it is too large
Load Diff
@@ -1,688 +0,0 @@
|
||||
#! /bin/sh
|
||||
# depcomp - compile a program generating dependencies as side-effects
|
||||
|
||||
scriptversion=2011-12-04.11; # UTC
|
||||
|
||||
# Copyright (C) 1999, 2000, 2003, 2004, 2005, 2006, 2007, 2009, 2010,
|
||||
# 2011 Free Software Foundation, Inc.
|
||||
|
||||
# This program is free software; you can redistribute it and/or modify
|
||||
# it under the terms of the GNU General Public License as published by
|
||||
# the Free Software Foundation; either version 2, or (at your option)
|
||||
# any later version.
|
||||
|
||||
# This program is distributed in the hope that it will be useful,
|
||||
# but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
||||
# GNU General Public License for more details.
|
||||
|
||||
# You should have received a copy of the GNU General Public License
|
||||
# along with this program. If not, see <http://www.gnu.org/licenses/>.
|
||||
|
||||
# As a special exception to the GNU General Public License, if you
|
||||
# distribute this file as part of a program that contains a
|
||||
# configuration script generated by Autoconf, you may include it under
|
||||
# the same distribution terms that you use for the rest of that program.
|
||||
|
||||
# Originally written by Alexandre Oliva <oliva@dcc.unicamp.br>.
|
||||
|
||||
case $1 in
|
||||
'')
|
||||
echo "$0: No command. Try \`$0 --help' for more information." 1>&2
|
||||
exit 1;
|
||||
;;
|
||||
-h | --h*)
|
||||
cat <<\EOF
|
||||
Usage: depcomp [--help] [--version] PROGRAM [ARGS]
|
||||
|
||||
Run PROGRAMS ARGS to compile a file, generating dependencies
|
||||
as side-effects.
|
||||
|
||||
Environment variables:
|
||||
depmode Dependency tracking mode.
|
||||
source Source file read by `PROGRAMS ARGS'.
|
||||
object Object file output by `PROGRAMS ARGS'.
|
||||
DEPDIR directory where to store dependencies.
|
||||
depfile Dependency file to output.
|
||||
tmpdepfile Temporary file to use when outputting dependencies.
|
||||
libtool Whether libtool is used (yes/no).
|
||||
|
||||
Report bugs to <bug-automake@gnu.org>.
|
||||
EOF
|
||||
exit $?
|
||||
;;
|
||||
-v | --v*)
|
||||
echo "depcomp $scriptversion"
|
||||
exit $?
|
||||
;;
|
||||
esac
|
||||
|
||||
if test -z "$depmode" || test -z "$source" || test -z "$object"; then
|
||||
echo "depcomp: Variables source, object and depmode must be set" 1>&2
|
||||
exit 1
|
||||
fi
|
||||
|
||||
# Dependencies for sub/bar.o or sub/bar.obj go into sub/.deps/bar.Po.
|
||||
depfile=${depfile-`echo "$object" |
|
||||
sed 's|[^\\/]*$|'${DEPDIR-.deps}'/&|;s|\.\([^.]*\)$|.P\1|;s|Pobj$|Po|'`}
|
||||
tmpdepfile=${tmpdepfile-`echo "$depfile" | sed 's/\.\([^.]*\)$/.T\1/'`}
|
||||
|
||||
rm -f "$tmpdepfile"
|
||||
|
||||
# Some modes work just like other modes, but use different flags. We
|
||||
# parameterize here, but still list the modes in the big case below,
|
||||
# to make depend.m4 easier to write. Note that we *cannot* use a case
|
||||
# here, because this file can only contain one case statement.
|
||||
if test "$depmode" = hp; then
|
||||
# HP compiler uses -M and no extra arg.
|
||||
gccflag=-M
|
||||
depmode=gcc
|
||||
fi
|
||||
|
||||
if test "$depmode" = dashXmstdout; then
|
||||
# This is just like dashmstdout with a different argument.
|
||||
dashmflag=-xM
|
||||
depmode=dashmstdout
|
||||
fi
|
||||
|
||||
cygpath_u="cygpath -u -f -"
|
||||
if test "$depmode" = msvcmsys; then
|
||||
# This is just like msvisualcpp but w/o cygpath translation.
|
||||
# Just convert the backslash-escaped backslashes to single forward
|
||||
# slashes to satisfy depend.m4
|
||||
cygpath_u='sed s,\\\\,/,g'
|
||||
depmode=msvisualcpp
|
||||
fi
|
||||
|
||||
if test "$depmode" = msvc7msys; then
|
||||
# This is just like msvc7 but w/o cygpath translation.
|
||||
# Just convert the backslash-escaped backslashes to single forward
|
||||
# slashes to satisfy depend.m4
|
||||
cygpath_u='sed s,\\\\,/,g'
|
||||
depmode=msvc7
|
||||
fi
|
||||
|
||||
case "$depmode" in
|
||||
gcc3)
|
||||
## gcc 3 implements dependency tracking that does exactly what
|
||||
## we want. Yay! Note: for some reason libtool 1.4 doesn't like
|
||||
## it if -MD -MP comes after the -MF stuff. Hmm.
|
||||
## Unfortunately, FreeBSD c89 acceptance of flags depends upon
|
||||
## the command line argument order; so add the flags where they
|
||||
## appear in depend2.am. Note that the slowdown incurred here
|
||||
## affects only configure: in makefiles, %FASTDEP% shortcuts this.
|
||||
for arg
|
||||
do
|
||||
case $arg in
|
||||
-c) set fnord "$@" -MT "$object" -MD -MP -MF "$tmpdepfile" "$arg" ;;
|
||||
*) set fnord "$@" "$arg" ;;
|
||||
esac
|
||||
shift # fnord
|
||||
shift # $arg
|
||||
done
|
||||
"$@"
|
||||
stat=$?
|
||||
if test $stat -eq 0; then :
|
||||
else
|
||||
rm -f "$tmpdepfile"
|
||||
exit $stat
|
||||
fi
|
||||
mv "$tmpdepfile" "$depfile"
|
||||
;;
|
||||
|
||||
gcc)
|
||||
## There are various ways to get dependency output from gcc. Here's
|
||||
## why we pick this rather obscure method:
|
||||
## - Don't want to use -MD because we'd like the dependencies to end
|
||||
## up in a subdir. Having to rename by hand is ugly.
|
||||
## (We might end up doing this anyway to support other compilers.)
|
||||
## - The DEPENDENCIES_OUTPUT environment variable makes gcc act like
|
||||
## -MM, not -M (despite what the docs say).
|
||||
## - Using -M directly means running the compiler twice (even worse
|
||||
## than renaming).
|
||||
if test -z "$gccflag"; then
|
||||
gccflag=-MD,
|
||||
fi
|
||||
"$@" -Wp,"$gccflag$tmpdepfile"
|
||||
stat=$?
|
||||
if test $stat -eq 0; then :
|
||||
else
|
||||
rm -f "$tmpdepfile"
|
||||
exit $stat
|
||||
fi
|
||||
rm -f "$depfile"
|
||||
echo "$object : \\" > "$depfile"
|
||||
alpha=ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz
|
||||
## The second -e expression handles DOS-style file names with drive letters.
|
||||
sed -e 's/^[^:]*: / /' \
|
||||
-e 's/^['$alpha']:\/[^:]*: / /' < "$tmpdepfile" >> "$depfile"
|
||||
## This next piece of magic avoids the `deleted header file' problem.
|
||||
## The problem is that when a header file which appears in a .P file
|
||||
## is deleted, the dependency causes make to die (because there is
|
||||
## typically no way to rebuild the header). We avoid this by adding
|
||||
## dummy dependencies for each header file. Too bad gcc doesn't do
|
||||
## this for us directly.
|
||||
tr ' ' '
|
||||
' < "$tmpdepfile" |
|
||||
## Some versions of gcc put a space before the `:'. On the theory
|
||||
## that the space means something, we add a space to the output as
|
||||
## well. hp depmode also adds that space, but also prefixes the VPATH
|
||||
## to the object. Take care to not repeat it in the output.
|
||||
## Some versions of the HPUX 10.20 sed can't process this invocation
|
||||
## correctly. Breaking it into two sed invocations is a workaround.
|
||||
sed -e 's/^\\$//' -e '/^$/d' -e "s|.*$object$||" -e '/:$/d' \
|
||||
| sed -e 's/$/ :/' >> "$depfile"
|
||||
rm -f "$tmpdepfile"
|
||||
;;
|
||||
|
||||
hp)
|
||||
# This case exists only to let depend.m4 do its work. It works by
|
||||
# looking at the text of this script. This case will never be run,
|
||||
# since it is checked for above.
|
||||
exit 1
|
||||
;;
|
||||
|
||||
sgi)
|
||||
if test "$libtool" = yes; then
|
||||
"$@" "-Wp,-MDupdate,$tmpdepfile"
|
||||
else
|
||||
"$@" -MDupdate "$tmpdepfile"
|
||||
fi
|
||||
stat=$?
|
||||
if test $stat -eq 0; then :
|
||||
else
|
||||
rm -f "$tmpdepfile"
|
||||
exit $stat
|
||||
fi
|
||||
rm -f "$depfile"
|
||||
|
||||
if test -f "$tmpdepfile"; then # yes, the sourcefile depend on other files
|
||||
echo "$object : \\" > "$depfile"
|
||||
|
||||
# Clip off the initial element (the dependent). Don't try to be
|
||||
# clever and replace this with sed code, as IRIX sed won't handle
|
||||
# lines with more than a fixed number of characters (4096 in
|
||||
# IRIX 6.2 sed, 8192 in IRIX 6.5). We also remove comment lines;
|
||||
# the IRIX cc adds comments like `#:fec' to the end of the
|
||||
# dependency line.
|
||||
tr ' ' '
|
||||
' < "$tmpdepfile" \
|
||||
| sed -e 's/^.*\.o://' -e 's/#.*$//' -e '/^$/ d' | \
|
||||
tr '
|
||||
' ' ' >> "$depfile"
|
||||
echo >> "$depfile"
|
||||
|
||||
# The second pass generates a dummy entry for each header file.
|
||||
tr ' ' '
|
||||
' < "$tmpdepfile" \
|
||||
| sed -e 's/^.*\.o://' -e 's/#.*$//' -e '/^$/ d' -e 's/$/:/' \
|
||||
>> "$depfile"
|
||||
else
|
||||
# The sourcefile does not contain any dependencies, so just
|
||||
# store a dummy comment line, to avoid errors with the Makefile
|
||||
# "include basename.Plo" scheme.
|
||||
echo "#dummy" > "$depfile"
|
||||
fi
|
||||
rm -f "$tmpdepfile"
|
||||
;;
|
||||
|
||||
aix)
|
||||
# The C for AIX Compiler uses -M and outputs the dependencies
|
||||
# in a .u file. In older versions, this file always lives in the
|
||||
# current directory. Also, the AIX compiler puts `$object:' at the
|
||||
# start of each line; $object doesn't have directory information.
|
||||
# Version 6 uses the directory in both cases.
|
||||
dir=`echo "$object" | sed -e 's|/[^/]*$|/|'`
|
||||
test "x$dir" = "x$object" && dir=
|
||||
base=`echo "$object" | sed -e 's|^.*/||' -e 's/\.o$//' -e 's/\.lo$//'`
|
||||
if test "$libtool" = yes; then
|
||||
tmpdepfile1=$dir$base.u
|
||||
tmpdepfile2=$base.u
|
||||
tmpdepfile3=$dir.libs/$base.u
|
||||
"$@" -Wc,-M
|
||||
else
|
||||
tmpdepfile1=$dir$base.u
|
||||
tmpdepfile2=$dir$base.u
|
||||
tmpdepfile3=$dir$base.u
|
||||
"$@" -M
|
||||
fi
|
||||
stat=$?
|
||||
|
||||
if test $stat -eq 0; then :
|
||||
else
|
||||
rm -f "$tmpdepfile1" "$tmpdepfile2" "$tmpdepfile3"
|
||||
exit $stat
|
||||
fi
|
||||
|
||||
for tmpdepfile in "$tmpdepfile1" "$tmpdepfile2" "$tmpdepfile3"
|
||||
do
|
||||
test -f "$tmpdepfile" && break
|
||||
done
|
||||
if test -f "$tmpdepfile"; then
|
||||
# Each line is of the form `foo.o: dependent.h'.
|
||||
# Do two passes, one to just change these to
|
||||
# `$object: dependent.h' and one to simply `dependent.h:'.
|
||||
sed -e "s,^.*\.[a-z]*:,$object:," < "$tmpdepfile" > "$depfile"
|
||||
# That's a tab and a space in the [].
|
||||
sed -e 's,^.*\.[a-z]*:[ ]*,,' -e 's,$,:,' < "$tmpdepfile" >> "$depfile"
|
||||
else
|
||||
# The sourcefile does not contain any dependencies, so just
|
||||
# store a dummy comment line, to avoid errors with the Makefile
|
||||
# "include basename.Plo" scheme.
|
||||
echo "#dummy" > "$depfile"
|
||||
fi
|
||||
rm -f "$tmpdepfile"
|
||||
;;
|
||||
|
||||
icc)
|
||||
# Intel's C compiler understands `-MD -MF file'. However on
|
||||
# icc -MD -MF foo.d -c -o sub/foo.o sub/foo.c
|
||||
# ICC 7.0 will fill foo.d with something like
|
||||
# foo.o: sub/foo.c
|
||||
# foo.o: sub/foo.h
|
||||
# which is wrong. We want:
|
||||
# sub/foo.o: sub/foo.c
|
||||
# sub/foo.o: sub/foo.h
|
||||
# sub/foo.c:
|
||||
# sub/foo.h:
|
||||
# ICC 7.1 will output
|
||||
# foo.o: sub/foo.c sub/foo.h
|
||||
# and will wrap long lines using \ :
|
||||
# foo.o: sub/foo.c ... \
|
||||
# sub/foo.h ... \
|
||||
# ...
|
||||
|
||||
"$@" -MD -MF "$tmpdepfile"
|
||||
stat=$?
|
||||
if test $stat -eq 0; then :
|
||||
else
|
||||
rm -f "$tmpdepfile"
|
||||
exit $stat
|
||||
fi
|
||||
rm -f "$depfile"
|
||||
# Each line is of the form `foo.o: dependent.h',
|
||||
# or `foo.o: dep1.h dep2.h \', or ` dep3.h dep4.h \'.
|
||||
# Do two passes, one to just change these to
|
||||
# `$object: dependent.h' and one to simply `dependent.h:'.
|
||||
sed "s,^[^:]*:,$object :," < "$tmpdepfile" > "$depfile"
|
||||
# Some versions of the HPUX 10.20 sed can't process this invocation
|
||||
# correctly. Breaking it into two sed invocations is a workaround.
|
||||
sed 's,^[^:]*: \(.*\)$,\1,;s/^\\$//;/^$/d;/:$/d' < "$tmpdepfile" |
|
||||
sed -e 's/$/ :/' >> "$depfile"
|
||||
rm -f "$tmpdepfile"
|
||||
;;
|
||||
|
||||
hp2)
|
||||
# The "hp" stanza above does not work with aCC (C++) and HP's ia64
|
||||
# compilers, which have integrated preprocessors. The correct option
|
||||
# to use with these is +Maked; it writes dependencies to a file named
|
||||
# 'foo.d', which lands next to the object file, wherever that
|
||||
# happens to be.
|
||||
# Much of this is similar to the tru64 case; see comments there.
|
||||
dir=`echo "$object" | sed -e 's|/[^/]*$|/|'`
|
||||
test "x$dir" = "x$object" && dir=
|
||||
base=`echo "$object" | sed -e 's|^.*/||' -e 's/\.o$//' -e 's/\.lo$//'`
|
||||
if test "$libtool" = yes; then
|
||||
tmpdepfile1=$dir$base.d
|
||||
tmpdepfile2=$dir.libs/$base.d
|
||||
"$@" -Wc,+Maked
|
||||
else
|
||||
tmpdepfile1=$dir$base.d
|
||||
tmpdepfile2=$dir$base.d
|
||||
"$@" +Maked
|
||||
fi
|
||||
stat=$?
|
||||
if test $stat -eq 0; then :
|
||||
else
|
||||
rm -f "$tmpdepfile1" "$tmpdepfile2"
|
||||
exit $stat
|
||||
fi
|
||||
|
||||
for tmpdepfile in "$tmpdepfile1" "$tmpdepfile2"
|
||||
do
|
||||
test -f "$tmpdepfile" && break
|
||||
done
|
||||
if test -f "$tmpdepfile"; then
|
||||
sed -e "s,^.*\.[a-z]*:,$object:," "$tmpdepfile" > "$depfile"
|
||||
# Add `dependent.h:' lines.
|
||||
sed -ne '2,${
|
||||
s/^ *//
|
||||
s/ \\*$//
|
||||
s/$/:/
|
||||
p
|
||||
}' "$tmpdepfile" >> "$depfile"
|
||||
else
|
||||
echo "#dummy" > "$depfile"
|
||||
fi
|
||||
rm -f "$tmpdepfile" "$tmpdepfile2"
|
||||
;;
|
||||
|
||||
tru64)
|
||||
# The Tru64 compiler uses -MD to generate dependencies as a side
|
||||
# effect. `cc -MD -o foo.o ...' puts the dependencies into `foo.o.d'.
|
||||
# At least on Alpha/Redhat 6.1, Compaq CCC V6.2-504 seems to put
|
||||
# dependencies in `foo.d' instead, so we check for that too.
|
||||
# Subdirectories are respected.
|
||||
dir=`echo "$object" | sed -e 's|/[^/]*$|/|'`
|
||||
test "x$dir" = "x$object" && dir=
|
||||
base=`echo "$object" | sed -e 's|^.*/||' -e 's/\.o$//' -e 's/\.lo$//'`
|
||||
|
||||
if test "$libtool" = yes; then
|
||||
# With Tru64 cc, shared objects can also be used to make a
|
||||
# static library. This mechanism is used in libtool 1.4 series to
|
||||
# handle both shared and static libraries in a single compilation.
|
||||
# With libtool 1.4, dependencies were output in $dir.libs/$base.lo.d.
|
||||
#
|
||||
# With libtool 1.5 this exception was removed, and libtool now
|
||||
# generates 2 separate objects for the 2 libraries. These two
|
||||
# compilations output dependencies in $dir.libs/$base.o.d and
|
||||
# in $dir$base.o.d. We have to check for both files, because
|
||||
# one of the two compilations can be disabled. We should prefer
|
||||
# $dir$base.o.d over $dir.libs/$base.o.d because the latter is
|
||||
# automatically cleaned when .libs/ is deleted, while ignoring
|
||||
# the former would cause a distcleancheck panic.
|
||||
tmpdepfile1=$dir.libs/$base.lo.d # libtool 1.4
|
||||
tmpdepfile2=$dir$base.o.d # libtool 1.5
|
||||
tmpdepfile3=$dir.libs/$base.o.d # libtool 1.5
|
||||
tmpdepfile4=$dir.libs/$base.d # Compaq CCC V6.2-504
|
||||
"$@" -Wc,-MD
|
||||
else
|
||||
tmpdepfile1=$dir$base.o.d
|
||||
tmpdepfile2=$dir$base.d
|
||||
tmpdepfile3=$dir$base.d
|
||||
tmpdepfile4=$dir$base.d
|
||||
"$@" -MD
|
||||
fi
|
||||
|
||||
stat=$?
|
||||
if test $stat -eq 0; then :
|
||||
else
|
||||
rm -f "$tmpdepfile1" "$tmpdepfile2" "$tmpdepfile3" "$tmpdepfile4"
|
||||
exit $stat
|
||||
fi
|
||||
|
||||
for tmpdepfile in "$tmpdepfile1" "$tmpdepfile2" "$tmpdepfile3" "$tmpdepfile4"
|
||||
do
|
||||
test -f "$tmpdepfile" && break
|
||||
done
|
||||
if test -f "$tmpdepfile"; then
|
||||
sed -e "s,^.*\.[a-z]*:,$object:," < "$tmpdepfile" > "$depfile"
|
||||
# That's a tab and a space in the [].
|
||||
sed -e 's,^.*\.[a-z]*:[ ]*,,' -e 's,$,:,' < "$tmpdepfile" >> "$depfile"
|
||||
else
|
||||
echo "#dummy" > "$depfile"
|
||||
fi
|
||||
rm -f "$tmpdepfile"
|
||||
;;
|
||||
|
||||
msvc7)
|
||||
if test "$libtool" = yes; then
|
||||
showIncludes=-Wc,-showIncludes
|
||||
else
|
||||
showIncludes=-showIncludes
|
||||
fi
|
||||
"$@" $showIncludes > "$tmpdepfile"
|
||||
stat=$?
|
||||
grep -v '^Note: including file: ' "$tmpdepfile"
|
||||
if test "$stat" = 0; then :
|
||||
else
|
||||
rm -f "$tmpdepfile"
|
||||
exit $stat
|
||||
fi
|
||||
rm -f "$depfile"
|
||||
echo "$object : \\" > "$depfile"
|
||||
# The first sed program below extracts the file names and escapes
|
||||
# backslashes for cygpath. The second sed program outputs the file
|
||||
# name when reading, but also accumulates all include files in the
|
||||
# hold buffer in order to output them again at the end. This only
|
||||
# works with sed implementations that can handle large buffers.
|
||||
sed < "$tmpdepfile" -n '
|
||||
/^Note: including file: *\(.*\)/ {
|
||||
s//\1/
|
||||
s/\\/\\\\/g
|
||||
p
|
||||
}' | $cygpath_u | sort -u | sed -n '
|
||||
s/ /\\ /g
|
||||
s/\(.*\)/ \1 \\/p
|
||||
s/.\(.*\) \\/\1:/
|
||||
H
|
||||
$ {
|
||||
s/.*/ /
|
||||
G
|
||||
p
|
||||
}' >> "$depfile"
|
||||
rm -f "$tmpdepfile"
|
||||
;;
|
||||
|
||||
msvc7msys)
|
||||
# This case exists only to let depend.m4 do its work. It works by
|
||||
# looking at the text of this script. This case will never be run,
|
||||
# since it is checked for above.
|
||||
exit 1
|
||||
;;
|
||||
|
||||
#nosideeffect)
|
||||
# This comment above is used by automake to tell side-effect
|
||||
# dependency tracking mechanisms from slower ones.
|
||||
|
||||
dashmstdout)
|
||||
# Important note: in order to support this mode, a compiler *must*
|
||||
# always write the preprocessed file to stdout, regardless of -o.
|
||||
"$@" || exit $?
|
||||
|
||||
# Remove the call to Libtool.
|
||||
if test "$libtool" = yes; then
|
||||
while test "X$1" != 'X--mode=compile'; do
|
||||
shift
|
||||
done
|
||||
shift
|
||||
fi
|
||||
|
||||
# Remove `-o $object'.
|
||||
IFS=" "
|
||||
for arg
|
||||
do
|
||||
case $arg in
|
||||
-o)
|
||||
shift
|
||||
;;
|
||||
$object)
|
||||
shift
|
||||
;;
|
||||
*)
|
||||
set fnord "$@" "$arg"
|
||||
shift # fnord
|
||||
shift # $arg
|
||||
;;
|
||||
esac
|
||||
done
|
||||
|
||||
test -z "$dashmflag" && dashmflag=-M
|
||||
# Require at least two characters before searching for `:'
|
||||
# in the target name. This is to cope with DOS-style filenames:
|
||||
# a dependency such as `c:/foo/bar' could be seen as target `c' otherwise.
|
||||
"$@" $dashmflag |
|
||||
sed 's:^[ ]*[^: ][^:][^:]*\:[ ]*:'"$object"'\: :' > "$tmpdepfile"
|
||||
rm -f "$depfile"
|
||||
cat < "$tmpdepfile" > "$depfile"
|
||||
tr ' ' '
|
||||
' < "$tmpdepfile" | \
|
||||
## Some versions of the HPUX 10.20 sed can't process this invocation
|
||||
## correctly. Breaking it into two sed invocations is a workaround.
|
||||
sed -e 's/^\\$//' -e '/^$/d' -e '/:$/d' | sed -e 's/$/ :/' >> "$depfile"
|
||||
rm -f "$tmpdepfile"
|
||||
;;
|
||||
|
||||
dashXmstdout)
|
||||
# This case only exists to satisfy depend.m4. It is never actually
|
||||
# run, as this mode is specially recognized in the preamble.
|
||||
exit 1
|
||||
;;
|
||||
|
||||
makedepend)
|
||||
"$@" || exit $?
|
||||
# Remove any Libtool call
|
||||
if test "$libtool" = yes; then
|
||||
while test "X$1" != 'X--mode=compile'; do
|
||||
shift
|
||||
done
|
||||
shift
|
||||
fi
|
||||
# X makedepend
|
||||
shift
|
||||
cleared=no eat=no
|
||||
for arg
|
||||
do
|
||||
case $cleared in
|
||||
no)
|
||||
set ""; shift
|
||||
cleared=yes ;;
|
||||
esac
|
||||
if test $eat = yes; then
|
||||
eat=no
|
||||
continue
|
||||
fi
|
||||
case "$arg" in
|
||||
-D*|-I*)
|
||||
set fnord "$@" "$arg"; shift ;;
|
||||
# Strip any option that makedepend may not understand. Remove
|
||||
# the object too, otherwise makedepend will parse it as a source file.
|
||||
-arch)
|
||||
eat=yes ;;
|
||||
-*|$object)
|
||||
;;
|
||||
*)
|
||||
set fnord "$@" "$arg"; shift ;;
|
||||
esac
|
||||
done
|
||||
obj_suffix=`echo "$object" | sed 's/^.*\././'`
|
||||
touch "$tmpdepfile"
|
||||
${MAKEDEPEND-makedepend} -o"$obj_suffix" -f"$tmpdepfile" "$@"
|
||||
rm -f "$depfile"
|
||||
# makedepend may prepend the VPATH from the source file name to the object.
|
||||
# No need to regex-escape $object, excess matching of '.' is harmless.
|
||||
sed "s|^.*\($object *:\)|\1|" "$tmpdepfile" > "$depfile"
|
||||
sed '1,2d' "$tmpdepfile" | tr ' ' '
|
||||
' | \
|
||||
## Some versions of the HPUX 10.20 sed can't process this invocation
|
||||
## correctly. Breaking it into two sed invocations is a workaround.
|
||||
sed -e 's/^\\$//' -e '/^$/d' -e '/:$/d' | sed -e 's/$/ :/' >> "$depfile"
|
||||
rm -f "$tmpdepfile" "$tmpdepfile".bak
|
||||
;;
|
||||
|
||||
cpp)
|
||||
# Important note: in order to support this mode, a compiler *must*
|
||||
# always write the preprocessed file to stdout.
|
||||
"$@" || exit $?
|
||||
|
||||
# Remove the call to Libtool.
|
||||
if test "$libtool" = yes; then
|
||||
while test "X$1" != 'X--mode=compile'; do
|
||||
shift
|
||||
done
|
||||
shift
|
||||
fi
|
||||
|
||||
# Remove `-o $object'.
|
||||
IFS=" "
|
||||
for arg
|
||||
do
|
||||
case $arg in
|
||||
-o)
|
||||
shift
|
||||
;;
|
||||
$object)
|
||||
shift
|
||||
;;
|
||||
*)
|
||||
set fnord "$@" "$arg"
|
||||
shift # fnord
|
||||
shift # $arg
|
||||
;;
|
||||
esac
|
||||
done
|
||||
|
||||
"$@" -E |
|
||||
sed -n -e '/^# [0-9][0-9]* "\([^"]*\)".*/ s:: \1 \\:p' \
|
||||
-e '/^#line [0-9][0-9]* "\([^"]*\)".*/ s:: \1 \\:p' |
|
||||
sed '$ s: \\$::' > "$tmpdepfile"
|
||||
rm -f "$depfile"
|
||||
echo "$object : \\" > "$depfile"
|
||||
cat < "$tmpdepfile" >> "$depfile"
|
||||
sed < "$tmpdepfile" '/^$/d;s/^ //;s/ \\$//;s/$/ :/' >> "$depfile"
|
||||
rm -f "$tmpdepfile"
|
||||
;;
|
||||
|
||||
msvisualcpp)
|
||||
# Important note: in order to support this mode, a compiler *must*
|
||||
# always write the preprocessed file to stdout.
|
||||
"$@" || exit $?
|
||||
|
||||
# Remove the call to Libtool.
|
||||
if test "$libtool" = yes; then
|
||||
while test "X$1" != 'X--mode=compile'; do
|
||||
shift
|
||||
done
|
||||
shift
|
||||
fi
|
||||
|
||||
IFS=" "
|
||||
for arg
|
||||
do
|
||||
case "$arg" in
|
||||
-o)
|
||||
shift
|
||||
;;
|
||||
$object)
|
||||
shift
|
||||
;;
|
||||
"-Gm"|"/Gm"|"-Gi"|"/Gi"|"-ZI"|"/ZI")
|
||||
set fnord "$@"
|
||||
shift
|
||||
shift
|
||||
;;
|
||||
*)
|
||||
set fnord "$@" "$arg"
|
||||
shift
|
||||
shift
|
||||
;;
|
||||
esac
|
||||
done
|
||||
"$@" -E 2>/dev/null |
|
||||
sed -n '/^#line [0-9][0-9]* "\([^"]*\)"/ s::\1:p' | $cygpath_u | sort -u > "$tmpdepfile"
|
||||
rm -f "$depfile"
|
||||
echo "$object : \\" > "$depfile"
|
||||
sed < "$tmpdepfile" -n -e 's% %\\ %g' -e '/^\(.*\)$/ s:: \1 \\:p' >> "$depfile"
|
||||
echo " " >> "$depfile"
|
||||
sed < "$tmpdepfile" -n -e 's% %\\ %g' -e '/^\(.*\)$/ s::\1\::p' >> "$depfile"
|
||||
rm -f "$tmpdepfile"
|
||||
;;
|
||||
|
||||
msvcmsys)
|
||||
# This case exists only to let depend.m4 do its work. It works by
|
||||
# looking at the text of this script. This case will never be run,
|
||||
# since it is checked for above.
|
||||
exit 1
|
||||
;;
|
||||
|
||||
none)
|
||||
exec "$@"
|
||||
;;
|
||||
|
||||
*)
|
||||
echo "Unknown depmode $depmode" 1>&2
|
||||
exit 1
|
||||
;;
|
||||
esac
|
||||
|
||||
exit 0
|
||||
|
||||
# Local Variables:
|
||||
# mode: shell-script
|
||||
# sh-indentation: 2
|
||||
# eval: (add-hook 'write-file-hooks 'time-stamp)
|
||||
# time-stamp-start: "scriptversion="
|
||||
# time-stamp-format: "%:y-%02m-%02d.%02H"
|
||||
# time-stamp-time-zone: "UTC"
|
||||
# time-stamp-end: "; # UTC"
|
||||
# End:
|
||||
@@ -1,527 +0,0 @@
|
||||
#!/bin/sh
|
||||
# install - install a program, script, or datafile
|
||||
|
||||
scriptversion=2011-01-19.21; # UTC
|
||||
|
||||
# This originates from X11R5 (mit/util/scripts/install.sh), which was
|
||||
# later released in X11R6 (xc/config/util/install.sh) with the
|
||||
# following copyright and license.
|
||||
#
|
||||
# Copyright (C) 1994 X Consortium
|
||||
#
|
||||
# Permission is hereby granted, free of charge, to any person obtaining a copy
|
||||
# of this software and associated documentation files (the "Software"), to
|
||||
# deal in the Software without restriction, including without limitation the
|
||||
# rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
|
||||
# sell copies of the Software, and to permit persons to whom the Software is
|
||||
# furnished to do so, subject to the following conditions:
|
||||
#
|
||||
# The above copyright notice and this permission notice shall be included in
|
||||
# all copies or substantial portions of the Software.
|
||||
#
|
||||
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
||||
# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
||||
# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
||||
# X CONSORTIUM BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN
|
||||
# AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNEC-
|
||||
# TION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
|
||||
#
|
||||
# Except as contained in this notice, the name of the X Consortium shall not
|
||||
# be used in advertising or otherwise to promote the sale, use or other deal-
|
||||
# ings in this Software without prior written authorization from the X Consor-
|
||||
# tium.
|
||||
#
|
||||
#
|
||||
# FSF changes to this file are in the public domain.
|
||||
#
|
||||
# Calling this script install-sh is preferred over install.sh, to prevent
|
||||
# `make' implicit rules from creating a file called install from it
|
||||
# when there is no Makefile.
|
||||
#
|
||||
# This script is compatible with the BSD install script, but was written
|
||||
# from scratch.
|
||||
|
||||
nl='
|
||||
'
|
||||
IFS=" "" $nl"
|
||||
|
||||
# set DOITPROG to echo to test this script
|
||||
|
||||
# Don't use :- since 4.3BSD and earlier shells don't like it.
|
||||
doit=${DOITPROG-}
|
||||
if test -z "$doit"; then
|
||||
doit_exec=exec
|
||||
else
|
||||
doit_exec=$doit
|
||||
fi
|
||||
|
||||
# Put in absolute file names if you don't have them in your path;
|
||||
# or use environment vars.
|
||||
|
||||
chgrpprog=${CHGRPPROG-chgrp}
|
||||
chmodprog=${CHMODPROG-chmod}
|
||||
chownprog=${CHOWNPROG-chown}
|
||||
cmpprog=${CMPPROG-cmp}
|
||||
cpprog=${CPPROG-cp}
|
||||
mkdirprog=${MKDIRPROG-mkdir}
|
||||
mvprog=${MVPROG-mv}
|
||||
rmprog=${RMPROG-rm}
|
||||
stripprog=${STRIPPROG-strip}
|
||||
|
||||
posix_glob='?'
|
||||
initialize_posix_glob='
|
||||
test "$posix_glob" != "?" || {
|
||||
if (set -f) 2>/dev/null; then
|
||||
posix_glob=
|
||||
else
|
||||
posix_glob=:
|
||||
fi
|
||||
}
|
||||
'
|
||||
|
||||
posix_mkdir=
|
||||
|
||||
# Desired mode of installed file.
|
||||
mode=0755
|
||||
|
||||
chgrpcmd=
|
||||
chmodcmd=$chmodprog
|
||||
chowncmd=
|
||||
mvcmd=$mvprog
|
||||
rmcmd="$rmprog -f"
|
||||
stripcmd=
|
||||
|
||||
src=
|
||||
dst=
|
||||
dir_arg=
|
||||
dst_arg=
|
||||
|
||||
copy_on_change=false
|
||||
no_target_directory=
|
||||
|
||||
usage="\
|
||||
Usage: $0 [OPTION]... [-T] SRCFILE DSTFILE
|
||||
or: $0 [OPTION]... SRCFILES... DIRECTORY
|
||||
or: $0 [OPTION]... -t DIRECTORY SRCFILES...
|
||||
or: $0 [OPTION]... -d DIRECTORIES...
|
||||
|
||||
In the 1st form, copy SRCFILE to DSTFILE.
|
||||
In the 2nd and 3rd, copy all SRCFILES to DIRECTORY.
|
||||
In the 4th, create DIRECTORIES.
|
||||
|
||||
Options:
|
||||
--help display this help and exit.
|
||||
--version display version info and exit.
|
||||
|
||||
-c (ignored)
|
||||
-C install only if different (preserve the last data modification time)
|
||||
-d create directories instead of installing files.
|
||||
-g GROUP $chgrpprog installed files to GROUP.
|
||||
-m MODE $chmodprog installed files to MODE.
|
||||
-o USER $chownprog installed files to USER.
|
||||
-s $stripprog installed files.
|
||||
-t DIRECTORY install into DIRECTORY.
|
||||
-T report an error if DSTFILE is a directory.
|
||||
|
||||
Environment variables override the default commands:
|
||||
CHGRPPROG CHMODPROG CHOWNPROG CMPPROG CPPROG MKDIRPROG MVPROG
|
||||
RMPROG STRIPPROG
|
||||
"
|
||||
|
||||
while test $# -ne 0; do
|
||||
case $1 in
|
||||
-c) ;;
|
||||
|
||||
-C) copy_on_change=true;;
|
||||
|
||||
-d) dir_arg=true;;
|
||||
|
||||
-g) chgrpcmd="$chgrpprog $2"
|
||||
shift;;
|
||||
|
||||
--help) echo "$usage"; exit $?;;
|
||||
|
||||
-m) mode=$2
|
||||
case $mode in
|
||||
*' '* | *' '* | *'
|
||||
'* | *'*'* | *'?'* | *'['*)
|
||||
echo "$0: invalid mode: $mode" >&2
|
||||
exit 1;;
|
||||
esac
|
||||
shift;;
|
||||
|
||||
-o) chowncmd="$chownprog $2"
|
||||
shift;;
|
||||
|
||||
-s) stripcmd=$stripprog;;
|
||||
|
||||
-t) dst_arg=$2
|
||||
# Protect names problematic for `test' and other utilities.
|
||||
case $dst_arg in
|
||||
-* | [=\(\)!]) dst_arg=./$dst_arg;;
|
||||
esac
|
||||
shift;;
|
||||
|
||||
-T) no_target_directory=true;;
|
||||
|
||||
--version) echo "$0 $scriptversion"; exit $?;;
|
||||
|
||||
--) shift
|
||||
break;;
|
||||
|
||||
-*) echo "$0: invalid option: $1" >&2
|
||||
exit 1;;
|
||||
|
||||
*) break;;
|
||||
esac
|
||||
shift
|
||||
done
|
||||
|
||||
if test $# -ne 0 && test -z "$dir_arg$dst_arg"; then
|
||||
# When -d is used, all remaining arguments are directories to create.
|
||||
# When -t is used, the destination is already specified.
|
||||
# Otherwise, the last argument is the destination. Remove it from $@.
|
||||
for arg
|
||||
do
|
||||
if test -n "$dst_arg"; then
|
||||
# $@ is not empty: it contains at least $arg.
|
||||
set fnord "$@" "$dst_arg"
|
||||
shift # fnord
|
||||
fi
|
||||
shift # arg
|
||||
dst_arg=$arg
|
||||
# Protect names problematic for `test' and other utilities.
|
||||
case $dst_arg in
|
||||
-* | [=\(\)!]) dst_arg=./$dst_arg;;
|
||||
esac
|
||||
done
|
||||
fi
|
||||
|
||||
if test $# -eq 0; then
|
||||
if test -z "$dir_arg"; then
|
||||
echo "$0: no input file specified." >&2
|
||||
exit 1
|
||||
fi
|
||||
# It's OK to call `install-sh -d' without argument.
|
||||
# This can happen when creating conditional directories.
|
||||
exit 0
|
||||
fi
|
||||
|
||||
if test -z "$dir_arg"; then
|
||||
do_exit='(exit $ret); exit $ret'
|
||||
trap "ret=129; $do_exit" 1
|
||||
trap "ret=130; $do_exit" 2
|
||||
trap "ret=141; $do_exit" 13
|
||||
trap "ret=143; $do_exit" 15
|
||||
|
||||
# Set umask so as not to create temps with too-generous modes.
|
||||
# However, 'strip' requires both read and write access to temps.
|
||||
case $mode in
|
||||
# Optimize common cases.
|
||||
*644) cp_umask=133;;
|
||||
*755) cp_umask=22;;
|
||||
|
||||
*[0-7])
|
||||
if test -z "$stripcmd"; then
|
||||
u_plus_rw=
|
||||
else
|
||||
u_plus_rw='% 200'
|
||||
fi
|
||||
cp_umask=`expr '(' 777 - $mode % 1000 ')' $u_plus_rw`;;
|
||||
*)
|
||||
if test -z "$stripcmd"; then
|
||||
u_plus_rw=
|
||||
else
|
||||
u_plus_rw=,u+rw
|
||||
fi
|
||||
cp_umask=$mode$u_plus_rw;;
|
||||
esac
|
||||
fi
|
||||
|
||||
for src
|
||||
do
|
||||
# Protect names problematic for `test' and other utilities.
|
||||
case $src in
|
||||
-* | [=\(\)!]) src=./$src;;
|
||||
esac
|
||||
|
||||
if test -n "$dir_arg"; then
|
||||
dst=$src
|
||||
dstdir=$dst
|
||||
test -d "$dstdir"
|
||||
dstdir_status=$?
|
||||
else
|
||||
|
||||
# Waiting for this to be detected by the "$cpprog $src $dsttmp" command
|
||||
# might cause directories to be created, which would be especially bad
|
||||
# if $src (and thus $dsttmp) contains '*'.
|
||||
if test ! -f "$src" && test ! -d "$src"; then
|
||||
echo "$0: $src does not exist." >&2
|
||||
exit 1
|
||||
fi
|
||||
|
||||
if test -z "$dst_arg"; then
|
||||
echo "$0: no destination specified." >&2
|
||||
exit 1
|
||||
fi
|
||||
dst=$dst_arg
|
||||
|
||||
# If destination is a directory, append the input filename; won't work
|
||||
# if double slashes aren't ignored.
|
||||
if test -d "$dst"; then
|
||||
if test -n "$no_target_directory"; then
|
||||
echo "$0: $dst_arg: Is a directory" >&2
|
||||
exit 1
|
||||
fi
|
||||
dstdir=$dst
|
||||
dst=$dstdir/`basename "$src"`
|
||||
dstdir_status=0
|
||||
else
|
||||
# Prefer dirname, but fall back on a substitute if dirname fails.
|
||||
dstdir=`
|
||||
(dirname "$dst") 2>/dev/null ||
|
||||
expr X"$dst" : 'X\(.*[^/]\)//*[^/][^/]*/*$' \| \
|
||||
X"$dst" : 'X\(//\)[^/]' \| \
|
||||
X"$dst" : 'X\(//\)$' \| \
|
||||
X"$dst" : 'X\(/\)' \| . 2>/dev/null ||
|
||||
echo X"$dst" |
|
||||
sed '/^X\(.*[^/]\)\/\/*[^/][^/]*\/*$/{
|
||||
s//\1/
|
||||
q
|
||||
}
|
||||
/^X\(\/\/\)[^/].*/{
|
||||
s//\1/
|
||||
q
|
||||
}
|
||||
/^X\(\/\/\)$/{
|
||||
s//\1/
|
||||
q
|
||||
}
|
||||
/^X\(\/\).*/{
|
||||
s//\1/
|
||||
q
|
||||
}
|
||||
s/.*/./; q'
|
||||
`
|
||||
|
||||
test -d "$dstdir"
|
||||
dstdir_status=$?
|
||||
fi
|
||||
fi
|
||||
|
||||
obsolete_mkdir_used=false
|
||||
|
||||
if test $dstdir_status != 0; then
|
||||
case $posix_mkdir in
|
||||
'')
|
||||
# Create intermediate dirs using mode 755 as modified by the umask.
|
||||
# This is like FreeBSD 'install' as of 1997-10-28.
|
||||
umask=`umask`
|
||||
case $stripcmd.$umask in
|
||||
# Optimize common cases.
|
||||
*[2367][2367]) mkdir_umask=$umask;;
|
||||
.*0[02][02] | .[02][02] | .[02]) mkdir_umask=22;;
|
||||
|
||||
*[0-7])
|
||||
mkdir_umask=`expr $umask + 22 \
|
||||
- $umask % 100 % 40 + $umask % 20 \
|
||||
- $umask % 10 % 4 + $umask % 2
|
||||
`;;
|
||||
*) mkdir_umask=$umask,go-w;;
|
||||
esac
|
||||
|
||||
# With -d, create the new directory with the user-specified mode.
|
||||
# Otherwise, rely on $mkdir_umask.
|
||||
if test -n "$dir_arg"; then
|
||||
mkdir_mode=-m$mode
|
||||
else
|
||||
mkdir_mode=
|
||||
fi
|
||||
|
||||
posix_mkdir=false
|
||||
case $umask in
|
||||
*[123567][0-7][0-7])
|
||||
# POSIX mkdir -p sets u+wx bits regardless of umask, which
|
||||
# is incompatible with FreeBSD 'install' when (umask & 300) != 0.
|
||||
;;
|
||||
*)
|
||||
tmpdir=${TMPDIR-/tmp}/ins$RANDOM-$$
|
||||
trap 'ret=$?; rmdir "$tmpdir/d" "$tmpdir" 2>/dev/null; exit $ret' 0
|
||||
|
||||
if (umask $mkdir_umask &&
|
||||
exec $mkdirprog $mkdir_mode -p -- "$tmpdir/d") >/dev/null 2>&1
|
||||
then
|
||||
if test -z "$dir_arg" || {
|
||||
# Check for POSIX incompatibilities with -m.
|
||||
# HP-UX 11.23 and IRIX 6.5 mkdir -m -p sets group- or
|
||||
# other-writeable bit of parent directory when it shouldn't.
|
||||
# FreeBSD 6.1 mkdir -m -p sets mode of existing directory.
|
||||
ls_ld_tmpdir=`ls -ld "$tmpdir"`
|
||||
case $ls_ld_tmpdir in
|
||||
d????-?r-*) different_mode=700;;
|
||||
d????-?--*) different_mode=755;;
|
||||
*) false;;
|
||||
esac &&
|
||||
$mkdirprog -m$different_mode -p -- "$tmpdir" && {
|
||||
ls_ld_tmpdir_1=`ls -ld "$tmpdir"`
|
||||
test "$ls_ld_tmpdir" = "$ls_ld_tmpdir_1"
|
||||
}
|
||||
}
|
||||
then posix_mkdir=:
|
||||
fi
|
||||
rmdir "$tmpdir/d" "$tmpdir"
|
||||
else
|
||||
# Remove any dirs left behind by ancient mkdir implementations.
|
||||
rmdir ./$mkdir_mode ./-p ./-- 2>/dev/null
|
||||
fi
|
||||
trap '' 0;;
|
||||
esac;;
|
||||
esac
|
||||
|
||||
if
|
||||
$posix_mkdir && (
|
||||
umask $mkdir_umask &&
|
||||
$doit_exec $mkdirprog $mkdir_mode -p -- "$dstdir"
|
||||
)
|
||||
then :
|
||||
else
|
||||
|
||||
# The umask is ridiculous, or mkdir does not conform to POSIX,
|
||||
# or it failed possibly due to a race condition. Create the
|
||||
# directory the slow way, step by step, checking for races as we go.
|
||||
|
||||
case $dstdir in
|
||||
/*) prefix='/';;
|
||||
[-=\(\)!]*) prefix='./';;
|
||||
*) prefix='';;
|
||||
esac
|
||||
|
||||
eval "$initialize_posix_glob"
|
||||
|
||||
oIFS=$IFS
|
||||
IFS=/
|
||||
$posix_glob set -f
|
||||
set fnord $dstdir
|
||||
shift
|
||||
$posix_glob set +f
|
||||
IFS=$oIFS
|
||||
|
||||
prefixes=
|
||||
|
||||
for d
|
||||
do
|
||||
test X"$d" = X && continue
|
||||
|
||||
prefix=$prefix$d
|
||||
if test -d "$prefix"; then
|
||||
prefixes=
|
||||
else
|
||||
if $posix_mkdir; then
|
||||
(umask=$mkdir_umask &&
|
||||
$doit_exec $mkdirprog $mkdir_mode -p -- "$dstdir") && break
|
||||
# Don't fail if two instances are running concurrently.
|
||||
test -d "$prefix" || exit 1
|
||||
else
|
||||
case $prefix in
|
||||
*\'*) qprefix=`echo "$prefix" | sed "s/'/'\\\\\\\\''/g"`;;
|
||||
*) qprefix=$prefix;;
|
||||
esac
|
||||
prefixes="$prefixes '$qprefix'"
|
||||
fi
|
||||
fi
|
||||
prefix=$prefix/
|
||||
done
|
||||
|
||||
if test -n "$prefixes"; then
|
||||
# Don't fail if two instances are running concurrently.
|
||||
(umask $mkdir_umask &&
|
||||
eval "\$doit_exec \$mkdirprog $prefixes") ||
|
||||
test -d "$dstdir" || exit 1
|
||||
obsolete_mkdir_used=true
|
||||
fi
|
||||
fi
|
||||
fi
|
||||
|
||||
if test -n "$dir_arg"; then
|
||||
{ test -z "$chowncmd" || $doit $chowncmd "$dst"; } &&
|
||||
{ test -z "$chgrpcmd" || $doit $chgrpcmd "$dst"; } &&
|
||||
{ test "$obsolete_mkdir_used$chowncmd$chgrpcmd" = false ||
|
||||
test -z "$chmodcmd" || $doit $chmodcmd $mode "$dst"; } || exit 1
|
||||
else
|
||||
|
||||
# Make a couple of temp file names in the proper directory.
|
||||
dsttmp=$dstdir/_inst.$$_
|
||||
rmtmp=$dstdir/_rm.$$_
|
||||
|
||||
# Trap to clean up those temp files at exit.
|
||||
trap 'ret=$?; rm -f "$dsttmp" "$rmtmp" && exit $ret' 0
|
||||
|
||||
# Copy the file name to the temp name.
|
||||
(umask $cp_umask && $doit_exec $cpprog "$src" "$dsttmp") &&
|
||||
|
||||
# and set any options; do chmod last to preserve setuid bits.
|
||||
#
|
||||
# If any of these fail, we abort the whole thing. If we want to
|
||||
# ignore errors from any of these, just make sure not to ignore
|
||||
# errors from the above "$doit $cpprog $src $dsttmp" command.
|
||||
#
|
||||
{ test -z "$chowncmd" || $doit $chowncmd "$dsttmp"; } &&
|
||||
{ test -z "$chgrpcmd" || $doit $chgrpcmd "$dsttmp"; } &&
|
||||
{ test -z "$stripcmd" || $doit $stripcmd "$dsttmp"; } &&
|
||||
{ test -z "$chmodcmd" || $doit $chmodcmd $mode "$dsttmp"; } &&
|
||||
|
||||
# If -C, don't bother to copy if it wouldn't change the file.
|
||||
if $copy_on_change &&
|
||||
old=`LC_ALL=C ls -dlL "$dst" 2>/dev/null` &&
|
||||
new=`LC_ALL=C ls -dlL "$dsttmp" 2>/dev/null` &&
|
||||
|
||||
eval "$initialize_posix_glob" &&
|
||||
$posix_glob set -f &&
|
||||
set X $old && old=:$2:$4:$5:$6 &&
|
||||
set X $new && new=:$2:$4:$5:$6 &&
|
||||
$posix_glob set +f &&
|
||||
|
||||
test "$old" = "$new" &&
|
||||
$cmpprog "$dst" "$dsttmp" >/dev/null 2>&1
|
||||
then
|
||||
rm -f "$dsttmp"
|
||||
else
|
||||
# Rename the file to the real destination.
|
||||
$doit $mvcmd -f "$dsttmp" "$dst" 2>/dev/null ||
|
||||
|
||||
# The rename failed, perhaps because mv can't rename something else
|
||||
# to itself, or perhaps because mv is so ancient that it does not
|
||||
# support -f.
|
||||
{
|
||||
# Now remove or move aside any old file at destination location.
|
||||
# We try this two ways since rm can't unlink itself on some
|
||||
# systems and the destination file might be busy for other
|
||||
# reasons. In this case, the final cleanup might fail but the new
|
||||
# file should still install successfully.
|
||||
{
|
||||
test ! -f "$dst" ||
|
||||
$doit $rmcmd -f "$dst" 2>/dev/null ||
|
||||
{ $doit $mvcmd -f "$dst" "$rmtmp" 2>/dev/null &&
|
||||
{ $doit $rmcmd -f "$rmtmp" 2>/dev/null; :; }
|
||||
} ||
|
||||
{ echo "$0: cannot unlink or rename $dst" >&2
|
||||
(exit 1); exit 1
|
||||
}
|
||||
} &&
|
||||
|
||||
# Now rename the file to the real destination.
|
||||
$doit $mvcmd "$dsttmp" "$dst"
|
||||
}
|
||||
fi || exit 1
|
||||
|
||||
trap '' 0
|
||||
fi
|
||||
done
|
||||
|
||||
# Local variables:
|
||||
# eval: (add-hook 'write-file-hooks 'time-stamp)
|
||||
# time-stamp-start: "scriptversion="
|
||||
# time-stamp-format: "%:y-%02m-%02d.%02H"
|
||||
# time-stamp-time-zone: "UTC"
|
||||
# time-stamp-end: "; # UTC"
|
||||
# End:
|
||||
File diff suppressed because it is too large
Load Diff
@@ -1,331 +0,0 @@
|
||||
#! /bin/sh
|
||||
# Common stub for a few missing GNU programs while installing.
|
||||
|
||||
scriptversion=2012-01-06.13; # UTC
|
||||
|
||||
# Copyright (C) 1996, 1997, 1999, 2000, 2002, 2003, 2004, 2005, 2006,
|
||||
# 2008, 2009, 2010, 2011, 2012 Free Software Foundation, Inc.
|
||||
# Originally by Fran,cois Pinard <pinard@iro.umontreal.ca>, 1996.
|
||||
|
||||
# This program is free software; you can redistribute it and/or modify
|
||||
# it under the terms of the GNU General Public License as published by
|
||||
# the Free Software Foundation; either version 2, or (at your option)
|
||||
# any later version.
|
||||
|
||||
# This program is distributed in the hope that it will be useful,
|
||||
# but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
||||
# GNU General Public License for more details.
|
||||
|
||||
# You should have received a copy of the GNU General Public License
|
||||
# along with this program. If not, see <http://www.gnu.org/licenses/>.
|
||||
|
||||
# As a special exception to the GNU General Public License, if you
|
||||
# distribute this file as part of a program that contains a
|
||||
# configuration script generated by Autoconf, you may include it under
|
||||
# the same distribution terms that you use for the rest of that program.
|
||||
|
||||
if test $# -eq 0; then
|
||||
echo 1>&2 "Try \`$0 --help' for more information"
|
||||
exit 1
|
||||
fi
|
||||
|
||||
run=:
|
||||
sed_output='s/.* --output[ =]\([^ ]*\).*/\1/p'
|
||||
sed_minuso='s/.* -o \([^ ]*\).*/\1/p'
|
||||
|
||||
# In the cases where this matters, `missing' is being run in the
|
||||
# srcdir already.
|
||||
if test -f configure.ac; then
|
||||
configure_ac=configure.ac
|
||||
else
|
||||
configure_ac=configure.in
|
||||
fi
|
||||
|
||||
msg="missing on your system"
|
||||
|
||||
case $1 in
|
||||
--run)
|
||||
# Try to run requested program, and just exit if it succeeds.
|
||||
run=
|
||||
shift
|
||||
"$@" && exit 0
|
||||
# Exit code 63 means version mismatch. This often happens
|
||||
# when the user try to use an ancient version of a tool on
|
||||
# a file that requires a minimum version. In this case we
|
||||
# we should proceed has if the program had been absent, or
|
||||
# if --run hadn't been passed.
|
||||
if test $? = 63; then
|
||||
run=:
|
||||
msg="probably too old"
|
||||
fi
|
||||
;;
|
||||
|
||||
-h|--h|--he|--hel|--help)
|
||||
echo "\
|
||||
$0 [OPTION]... PROGRAM [ARGUMENT]...
|
||||
|
||||
Handle \`PROGRAM [ARGUMENT]...' for when PROGRAM is missing, or return an
|
||||
error status if there is no known handling for PROGRAM.
|
||||
|
||||
Options:
|
||||
-h, --help display this help and exit
|
||||
-v, --version output version information and exit
|
||||
--run try to run the given command, and emulate it if it fails
|
||||
|
||||
Supported PROGRAM values:
|
||||
aclocal touch file \`aclocal.m4'
|
||||
autoconf touch file \`configure'
|
||||
autoheader touch file \`config.h.in'
|
||||
autom4te touch the output file, or create a stub one
|
||||
automake touch all \`Makefile.in' files
|
||||
bison create \`y.tab.[ch]', if possible, from existing .[ch]
|
||||
flex create \`lex.yy.c', if possible, from existing .c
|
||||
help2man touch the output file
|
||||
lex create \`lex.yy.c', if possible, from existing .c
|
||||
makeinfo touch the output file
|
||||
yacc create \`y.tab.[ch]', if possible, from existing .[ch]
|
||||
|
||||
Version suffixes to PROGRAM as well as the prefixes \`gnu-', \`gnu', and
|
||||
\`g' are ignored when checking the name.
|
||||
|
||||
Send bug reports to <bug-automake@gnu.org>."
|
||||
exit $?
|
||||
;;
|
||||
|
||||
-v|--v|--ve|--ver|--vers|--versi|--versio|--version)
|
||||
echo "missing $scriptversion (GNU Automake)"
|
||||
exit $?
|
||||
;;
|
||||
|
||||
-*)
|
||||
echo 1>&2 "$0: Unknown \`$1' option"
|
||||
echo 1>&2 "Try \`$0 --help' for more information"
|
||||
exit 1
|
||||
;;
|
||||
|
||||
esac
|
||||
|
||||
# normalize program name to check for.
|
||||
program=`echo "$1" | sed '
|
||||
s/^gnu-//; t
|
||||
s/^gnu//; t
|
||||
s/^g//; t'`
|
||||
|
||||
# Now exit if we have it, but it failed. Also exit now if we
|
||||
# don't have it and --version was passed (most likely to detect
|
||||
# the program). This is about non-GNU programs, so use $1 not
|
||||
# $program.
|
||||
case $1 in
|
||||
lex*|yacc*)
|
||||
# Not GNU programs, they don't have --version.
|
||||
;;
|
||||
|
||||
*)
|
||||
if test -z "$run" && ($1 --version) > /dev/null 2>&1; then
|
||||
# We have it, but it failed.
|
||||
exit 1
|
||||
elif test "x$2" = "x--version" || test "x$2" = "x--help"; then
|
||||
# Could not run --version or --help. This is probably someone
|
||||
# running `$TOOL --version' or `$TOOL --help' to check whether
|
||||
# $TOOL exists and not knowing $TOOL uses missing.
|
||||
exit 1
|
||||
fi
|
||||
;;
|
||||
esac
|
||||
|
||||
# If it does not exist, or fails to run (possibly an outdated version),
|
||||
# try to emulate it.
|
||||
case $program in
|
||||
aclocal*)
|
||||
echo 1>&2 "\
|
||||
WARNING: \`$1' is $msg. You should only need it if
|
||||
you modified \`acinclude.m4' or \`${configure_ac}'. You might want
|
||||
to install the \`Automake' and \`Perl' packages. Grab them from
|
||||
any GNU archive site."
|
||||
touch aclocal.m4
|
||||
;;
|
||||
|
||||
autoconf*)
|
||||
echo 1>&2 "\
|
||||
WARNING: \`$1' is $msg. You should only need it if
|
||||
you modified \`${configure_ac}'. You might want to install the
|
||||
\`Autoconf' and \`GNU m4' packages. Grab them from any GNU
|
||||
archive site."
|
||||
touch configure
|
||||
;;
|
||||
|
||||
autoheader*)
|
||||
echo 1>&2 "\
|
||||
WARNING: \`$1' is $msg. You should only need it if
|
||||
you modified \`acconfig.h' or \`${configure_ac}'. You might want
|
||||
to install the \`Autoconf' and \`GNU m4' packages. Grab them
|
||||
from any GNU archive site."
|
||||
files=`sed -n 's/^[ ]*A[CM]_CONFIG_HEADER(\([^)]*\)).*/\1/p' ${configure_ac}`
|
||||
test -z "$files" && files="config.h"
|
||||
touch_files=
|
||||
for f in $files; do
|
||||
case $f in
|
||||
*:*) touch_files="$touch_files "`echo "$f" |
|
||||
sed -e 's/^[^:]*://' -e 's/:.*//'`;;
|
||||
*) touch_files="$touch_files $f.in";;
|
||||
esac
|
||||
done
|
||||
touch $touch_files
|
||||
;;
|
||||
|
||||
automake*)
|
||||
echo 1>&2 "\
|
||||
WARNING: \`$1' is $msg. You should only need it if
|
||||
you modified \`Makefile.am', \`acinclude.m4' or \`${configure_ac}'.
|
||||
You might want to install the \`Automake' and \`Perl' packages.
|
||||
Grab them from any GNU archive site."
|
||||
find . -type f -name Makefile.am -print |
|
||||
sed 's/\.am$/.in/' |
|
||||
while read f; do touch "$f"; done
|
||||
;;
|
||||
|
||||
autom4te*)
|
||||
echo 1>&2 "\
|
||||
WARNING: \`$1' is needed, but is $msg.
|
||||
You might have modified some files without having the
|
||||
proper tools for further handling them.
|
||||
You can get \`$1' as part of \`Autoconf' from any GNU
|
||||
archive site."
|
||||
|
||||
file=`echo "$*" | sed -n "$sed_output"`
|
||||
test -z "$file" && file=`echo "$*" | sed -n "$sed_minuso"`
|
||||
if test -f "$file"; then
|
||||
touch $file
|
||||
else
|
||||
test -z "$file" || exec >$file
|
||||
echo "#! /bin/sh"
|
||||
echo "# Created by GNU Automake missing as a replacement of"
|
||||
echo "# $ $@"
|
||||
echo "exit 0"
|
||||
chmod +x $file
|
||||
exit 1
|
||||
fi
|
||||
;;
|
||||
|
||||
bison*|yacc*)
|
||||
echo 1>&2 "\
|
||||
WARNING: \`$1' $msg. You should only need it if
|
||||
you modified a \`.y' file. You may need the \`Bison' package
|
||||
in order for those modifications to take effect. You can get
|
||||
\`Bison' from any GNU archive site."
|
||||
rm -f y.tab.c y.tab.h
|
||||
if test $# -ne 1; then
|
||||
eval LASTARG=\${$#}
|
||||
case $LASTARG in
|
||||
*.y)
|
||||
SRCFILE=`echo "$LASTARG" | sed 's/y$/c/'`
|
||||
if test -f "$SRCFILE"; then
|
||||
cp "$SRCFILE" y.tab.c
|
||||
fi
|
||||
SRCFILE=`echo "$LASTARG" | sed 's/y$/h/'`
|
||||
if test -f "$SRCFILE"; then
|
||||
cp "$SRCFILE" y.tab.h
|
||||
fi
|
||||
;;
|
||||
esac
|
||||
fi
|
||||
if test ! -f y.tab.h; then
|
||||
echo >y.tab.h
|
||||
fi
|
||||
if test ! -f y.tab.c; then
|
||||
echo 'main() { return 0; }' >y.tab.c
|
||||
fi
|
||||
;;
|
||||
|
||||
lex*|flex*)
|
||||
echo 1>&2 "\
|
||||
WARNING: \`$1' is $msg. You should only need it if
|
||||
you modified a \`.l' file. You may need the \`Flex' package
|
||||
in order for those modifications to take effect. You can get
|
||||
\`Flex' from any GNU archive site."
|
||||
rm -f lex.yy.c
|
||||
if test $# -ne 1; then
|
||||
eval LASTARG=\${$#}
|
||||
case $LASTARG in
|
||||
*.l)
|
||||
SRCFILE=`echo "$LASTARG" | sed 's/l$/c/'`
|
||||
if test -f "$SRCFILE"; then
|
||||
cp "$SRCFILE" lex.yy.c
|
||||
fi
|
||||
;;
|
||||
esac
|
||||
fi
|
||||
if test ! -f lex.yy.c; then
|
||||
echo 'main() { return 0; }' >lex.yy.c
|
||||
fi
|
||||
;;
|
||||
|
||||
help2man*)
|
||||
echo 1>&2 "\
|
||||
WARNING: \`$1' is $msg. You should only need it if
|
||||
you modified a dependency of a manual page. You may need the
|
||||
\`Help2man' package in order for those modifications to take
|
||||
effect. You can get \`Help2man' from any GNU archive site."
|
||||
|
||||
file=`echo "$*" | sed -n "$sed_output"`
|
||||
test -z "$file" && file=`echo "$*" | sed -n "$sed_minuso"`
|
||||
if test -f "$file"; then
|
||||
touch $file
|
||||
else
|
||||
test -z "$file" || exec >$file
|
||||
echo ".ab help2man is required to generate this page"
|
||||
exit $?
|
||||
fi
|
||||
;;
|
||||
|
||||
makeinfo*)
|
||||
echo 1>&2 "\
|
||||
WARNING: \`$1' is $msg. You should only need it if
|
||||
you modified a \`.texi' or \`.texinfo' file, or any other file
|
||||
indirectly affecting the aspect of the manual. The spurious
|
||||
call might also be the consequence of using a buggy \`make' (AIX,
|
||||
DU, IRIX). You might want to install the \`Texinfo' package or
|
||||
the \`GNU make' package. Grab either from any GNU archive site."
|
||||
# The file to touch is that specified with -o ...
|
||||
file=`echo "$*" | sed -n "$sed_output"`
|
||||
test -z "$file" && file=`echo "$*" | sed -n "$sed_minuso"`
|
||||
if test -z "$file"; then
|
||||
# ... or it is the one specified with @setfilename ...
|
||||
infile=`echo "$*" | sed 's/.* \([^ ]*\) *$/\1/'`
|
||||
file=`sed -n '
|
||||
/^@setfilename/{
|
||||
s/.* \([^ ]*\) *$/\1/
|
||||
p
|
||||
q
|
||||
}' $infile`
|
||||
# ... or it is derived from the source name (dir/f.texi becomes f.info)
|
||||
test -z "$file" && file=`echo "$infile" | sed 's,.*/,,;s,.[^.]*$,,'`.info
|
||||
fi
|
||||
# If the file does not exist, the user really needs makeinfo;
|
||||
# let's fail without touching anything.
|
||||
test -f $file || exit 1
|
||||
touch $file
|
||||
;;
|
||||
|
||||
*)
|
||||
echo 1>&2 "\
|
||||
WARNING: \`$1' is needed, and is $msg.
|
||||
You might have modified some files without having the
|
||||
proper tools for further handling them. Check the \`README' file,
|
||||
it often tells you about the needed prerequisites for installing
|
||||
this package. You may also peek at any GNU archive site, in case
|
||||
some other package would contain this missing \`$1' program."
|
||||
exit 1
|
||||
;;
|
||||
esac
|
||||
|
||||
exit 0
|
||||
|
||||
# Local variables:
|
||||
# eval: (add-hook 'write-file-hooks 'time-stamp)
|
||||
# time-stamp-start: "scriptversion="
|
||||
# time-stamp-format: "%:y-%02m-%02d.%02H"
|
||||
# time-stamp-time-zone: "UTC"
|
||||
# time-stamp-end: "; # UTC"
|
||||
# End:
|
||||
18535
test/gmock-1.7.0/configure
vendored
18535
test/gmock-1.7.0/configure
vendored
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
@@ -1,435 +0,0 @@
|
||||
Google C++ Testing Framework
|
||||
============================
|
||||
|
||||
http://code.google.com/p/googletest/
|
||||
|
||||
Overview
|
||||
--------
|
||||
|
||||
Google's framework for writing C++ tests on a variety of platforms
|
||||
(Linux, Mac OS X, Windows, Windows CE, Symbian, etc). Based on the
|
||||
xUnit architecture. Supports automatic test discovery, a rich set of
|
||||
assertions, user-defined assertions, death tests, fatal and non-fatal
|
||||
failures, various options for running the tests, and XML test report
|
||||
generation.
|
||||
|
||||
Please see the project page above for more information as well as the
|
||||
mailing list for questions, discussions, and development. There is
|
||||
also an IRC channel on OFTC (irc.oftc.net) #gtest available. Please
|
||||
join us!
|
||||
|
||||
Requirements for End Users
|
||||
--------------------------
|
||||
|
||||
Google Test is designed to have fairly minimal requirements to build
|
||||
and use with your projects, but there are some. Currently, we support
|
||||
Linux, Windows, Mac OS X, and Cygwin. We will also make our best
|
||||
effort to support other platforms (e.g. Solaris, AIX, and z/OS).
|
||||
However, since core members of the Google Test project have no access
|
||||
to these platforms, Google Test may have outstanding issues there. If
|
||||
you notice any problems on your platform, please notify
|
||||
googletestframework@googlegroups.com. Patches for fixing them are
|
||||
even more welcome!
|
||||
|
||||
### Linux Requirements ###
|
||||
|
||||
These are the base requirements to build and use Google Test from a source
|
||||
package (as described below):
|
||||
* GNU-compatible Make or gmake
|
||||
* POSIX-standard shell
|
||||
* POSIX(-2) Regular Expressions (regex.h)
|
||||
* A C++98-standard-compliant compiler
|
||||
|
||||
### Windows Requirements ###
|
||||
|
||||
* Microsoft Visual C++ 7.1 or newer
|
||||
|
||||
### Cygwin Requirements ###
|
||||
|
||||
* Cygwin 1.5.25-14 or newer
|
||||
|
||||
### Mac OS X Requirements ###
|
||||
|
||||
* Mac OS X 10.4 Tiger or newer
|
||||
* Developer Tools Installed
|
||||
|
||||
Also, you'll need CMake 2.6.4 or higher if you want to build the
|
||||
samples using the provided CMake script, regardless of the platform.
|
||||
|
||||
Requirements for Contributors
|
||||
-----------------------------
|
||||
|
||||
We welcome patches. If you plan to contribute a patch, you need to
|
||||
build Google Test and its own tests from an SVN checkout (described
|
||||
below), which has further requirements:
|
||||
|
||||
* Python version 2.3 or newer (for running some of the tests and
|
||||
re-generating certain source files from templates)
|
||||
* CMake 2.6.4 or newer
|
||||
|
||||
Getting the Source
|
||||
------------------
|
||||
|
||||
There are two primary ways of getting Google Test's source code: you
|
||||
can download a stable source release in your preferred archive format,
|
||||
or directly check out the source from our Subversion (SVN) repositary.
|
||||
The SVN checkout requires a few extra steps and some extra software
|
||||
packages on your system, but lets you track the latest development and
|
||||
make patches much more easily, so we highly encourage it.
|
||||
|
||||
### Source Package ###
|
||||
|
||||
Google Test is released in versioned source packages which can be
|
||||
downloaded from the download page [1]. Several different archive
|
||||
formats are provided, but the only difference is the tools used to
|
||||
manipulate them, and the size of the resulting file. Download
|
||||
whichever you are most comfortable with.
|
||||
|
||||
[1] http://code.google.com/p/googletest/downloads/list
|
||||
|
||||
Once the package is downloaded, expand it using whichever tools you
|
||||
prefer for that type. This will result in a new directory with the
|
||||
name "gtest-X.Y.Z" which contains all of the source code. Here are
|
||||
some examples on Linux:
|
||||
|
||||
tar -xvzf gtest-X.Y.Z.tar.gz
|
||||
tar -xvjf gtest-X.Y.Z.tar.bz2
|
||||
unzip gtest-X.Y.Z.zip
|
||||
|
||||
### SVN Checkout ###
|
||||
|
||||
To check out the main branch (also known as the "trunk") of Google
|
||||
Test, run the following Subversion command:
|
||||
|
||||
svn checkout http://googletest.googlecode.com/svn/trunk/ gtest-svn
|
||||
|
||||
Setting up the Build
|
||||
--------------------
|
||||
|
||||
To build Google Test and your tests that use it, you need to tell your
|
||||
build system where to find its headers and source files. The exact
|
||||
way to do it depends on which build system you use, and is usually
|
||||
straightforward.
|
||||
|
||||
### Generic Build Instructions ###
|
||||
|
||||
Suppose you put Google Test in directory ${GTEST_DIR}. To build it,
|
||||
create a library build target (or a project as called by Visual Studio
|
||||
and Xcode) to compile
|
||||
|
||||
${GTEST_DIR}/src/gtest-all.cc
|
||||
|
||||
with ${GTEST_DIR}/include in the system header search path and ${GTEST_DIR}
|
||||
in the normal header search path. Assuming a Linux-like system and gcc,
|
||||
something like the following will do:
|
||||
|
||||
g++ -isystem ${GTEST_DIR}/include -I${GTEST_DIR} \
|
||||
-pthread -c ${GTEST_DIR}/src/gtest-all.cc
|
||||
ar -rv libgtest.a gtest-all.o
|
||||
|
||||
(We need -pthread as Google Test uses threads.)
|
||||
|
||||
Next, you should compile your test source file with
|
||||
${GTEST_DIR}/include in the system header search path, and link it
|
||||
with gtest and any other necessary libraries:
|
||||
|
||||
g++ -isystem ${GTEST_DIR}/include -pthread path/to/your_test.cc libgtest.a \
|
||||
-o your_test
|
||||
|
||||
As an example, the make/ directory contains a Makefile that you can
|
||||
use to build Google Test on systems where GNU make is available
|
||||
(e.g. Linux, Mac OS X, and Cygwin). It doesn't try to build Google
|
||||
Test's own tests. Instead, it just builds the Google Test library and
|
||||
a sample test. You can use it as a starting point for your own build
|
||||
script.
|
||||
|
||||
If the default settings are correct for your environment, the
|
||||
following commands should succeed:
|
||||
|
||||
cd ${GTEST_DIR}/make
|
||||
make
|
||||
./sample1_unittest
|
||||
|
||||
If you see errors, try to tweak the contents of make/Makefile to make
|
||||
them go away. There are instructions in make/Makefile on how to do
|
||||
it.
|
||||
|
||||
### Using CMake ###
|
||||
|
||||
Google Test comes with a CMake build script (CMakeLists.txt) that can
|
||||
be used on a wide range of platforms ("C" stands for cross-platofrm.).
|
||||
If you don't have CMake installed already, you can download it for
|
||||
free from http://www.cmake.org/.
|
||||
|
||||
CMake works by generating native makefiles or build projects that can
|
||||
be used in the compiler environment of your choice. The typical
|
||||
workflow starts with:
|
||||
|
||||
mkdir mybuild # Create a directory to hold the build output.
|
||||
cd mybuild
|
||||
cmake ${GTEST_DIR} # Generate native build scripts.
|
||||
|
||||
If you want to build Google Test's samples, you should replace the
|
||||
last command with
|
||||
|
||||
cmake -Dgtest_build_samples=ON ${GTEST_DIR}
|
||||
|
||||
If you are on a *nix system, you should now see a Makefile in the
|
||||
current directory. Just type 'make' to build gtest.
|
||||
|
||||
If you use Windows and have Vistual Studio installed, a gtest.sln file
|
||||
and several .vcproj files will be created. You can then build them
|
||||
using Visual Studio.
|
||||
|
||||
On Mac OS X with Xcode installed, a .xcodeproj file will be generated.
|
||||
|
||||
### Legacy Build Scripts ###
|
||||
|
||||
Before settling on CMake, we have been providing hand-maintained build
|
||||
projects/scripts for Visual Studio, Xcode, and Autotools. While we
|
||||
continue to provide them for convenience, they are not actively
|
||||
maintained any more. We highly recommend that you follow the
|
||||
instructions in the previous two sections to integrate Google Test
|
||||
with your existing build system.
|
||||
|
||||
If you still need to use the legacy build scripts, here's how:
|
||||
|
||||
The msvc\ folder contains two solutions with Visual C++ projects.
|
||||
Open the gtest.sln or gtest-md.sln file using Visual Studio, and you
|
||||
are ready to build Google Test the same way you build any Visual
|
||||
Studio project. Files that have names ending with -md use DLL
|
||||
versions of Microsoft runtime libraries (the /MD or the /MDd compiler
|
||||
option). Files without that suffix use static versions of the runtime
|
||||
libraries (the /MT or the /MTd option). Please note that one must use
|
||||
the same option to compile both gtest and the test code. If you use
|
||||
Visual Studio 2005 or above, we recommend the -md version as /MD is
|
||||
the default for new projects in these versions of Visual Studio.
|
||||
|
||||
On Mac OS X, open the gtest.xcodeproj in the xcode/ folder using
|
||||
Xcode. Build the "gtest" target. The universal binary framework will
|
||||
end up in your selected build directory (selected in the Xcode
|
||||
"Preferences..." -> "Building" pane and defaults to xcode/build).
|
||||
Alternatively, at the command line, enter:
|
||||
|
||||
xcodebuild
|
||||
|
||||
This will build the "Release" configuration of gtest.framework in your
|
||||
default build location. See the "xcodebuild" man page for more
|
||||
information about building different configurations and building in
|
||||
different locations.
|
||||
|
||||
If you wish to use the Google Test Xcode project with Xcode 4.x and
|
||||
above, you need to either:
|
||||
* update the SDK configuration options in xcode/Config/General.xconfig.
|
||||
Comment options SDKROOT, MACOS_DEPLOYMENT_TARGET, and GCC_VERSION. If
|
||||
you choose this route you lose the ability to target earlier versions
|
||||
of MacOS X.
|
||||
* Install an SDK for an earlier version. This doesn't appear to be
|
||||
supported by Apple, but has been reported to work
|
||||
(http://stackoverflow.com/questions/5378518).
|
||||
|
||||
Tweaking Google Test
|
||||
--------------------
|
||||
|
||||
Google Test can be used in diverse environments. The default
|
||||
configuration may not work (or may not work well) out of the box in
|
||||
some environments. However, you can easily tweak Google Test by
|
||||
defining control macros on the compiler command line. Generally,
|
||||
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.
|
||||
|
||||
### Choosing a TR1 Tuple Library ###
|
||||
|
||||
Some Google Test features require the C++ Technical Report 1 (TR1)
|
||||
tuple library, which is not yet available with all compilers. The
|
||||
good news is that Google Test implements a subset of TR1 tuple that's
|
||||
enough for its own need, and will automatically use this when the
|
||||
compiler doesn't provide TR1 tuple.
|
||||
|
||||
Usually you don't need to care about which tuple library Google Test
|
||||
uses. However, if your project already uses TR1 tuple, you need to
|
||||
tell Google Test to use the same TR1 tuple library the rest of your
|
||||
project uses, or the two tuple implementations will clash. To do
|
||||
that, add
|
||||
|
||||
-DGTEST_USE_OWN_TR1_TUPLE=0
|
||||
|
||||
to the compiler flags while compiling Google Test and your tests. If
|
||||
you want to force Google Test to use its own tuple library, just add
|
||||
|
||||
-DGTEST_USE_OWN_TR1_TUPLE=1
|
||||
|
||||
to the compiler flags instead.
|
||||
|
||||
If you don't want Google Test to use tuple at all, add
|
||||
|
||||
-DGTEST_HAS_TR1_TUPLE=0
|
||||
|
||||
and all features using tuple will be disabled.
|
||||
|
||||
### Multi-threaded Tests ###
|
||||
|
||||
Google Test is thread-safe where the pthread library is available.
|
||||
After #include "gtest/gtest.h", you can check the GTEST_IS_THREADSAFE
|
||||
macro to see whether this is the case (yes if the macro is #defined to
|
||||
1, no if it's undefined.).
|
||||
|
||||
If Google Test doesn't correctly detect whether pthread is available
|
||||
in your environment, you can force it with
|
||||
|
||||
-DGTEST_HAS_PTHREAD=1
|
||||
|
||||
or
|
||||
|
||||
-DGTEST_HAS_PTHREAD=0
|
||||
|
||||
When Google Test uses pthread, you may need to add flags to your
|
||||
compiler and/or linker to select the pthread library, or you'll get
|
||||
link errors. If you use the CMake script or the deprecated Autotools
|
||||
script, this is taken care of for you. If you use your own build
|
||||
script, you'll need to read your compiler and linker's manual to
|
||||
figure out what flags to add.
|
||||
|
||||
### As a Shared Library (DLL) ###
|
||||
|
||||
Google Test is compact, so most users can build and link it as a
|
||||
static library for the simplicity. You can choose to use Google Test
|
||||
as a shared library (known as a DLL on Windows) if you prefer.
|
||||
|
||||
To compile *gtest* as a shared library, add
|
||||
|
||||
-DGTEST_CREATE_SHARED_LIBRARY=1
|
||||
|
||||
to the compiler flags. You'll also need to tell the linker to produce
|
||||
a shared library instead - consult your linker's manual for how to do
|
||||
it.
|
||||
|
||||
To compile your *tests* that use the gtest shared library, add
|
||||
|
||||
-DGTEST_LINKED_AS_SHARED_LIBRARY=1
|
||||
|
||||
to the compiler flags.
|
||||
|
||||
Note: while the above steps aren't technically necessary today when
|
||||
using some compilers (e.g. GCC), they may become necessary in the
|
||||
future, if we decide to improve the speed of loading the library (see
|
||||
http://gcc.gnu.org/wiki/Visibility for details). Therefore you are
|
||||
recommended to always add the above flags when using Google Test as a
|
||||
shared library. Otherwise a future release of Google Test may break
|
||||
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
|
||||
definitions. In case a Google Test macro clashes with another
|
||||
library, you can force Google Test to rename its macro to avoid the
|
||||
conflict.
|
||||
|
||||
Specifically, if both Google Test and some other code define macro
|
||||
FOO, you can add
|
||||
|
||||
-DGTEST_DONT_DEFINE_FOO=1
|
||||
|
||||
to the compiler flags to tell Google Test to change the macro's name
|
||||
from FOO to GTEST_FOO. Currently FOO can be FAIL, SUCCEED, or TEST.
|
||||
For example, with -DGTEST_DONT_DEFINE_TEST=1, you'll need to write
|
||||
|
||||
GTEST_TEST(SomeTest, DoesThis) { ... }
|
||||
|
||||
instead of
|
||||
|
||||
TEST(SomeTest, DoesThis) { ... }
|
||||
|
||||
in order to define a test.
|
||||
|
||||
Upgrating from an Earlier Version
|
||||
---------------------------------
|
||||
|
||||
We strive to keep Google Test releases backward compatible.
|
||||
Sometimes, though, we have to make some breaking changes for the
|
||||
users' long-term benefits. This section describes what you'll need to
|
||||
do if you are upgrading from an earlier version of Google Test.
|
||||
|
||||
### Upgrading from 1.3.0 or Earlier ###
|
||||
|
||||
You may need to explicitly enable or disable Google Test's own TR1
|
||||
tuple library. See the instructions in section "Choosing a TR1 Tuple
|
||||
Library".
|
||||
|
||||
### Upgrading from 1.4.0 or Earlier ###
|
||||
|
||||
The Autotools build script (configure + make) is no longer officially
|
||||
supportted. You are encouraged to migrate to your own build system or
|
||||
use CMake. If you still need to use Autotools, you can find
|
||||
instructions in the README file from Google Test 1.4.0.
|
||||
|
||||
On platforms where the pthread library is available, Google Test uses
|
||||
it in order to be thread-safe. See the "Multi-threaded Tests" section
|
||||
for what this means to your build script.
|
||||
|
||||
If you use Microsoft Visual C++ 7.1 with exceptions disabled, Google
|
||||
Test will no longer compile. This should affect very few people, as a
|
||||
large portion of STL (including <string>) doesn't compile in this mode
|
||||
anyway. We decided to stop supporting it in order to greatly simplify
|
||||
Google Test's implementation.
|
||||
|
||||
Developing Google Test
|
||||
----------------------
|
||||
|
||||
This section discusses how to make your own changes to Google Test.
|
||||
|
||||
### Testing Google Test Itself ###
|
||||
|
||||
To make sure your changes work as intended and don't break existing
|
||||
functionality, you'll want to compile and run Google Test's own tests.
|
||||
For that you can use CMake:
|
||||
|
||||
mkdir mybuild
|
||||
cd mybuild
|
||||
cmake -Dgtest_build_tests=ON ${GTEST_DIR}
|
||||
|
||||
Make sure you have Python installed, as some of Google Test's tests
|
||||
are written in Python. If the cmake command complains about not being
|
||||
able to find Python ("Could NOT find PythonInterp (missing:
|
||||
PYTHON_EXECUTABLE)"), try telling it explicitly where your Python
|
||||
executable can be found:
|
||||
|
||||
cmake -DPYTHON_EXECUTABLE=path/to/python -Dgtest_build_tests=ON ${GTEST_DIR}
|
||||
|
||||
Next, you can build Google Test and all of its own tests. On *nix,
|
||||
this is usually done by 'make'. To run the tests, do
|
||||
|
||||
make test
|
||||
|
||||
All tests should pass.
|
||||
|
||||
### Regenerating Source Files ###
|
||||
|
||||
Some of Google Test's source files are generated from templates (not
|
||||
in the C++ sense) using a script. A template file is named FOO.pump,
|
||||
where FOO is the name of the file it will generate. For example, the
|
||||
file include/gtest/internal/gtest-type-util.h.pump is used to generate
|
||||
gtest-type-util.h in the same directory.
|
||||
|
||||
Normally you don't need to worry about regenerating the source files,
|
||||
unless you need to modify them. In that case, you should modify the
|
||||
corresponding .pump files instead and run the pump.py Python script to
|
||||
regenerate them. You can find pump.py in the scripts/ directory.
|
||||
Read the Pump manual [2] for how to use it.
|
||||
|
||||
[2] http://code.google.com/p/googletest/wiki/PumpManual
|
||||
|
||||
### Contributing a Patch ###
|
||||
|
||||
We welcome patches. Please read the Google Test developer's guide [3]
|
||||
for how you can contribute. In particular, make sure you have signed
|
||||
the Contributor License Agreement, or we won't be able to accept the
|
||||
patch.
|
||||
|
||||
[3] http://code.google.com/p/googletest/wiki/GoogleTestDevGuide
|
||||
|
||||
Happy testing!
|
||||
1198
test/gmock-1.7.0/gtest/aclocal.m4
vendored
1198
test/gmock-1.7.0/gtest/aclocal.m4
vendored
File diff suppressed because it is too large
Load Diff
1530
test/gmock-1.7.0/gtest/build-aux/config.guess
vendored
1530
test/gmock-1.7.0/gtest/build-aux/config.guess
vendored
File diff suppressed because it is too large
Load Diff
@@ -1,69 +0,0 @@
|
||||
/* build-aux/config.h.in. Generated from configure.ac by autoheader. */
|
||||
|
||||
/* Define to 1 if you have the <dlfcn.h> header file. */
|
||||
#undef HAVE_DLFCN_H
|
||||
|
||||
/* Define to 1 if you have the <inttypes.h> header file. */
|
||||
#undef HAVE_INTTYPES_H
|
||||
|
||||
/* Define to 1 if you have the <memory.h> header file. */
|
||||
#undef HAVE_MEMORY_H
|
||||
|
||||
/* Define if you have POSIX threads libraries and header files. */
|
||||
#undef HAVE_PTHREAD
|
||||
|
||||
/* Define to 1 if you have the <stdint.h> header file. */
|
||||
#undef HAVE_STDINT_H
|
||||
|
||||
/* Define to 1 if you have the <stdlib.h> header file. */
|
||||
#undef HAVE_STDLIB_H
|
||||
|
||||
/* Define to 1 if you have the <strings.h> header file. */
|
||||
#undef HAVE_STRINGS_H
|
||||
|
||||
/* Define to 1 if you have the <string.h> header file. */
|
||||
#undef HAVE_STRING_H
|
||||
|
||||
/* Define to 1 if you have the <sys/stat.h> header file. */
|
||||
#undef HAVE_SYS_STAT_H
|
||||
|
||||
/* Define to 1 if you have the <sys/types.h> header file. */
|
||||
#undef HAVE_SYS_TYPES_H
|
||||
|
||||
/* Define to 1 if you have the <unistd.h> header file. */
|
||||
#undef HAVE_UNISTD_H
|
||||
|
||||
/* Define to the sub-directory in which libtool stores uninstalled libraries.
|
||||
*/
|
||||
#undef LT_OBJDIR
|
||||
|
||||
/* Name of package */
|
||||
#undef PACKAGE
|
||||
|
||||
/* Define to the address where bug reports for this package should be sent. */
|
||||
#undef PACKAGE_BUGREPORT
|
||||
|
||||
/* Define to the full name of this package. */
|
||||
#undef PACKAGE_NAME
|
||||
|
||||
/* Define to the full name and version of this package. */
|
||||
#undef PACKAGE_STRING
|
||||
|
||||
/* Define to the one symbol short name of this package. */
|
||||
#undef PACKAGE_TARNAME
|
||||
|
||||
/* Define to the home page for this package. */
|
||||
#undef PACKAGE_URL
|
||||
|
||||
/* Define to the version of this package. */
|
||||
#undef PACKAGE_VERSION
|
||||
|
||||
/* Define to necessary symbol if this constant uses a non-standard name on
|
||||
your system. */
|
||||
#undef PTHREAD_CREATE_JOINABLE
|
||||
|
||||
/* Define to 1 if you have the ANSI C header files. */
|
||||
#undef STDC_HEADERS
|
||||
|
||||
/* Version number of package */
|
||||
#undef VERSION
|
||||
1773
test/gmock-1.7.0/gtest/build-aux/config.sub
vendored
1773
test/gmock-1.7.0/gtest/build-aux/config.sub
vendored
File diff suppressed because it is too large
Load Diff
@@ -1,688 +0,0 @@
|
||||
#! /bin/sh
|
||||
# depcomp - compile a program generating dependencies as side-effects
|
||||
|
||||
scriptversion=2011-12-04.11; # UTC
|
||||
|
||||
# Copyright (C) 1999, 2000, 2003, 2004, 2005, 2006, 2007, 2009, 2010,
|
||||
# 2011 Free Software Foundation, Inc.
|
||||
|
||||
# This program is free software; you can redistribute it and/or modify
|
||||
# it under the terms of the GNU General Public License as published by
|
||||
# the Free Software Foundation; either version 2, or (at your option)
|
||||
# any later version.
|
||||
|
||||
# This program is distributed in the hope that it will be useful,
|
||||
# but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
||||
# GNU General Public License for more details.
|
||||
|
||||
# You should have received a copy of the GNU General Public License
|
||||
# along with this program. If not, see <http://www.gnu.org/licenses/>.
|
||||
|
||||
# As a special exception to the GNU General Public License, if you
|
||||
# distribute this file as part of a program that contains a
|
||||
# configuration script generated by Autoconf, you may include it under
|
||||
# the same distribution terms that you use for the rest of that program.
|
||||
|
||||
# Originally written by Alexandre Oliva <oliva@dcc.unicamp.br>.
|
||||
|
||||
case $1 in
|
||||
'')
|
||||
echo "$0: No command. Try \`$0 --help' for more information." 1>&2
|
||||
exit 1;
|
||||
;;
|
||||
-h | --h*)
|
||||
cat <<\EOF
|
||||
Usage: depcomp [--help] [--version] PROGRAM [ARGS]
|
||||
|
||||
Run PROGRAMS ARGS to compile a file, generating dependencies
|
||||
as side-effects.
|
||||
|
||||
Environment variables:
|
||||
depmode Dependency tracking mode.
|
||||
source Source file read by `PROGRAMS ARGS'.
|
||||
object Object file output by `PROGRAMS ARGS'.
|
||||
DEPDIR directory where to store dependencies.
|
||||
depfile Dependency file to output.
|
||||
tmpdepfile Temporary file to use when outputting dependencies.
|
||||
libtool Whether libtool is used (yes/no).
|
||||
|
||||
Report bugs to <bug-automake@gnu.org>.
|
||||
EOF
|
||||
exit $?
|
||||
;;
|
||||
-v | --v*)
|
||||
echo "depcomp $scriptversion"
|
||||
exit $?
|
||||
;;
|
||||
esac
|
||||
|
||||
if test -z "$depmode" || test -z "$source" || test -z "$object"; then
|
||||
echo "depcomp: Variables source, object and depmode must be set" 1>&2
|
||||
exit 1
|
||||
fi
|
||||
|
||||
# Dependencies for sub/bar.o or sub/bar.obj go into sub/.deps/bar.Po.
|
||||
depfile=${depfile-`echo "$object" |
|
||||
sed 's|[^\\/]*$|'${DEPDIR-.deps}'/&|;s|\.\([^.]*\)$|.P\1|;s|Pobj$|Po|'`}
|
||||
tmpdepfile=${tmpdepfile-`echo "$depfile" | sed 's/\.\([^.]*\)$/.T\1/'`}
|
||||
|
||||
rm -f "$tmpdepfile"
|
||||
|
||||
# Some modes work just like other modes, but use different flags. We
|
||||
# parameterize here, but still list the modes in the big case below,
|
||||
# to make depend.m4 easier to write. Note that we *cannot* use a case
|
||||
# here, because this file can only contain one case statement.
|
||||
if test "$depmode" = hp; then
|
||||
# HP compiler uses -M and no extra arg.
|
||||
gccflag=-M
|
||||
depmode=gcc
|
||||
fi
|
||||
|
||||
if test "$depmode" = dashXmstdout; then
|
||||
# This is just like dashmstdout with a different argument.
|
||||
dashmflag=-xM
|
||||
depmode=dashmstdout
|
||||
fi
|
||||
|
||||
cygpath_u="cygpath -u -f -"
|
||||
if test "$depmode" = msvcmsys; then
|
||||
# This is just like msvisualcpp but w/o cygpath translation.
|
||||
# Just convert the backslash-escaped backslashes to single forward
|
||||
# slashes to satisfy depend.m4
|
||||
cygpath_u='sed s,\\\\,/,g'
|
||||
depmode=msvisualcpp
|
||||
fi
|
||||
|
||||
if test "$depmode" = msvc7msys; then
|
||||
# This is just like msvc7 but w/o cygpath translation.
|
||||
# Just convert the backslash-escaped backslashes to single forward
|
||||
# slashes to satisfy depend.m4
|
||||
cygpath_u='sed s,\\\\,/,g'
|
||||
depmode=msvc7
|
||||
fi
|
||||
|
||||
case "$depmode" in
|
||||
gcc3)
|
||||
## gcc 3 implements dependency tracking that does exactly what
|
||||
## we want. Yay! Note: for some reason libtool 1.4 doesn't like
|
||||
## it if -MD -MP comes after the -MF stuff. Hmm.
|
||||
## Unfortunately, FreeBSD c89 acceptance of flags depends upon
|
||||
## the command line argument order; so add the flags where they
|
||||
## appear in depend2.am. Note that the slowdown incurred here
|
||||
## affects only configure: in makefiles, %FASTDEP% shortcuts this.
|
||||
for arg
|
||||
do
|
||||
case $arg in
|
||||
-c) set fnord "$@" -MT "$object" -MD -MP -MF "$tmpdepfile" "$arg" ;;
|
||||
*) set fnord "$@" "$arg" ;;
|
||||
esac
|
||||
shift # fnord
|
||||
shift # $arg
|
||||
done
|
||||
"$@"
|
||||
stat=$?
|
||||
if test $stat -eq 0; then :
|
||||
else
|
||||
rm -f "$tmpdepfile"
|
||||
exit $stat
|
||||
fi
|
||||
mv "$tmpdepfile" "$depfile"
|
||||
;;
|
||||
|
||||
gcc)
|
||||
## There are various ways to get dependency output from gcc. Here's
|
||||
## why we pick this rather obscure method:
|
||||
## - Don't want to use -MD because we'd like the dependencies to end
|
||||
## up in a subdir. Having to rename by hand is ugly.
|
||||
## (We might end up doing this anyway to support other compilers.)
|
||||
## - The DEPENDENCIES_OUTPUT environment variable makes gcc act like
|
||||
## -MM, not -M (despite what the docs say).
|
||||
## - Using -M directly means running the compiler twice (even worse
|
||||
## than renaming).
|
||||
if test -z "$gccflag"; then
|
||||
gccflag=-MD,
|
||||
fi
|
||||
"$@" -Wp,"$gccflag$tmpdepfile"
|
||||
stat=$?
|
||||
if test $stat -eq 0; then :
|
||||
else
|
||||
rm -f "$tmpdepfile"
|
||||
exit $stat
|
||||
fi
|
||||
rm -f "$depfile"
|
||||
echo "$object : \\" > "$depfile"
|
||||
alpha=ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz
|
||||
## The second -e expression handles DOS-style file names with drive letters.
|
||||
sed -e 's/^[^:]*: / /' \
|
||||
-e 's/^['$alpha']:\/[^:]*: / /' < "$tmpdepfile" >> "$depfile"
|
||||
## This next piece of magic avoids the `deleted header file' problem.
|
||||
## The problem is that when a header file which appears in a .P file
|
||||
## is deleted, the dependency causes make to die (because there is
|
||||
## typically no way to rebuild the header). We avoid this by adding
|
||||
## dummy dependencies for each header file. Too bad gcc doesn't do
|
||||
## this for us directly.
|
||||
tr ' ' '
|
||||
' < "$tmpdepfile" |
|
||||
## Some versions of gcc put a space before the `:'. On the theory
|
||||
## that the space means something, we add a space to the output as
|
||||
## well. hp depmode also adds that space, but also prefixes the VPATH
|
||||
## to the object. Take care to not repeat it in the output.
|
||||
## Some versions of the HPUX 10.20 sed can't process this invocation
|
||||
## correctly. Breaking it into two sed invocations is a workaround.
|
||||
sed -e 's/^\\$//' -e '/^$/d' -e "s|.*$object$||" -e '/:$/d' \
|
||||
| sed -e 's/$/ :/' >> "$depfile"
|
||||
rm -f "$tmpdepfile"
|
||||
;;
|
||||
|
||||
hp)
|
||||
# This case exists only to let depend.m4 do its work. It works by
|
||||
# looking at the text of this script. This case will never be run,
|
||||
# since it is checked for above.
|
||||
exit 1
|
||||
;;
|
||||
|
||||
sgi)
|
||||
if test "$libtool" = yes; then
|
||||
"$@" "-Wp,-MDupdate,$tmpdepfile"
|
||||
else
|
||||
"$@" -MDupdate "$tmpdepfile"
|
||||
fi
|
||||
stat=$?
|
||||
if test $stat -eq 0; then :
|
||||
else
|
||||
rm -f "$tmpdepfile"
|
||||
exit $stat
|
||||
fi
|
||||
rm -f "$depfile"
|
||||
|
||||
if test -f "$tmpdepfile"; then # yes, the sourcefile depend on other files
|
||||
echo "$object : \\" > "$depfile"
|
||||
|
||||
# Clip off the initial element (the dependent). Don't try to be
|
||||
# clever and replace this with sed code, as IRIX sed won't handle
|
||||
# lines with more than a fixed number of characters (4096 in
|
||||
# IRIX 6.2 sed, 8192 in IRIX 6.5). We also remove comment lines;
|
||||
# the IRIX cc adds comments like `#:fec' to the end of the
|
||||
# dependency line.
|
||||
tr ' ' '
|
||||
' < "$tmpdepfile" \
|
||||
| sed -e 's/^.*\.o://' -e 's/#.*$//' -e '/^$/ d' | \
|
||||
tr '
|
||||
' ' ' >> "$depfile"
|
||||
echo >> "$depfile"
|
||||
|
||||
# The second pass generates a dummy entry for each header file.
|
||||
tr ' ' '
|
||||
' < "$tmpdepfile" \
|
||||
| sed -e 's/^.*\.o://' -e 's/#.*$//' -e '/^$/ d' -e 's/$/:/' \
|
||||
>> "$depfile"
|
||||
else
|
||||
# The sourcefile does not contain any dependencies, so just
|
||||
# store a dummy comment line, to avoid errors with the Makefile
|
||||
# "include basename.Plo" scheme.
|
||||
echo "#dummy" > "$depfile"
|
||||
fi
|
||||
rm -f "$tmpdepfile"
|
||||
;;
|
||||
|
||||
aix)
|
||||
# The C for AIX Compiler uses -M and outputs the dependencies
|
||||
# in a .u file. In older versions, this file always lives in the
|
||||
# current directory. Also, the AIX compiler puts `$object:' at the
|
||||
# start of each line; $object doesn't have directory information.
|
||||
# Version 6 uses the directory in both cases.
|
||||
dir=`echo "$object" | sed -e 's|/[^/]*$|/|'`
|
||||
test "x$dir" = "x$object" && dir=
|
||||
base=`echo "$object" | sed -e 's|^.*/||' -e 's/\.o$//' -e 's/\.lo$//'`
|
||||
if test "$libtool" = yes; then
|
||||
tmpdepfile1=$dir$base.u
|
||||
tmpdepfile2=$base.u
|
||||
tmpdepfile3=$dir.libs/$base.u
|
||||
"$@" -Wc,-M
|
||||
else
|
||||
tmpdepfile1=$dir$base.u
|
||||
tmpdepfile2=$dir$base.u
|
||||
tmpdepfile3=$dir$base.u
|
||||
"$@" -M
|
||||
fi
|
||||
stat=$?
|
||||
|
||||
if test $stat -eq 0; then :
|
||||
else
|
||||
rm -f "$tmpdepfile1" "$tmpdepfile2" "$tmpdepfile3"
|
||||
exit $stat
|
||||
fi
|
||||
|
||||
for tmpdepfile in "$tmpdepfile1" "$tmpdepfile2" "$tmpdepfile3"
|
||||
do
|
||||
test -f "$tmpdepfile" && break
|
||||
done
|
||||
if test -f "$tmpdepfile"; then
|
||||
# Each line is of the form `foo.o: dependent.h'.
|
||||
# Do two passes, one to just change these to
|
||||
# `$object: dependent.h' and one to simply `dependent.h:'.
|
||||
sed -e "s,^.*\.[a-z]*:,$object:," < "$tmpdepfile" > "$depfile"
|
||||
# That's a tab and a space in the [].
|
||||
sed -e 's,^.*\.[a-z]*:[ ]*,,' -e 's,$,:,' < "$tmpdepfile" >> "$depfile"
|
||||
else
|
||||
# The sourcefile does not contain any dependencies, so just
|
||||
# store a dummy comment line, to avoid errors with the Makefile
|
||||
# "include basename.Plo" scheme.
|
||||
echo "#dummy" > "$depfile"
|
||||
fi
|
||||
rm -f "$tmpdepfile"
|
||||
;;
|
||||
|
||||
icc)
|
||||
# Intel's C compiler understands `-MD -MF file'. However on
|
||||
# icc -MD -MF foo.d -c -o sub/foo.o sub/foo.c
|
||||
# ICC 7.0 will fill foo.d with something like
|
||||
# foo.o: sub/foo.c
|
||||
# foo.o: sub/foo.h
|
||||
# which is wrong. We want:
|
||||
# sub/foo.o: sub/foo.c
|
||||
# sub/foo.o: sub/foo.h
|
||||
# sub/foo.c:
|
||||
# sub/foo.h:
|
||||
# ICC 7.1 will output
|
||||
# foo.o: sub/foo.c sub/foo.h
|
||||
# and will wrap long lines using \ :
|
||||
# foo.o: sub/foo.c ... \
|
||||
# sub/foo.h ... \
|
||||
# ...
|
||||
|
||||
"$@" -MD -MF "$tmpdepfile"
|
||||
stat=$?
|
||||
if test $stat -eq 0; then :
|
||||
else
|
||||
rm -f "$tmpdepfile"
|
||||
exit $stat
|
||||
fi
|
||||
rm -f "$depfile"
|
||||
# Each line is of the form `foo.o: dependent.h',
|
||||
# or `foo.o: dep1.h dep2.h \', or ` dep3.h dep4.h \'.
|
||||
# Do two passes, one to just change these to
|
||||
# `$object: dependent.h' and one to simply `dependent.h:'.
|
||||
sed "s,^[^:]*:,$object :," < "$tmpdepfile" > "$depfile"
|
||||
# Some versions of the HPUX 10.20 sed can't process this invocation
|
||||
# correctly. Breaking it into two sed invocations is a workaround.
|
||||
sed 's,^[^:]*: \(.*\)$,\1,;s/^\\$//;/^$/d;/:$/d' < "$tmpdepfile" |
|
||||
sed -e 's/$/ :/' >> "$depfile"
|
||||
rm -f "$tmpdepfile"
|
||||
;;
|
||||
|
||||
hp2)
|
||||
# The "hp" stanza above does not work with aCC (C++) and HP's ia64
|
||||
# compilers, which have integrated preprocessors. The correct option
|
||||
# to use with these is +Maked; it writes dependencies to a file named
|
||||
# 'foo.d', which lands next to the object file, wherever that
|
||||
# happens to be.
|
||||
# Much of this is similar to the tru64 case; see comments there.
|
||||
dir=`echo "$object" | sed -e 's|/[^/]*$|/|'`
|
||||
test "x$dir" = "x$object" && dir=
|
||||
base=`echo "$object" | sed -e 's|^.*/||' -e 's/\.o$//' -e 's/\.lo$//'`
|
||||
if test "$libtool" = yes; then
|
||||
tmpdepfile1=$dir$base.d
|
||||
tmpdepfile2=$dir.libs/$base.d
|
||||
"$@" -Wc,+Maked
|
||||
else
|
||||
tmpdepfile1=$dir$base.d
|
||||
tmpdepfile2=$dir$base.d
|
||||
"$@" +Maked
|
||||
fi
|
||||
stat=$?
|
||||
if test $stat -eq 0; then :
|
||||
else
|
||||
rm -f "$tmpdepfile1" "$tmpdepfile2"
|
||||
exit $stat
|
||||
fi
|
||||
|
||||
for tmpdepfile in "$tmpdepfile1" "$tmpdepfile2"
|
||||
do
|
||||
test -f "$tmpdepfile" && break
|
||||
done
|
||||
if test -f "$tmpdepfile"; then
|
||||
sed -e "s,^.*\.[a-z]*:,$object:," "$tmpdepfile" > "$depfile"
|
||||
# Add `dependent.h:' lines.
|
||||
sed -ne '2,${
|
||||
s/^ *//
|
||||
s/ \\*$//
|
||||
s/$/:/
|
||||
p
|
||||
}' "$tmpdepfile" >> "$depfile"
|
||||
else
|
||||
echo "#dummy" > "$depfile"
|
||||
fi
|
||||
rm -f "$tmpdepfile" "$tmpdepfile2"
|
||||
;;
|
||||
|
||||
tru64)
|
||||
# The Tru64 compiler uses -MD to generate dependencies as a side
|
||||
# effect. `cc -MD -o foo.o ...' puts the dependencies into `foo.o.d'.
|
||||
# At least on Alpha/Redhat 6.1, Compaq CCC V6.2-504 seems to put
|
||||
# dependencies in `foo.d' instead, so we check for that too.
|
||||
# Subdirectories are respected.
|
||||
dir=`echo "$object" | sed -e 's|/[^/]*$|/|'`
|
||||
test "x$dir" = "x$object" && dir=
|
||||
base=`echo "$object" | sed -e 's|^.*/||' -e 's/\.o$//' -e 's/\.lo$//'`
|
||||
|
||||
if test "$libtool" = yes; then
|
||||
# With Tru64 cc, shared objects can also be used to make a
|
||||
# static library. This mechanism is used in libtool 1.4 series to
|
||||
# handle both shared and static libraries in a single compilation.
|
||||
# With libtool 1.4, dependencies were output in $dir.libs/$base.lo.d.
|
||||
#
|
||||
# With libtool 1.5 this exception was removed, and libtool now
|
||||
# generates 2 separate objects for the 2 libraries. These two
|
||||
# compilations output dependencies in $dir.libs/$base.o.d and
|
||||
# in $dir$base.o.d. We have to check for both files, because
|
||||
# one of the two compilations can be disabled. We should prefer
|
||||
# $dir$base.o.d over $dir.libs/$base.o.d because the latter is
|
||||
# automatically cleaned when .libs/ is deleted, while ignoring
|
||||
# the former would cause a distcleancheck panic.
|
||||
tmpdepfile1=$dir.libs/$base.lo.d # libtool 1.4
|
||||
tmpdepfile2=$dir$base.o.d # libtool 1.5
|
||||
tmpdepfile3=$dir.libs/$base.o.d # libtool 1.5
|
||||
tmpdepfile4=$dir.libs/$base.d # Compaq CCC V6.2-504
|
||||
"$@" -Wc,-MD
|
||||
else
|
||||
tmpdepfile1=$dir$base.o.d
|
||||
tmpdepfile2=$dir$base.d
|
||||
tmpdepfile3=$dir$base.d
|
||||
tmpdepfile4=$dir$base.d
|
||||
"$@" -MD
|
||||
fi
|
||||
|
||||
stat=$?
|
||||
if test $stat -eq 0; then :
|
||||
else
|
||||
rm -f "$tmpdepfile1" "$tmpdepfile2" "$tmpdepfile3" "$tmpdepfile4"
|
||||
exit $stat
|
||||
fi
|
||||
|
||||
for tmpdepfile in "$tmpdepfile1" "$tmpdepfile2" "$tmpdepfile3" "$tmpdepfile4"
|
||||
do
|
||||
test -f "$tmpdepfile" && break
|
||||
done
|
||||
if test -f "$tmpdepfile"; then
|
||||
sed -e "s,^.*\.[a-z]*:,$object:," < "$tmpdepfile" > "$depfile"
|
||||
# That's a tab and a space in the [].
|
||||
sed -e 's,^.*\.[a-z]*:[ ]*,,' -e 's,$,:,' < "$tmpdepfile" >> "$depfile"
|
||||
else
|
||||
echo "#dummy" > "$depfile"
|
||||
fi
|
||||
rm -f "$tmpdepfile"
|
||||
;;
|
||||
|
||||
msvc7)
|
||||
if test "$libtool" = yes; then
|
||||
showIncludes=-Wc,-showIncludes
|
||||
else
|
||||
showIncludes=-showIncludes
|
||||
fi
|
||||
"$@" $showIncludes > "$tmpdepfile"
|
||||
stat=$?
|
||||
grep -v '^Note: including file: ' "$tmpdepfile"
|
||||
if test "$stat" = 0; then :
|
||||
else
|
||||
rm -f "$tmpdepfile"
|
||||
exit $stat
|
||||
fi
|
||||
rm -f "$depfile"
|
||||
echo "$object : \\" > "$depfile"
|
||||
# The first sed program below extracts the file names and escapes
|
||||
# backslashes for cygpath. The second sed program outputs the file
|
||||
# name when reading, but also accumulates all include files in the
|
||||
# hold buffer in order to output them again at the end. This only
|
||||
# works with sed implementations that can handle large buffers.
|
||||
sed < "$tmpdepfile" -n '
|
||||
/^Note: including file: *\(.*\)/ {
|
||||
s//\1/
|
||||
s/\\/\\\\/g
|
||||
p
|
||||
}' | $cygpath_u | sort -u | sed -n '
|
||||
s/ /\\ /g
|
||||
s/\(.*\)/ \1 \\/p
|
||||
s/.\(.*\) \\/\1:/
|
||||
H
|
||||
$ {
|
||||
s/.*/ /
|
||||
G
|
||||
p
|
||||
}' >> "$depfile"
|
||||
rm -f "$tmpdepfile"
|
||||
;;
|
||||
|
||||
msvc7msys)
|
||||
# This case exists only to let depend.m4 do its work. It works by
|
||||
# looking at the text of this script. This case will never be run,
|
||||
# since it is checked for above.
|
||||
exit 1
|
||||
;;
|
||||
|
||||
#nosideeffect)
|
||||
# This comment above is used by automake to tell side-effect
|
||||
# dependency tracking mechanisms from slower ones.
|
||||
|
||||
dashmstdout)
|
||||
# Important note: in order to support this mode, a compiler *must*
|
||||
# always write the preprocessed file to stdout, regardless of -o.
|
||||
"$@" || exit $?
|
||||
|
||||
# Remove the call to Libtool.
|
||||
if test "$libtool" = yes; then
|
||||
while test "X$1" != 'X--mode=compile'; do
|
||||
shift
|
||||
done
|
||||
shift
|
||||
fi
|
||||
|
||||
# Remove `-o $object'.
|
||||
IFS=" "
|
||||
for arg
|
||||
do
|
||||
case $arg in
|
||||
-o)
|
||||
shift
|
||||
;;
|
||||
$object)
|
||||
shift
|
||||
;;
|
||||
*)
|
||||
set fnord "$@" "$arg"
|
||||
shift # fnord
|
||||
shift # $arg
|
||||
;;
|
||||
esac
|
||||
done
|
||||
|
||||
test -z "$dashmflag" && dashmflag=-M
|
||||
# Require at least two characters before searching for `:'
|
||||
# in the target name. This is to cope with DOS-style filenames:
|
||||
# a dependency such as `c:/foo/bar' could be seen as target `c' otherwise.
|
||||
"$@" $dashmflag |
|
||||
sed 's:^[ ]*[^: ][^:][^:]*\:[ ]*:'"$object"'\: :' > "$tmpdepfile"
|
||||
rm -f "$depfile"
|
||||
cat < "$tmpdepfile" > "$depfile"
|
||||
tr ' ' '
|
||||
' < "$tmpdepfile" | \
|
||||
## Some versions of the HPUX 10.20 sed can't process this invocation
|
||||
## correctly. Breaking it into two sed invocations is a workaround.
|
||||
sed -e 's/^\\$//' -e '/^$/d' -e '/:$/d' | sed -e 's/$/ :/' >> "$depfile"
|
||||
rm -f "$tmpdepfile"
|
||||
;;
|
||||
|
||||
dashXmstdout)
|
||||
# This case only exists to satisfy depend.m4. It is never actually
|
||||
# run, as this mode is specially recognized in the preamble.
|
||||
exit 1
|
||||
;;
|
||||
|
||||
makedepend)
|
||||
"$@" || exit $?
|
||||
# Remove any Libtool call
|
||||
if test "$libtool" = yes; then
|
||||
while test "X$1" != 'X--mode=compile'; do
|
||||
shift
|
||||
done
|
||||
shift
|
||||
fi
|
||||
# X makedepend
|
||||
shift
|
||||
cleared=no eat=no
|
||||
for arg
|
||||
do
|
||||
case $cleared in
|
||||
no)
|
||||
set ""; shift
|
||||
cleared=yes ;;
|
||||
esac
|
||||
if test $eat = yes; then
|
||||
eat=no
|
||||
continue
|
||||
fi
|
||||
case "$arg" in
|
||||
-D*|-I*)
|
||||
set fnord "$@" "$arg"; shift ;;
|
||||
# Strip any option that makedepend may not understand. Remove
|
||||
# the object too, otherwise makedepend will parse it as a source file.
|
||||
-arch)
|
||||
eat=yes ;;
|
||||
-*|$object)
|
||||
;;
|
||||
*)
|
||||
set fnord "$@" "$arg"; shift ;;
|
||||
esac
|
||||
done
|
||||
obj_suffix=`echo "$object" | sed 's/^.*\././'`
|
||||
touch "$tmpdepfile"
|
||||
${MAKEDEPEND-makedepend} -o"$obj_suffix" -f"$tmpdepfile" "$@"
|
||||
rm -f "$depfile"
|
||||
# makedepend may prepend the VPATH from the source file name to the object.
|
||||
# No need to regex-escape $object, excess matching of '.' is harmless.
|
||||
sed "s|^.*\($object *:\)|\1|" "$tmpdepfile" > "$depfile"
|
||||
sed '1,2d' "$tmpdepfile" | tr ' ' '
|
||||
' | \
|
||||
## Some versions of the HPUX 10.20 sed can't process this invocation
|
||||
## correctly. Breaking it into two sed invocations is a workaround.
|
||||
sed -e 's/^\\$//' -e '/^$/d' -e '/:$/d' | sed -e 's/$/ :/' >> "$depfile"
|
||||
rm -f "$tmpdepfile" "$tmpdepfile".bak
|
||||
;;
|
||||
|
||||
cpp)
|
||||
# Important note: in order to support this mode, a compiler *must*
|
||||
# always write the preprocessed file to stdout.
|
||||
"$@" || exit $?
|
||||
|
||||
# Remove the call to Libtool.
|
||||
if test "$libtool" = yes; then
|
||||
while test "X$1" != 'X--mode=compile'; do
|
||||
shift
|
||||
done
|
||||
shift
|
||||
fi
|
||||
|
||||
# Remove `-o $object'.
|
||||
IFS=" "
|
||||
for arg
|
||||
do
|
||||
case $arg in
|
||||
-o)
|
||||
shift
|
||||
;;
|
||||
$object)
|
||||
shift
|
||||
;;
|
||||
*)
|
||||
set fnord "$@" "$arg"
|
||||
shift # fnord
|
||||
shift # $arg
|
||||
;;
|
||||
esac
|
||||
done
|
||||
|
||||
"$@" -E |
|
||||
sed -n -e '/^# [0-9][0-9]* "\([^"]*\)".*/ s:: \1 \\:p' \
|
||||
-e '/^#line [0-9][0-9]* "\([^"]*\)".*/ s:: \1 \\:p' |
|
||||
sed '$ s: \\$::' > "$tmpdepfile"
|
||||
rm -f "$depfile"
|
||||
echo "$object : \\" > "$depfile"
|
||||
cat < "$tmpdepfile" >> "$depfile"
|
||||
sed < "$tmpdepfile" '/^$/d;s/^ //;s/ \\$//;s/$/ :/' >> "$depfile"
|
||||
rm -f "$tmpdepfile"
|
||||
;;
|
||||
|
||||
msvisualcpp)
|
||||
# Important note: in order to support this mode, a compiler *must*
|
||||
# always write the preprocessed file to stdout.
|
||||
"$@" || exit $?
|
||||
|
||||
# Remove the call to Libtool.
|
||||
if test "$libtool" = yes; then
|
||||
while test "X$1" != 'X--mode=compile'; do
|
||||
shift
|
||||
done
|
||||
shift
|
||||
fi
|
||||
|
||||
IFS=" "
|
||||
for arg
|
||||
do
|
||||
case "$arg" in
|
||||
-o)
|
||||
shift
|
||||
;;
|
||||
$object)
|
||||
shift
|
||||
;;
|
||||
"-Gm"|"/Gm"|"-Gi"|"/Gi"|"-ZI"|"/ZI")
|
||||
set fnord "$@"
|
||||
shift
|
||||
shift
|
||||
;;
|
||||
*)
|
||||
set fnord "$@" "$arg"
|
||||
shift
|
||||
shift
|
||||
;;
|
||||
esac
|
||||
done
|
||||
"$@" -E 2>/dev/null |
|
||||
sed -n '/^#line [0-9][0-9]* "\([^"]*\)"/ s::\1:p' | $cygpath_u | sort -u > "$tmpdepfile"
|
||||
rm -f "$depfile"
|
||||
echo "$object : \\" > "$depfile"
|
||||
sed < "$tmpdepfile" -n -e 's% %\\ %g' -e '/^\(.*\)$/ s:: \1 \\:p' >> "$depfile"
|
||||
echo " " >> "$depfile"
|
||||
sed < "$tmpdepfile" -n -e 's% %\\ %g' -e '/^\(.*\)$/ s::\1\::p' >> "$depfile"
|
||||
rm -f "$tmpdepfile"
|
||||
;;
|
||||
|
||||
msvcmsys)
|
||||
# This case exists only to let depend.m4 do its work. It works by
|
||||
# looking at the text of this script. This case will never be run,
|
||||
# since it is checked for above.
|
||||
exit 1
|
||||
;;
|
||||
|
||||
none)
|
||||
exec "$@"
|
||||
;;
|
||||
|
||||
*)
|
||||
echo "Unknown depmode $depmode" 1>&2
|
||||
exit 1
|
||||
;;
|
||||
esac
|
||||
|
||||
exit 0
|
||||
|
||||
# Local Variables:
|
||||
# mode: shell-script
|
||||
# sh-indentation: 2
|
||||
# eval: (add-hook 'write-file-hooks 'time-stamp)
|
||||
# time-stamp-start: "scriptversion="
|
||||
# time-stamp-format: "%:y-%02m-%02d.%02H"
|
||||
# time-stamp-time-zone: "UTC"
|
||||
# time-stamp-end: "; # UTC"
|
||||
# End:
|
||||
@@ -1,527 +0,0 @@
|
||||
#!/bin/sh
|
||||
# install - install a program, script, or datafile
|
||||
|
||||
scriptversion=2011-01-19.21; # UTC
|
||||
|
||||
# This originates from X11R5 (mit/util/scripts/install.sh), which was
|
||||
# later released in X11R6 (xc/config/util/install.sh) with the
|
||||
# following copyright and license.
|
||||
#
|
||||
# Copyright (C) 1994 X Consortium
|
||||
#
|
||||
# Permission is hereby granted, free of charge, to any person obtaining a copy
|
||||
# of this software and associated documentation files (the "Software"), to
|
||||
# deal in the Software without restriction, including without limitation the
|
||||
# rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
|
||||
# sell copies of the Software, and to permit persons to whom the Software is
|
||||
# furnished to do so, subject to the following conditions:
|
||||
#
|
||||
# The above copyright notice and this permission notice shall be included in
|
||||
# all copies or substantial portions of the Software.
|
||||
#
|
||||
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
||||
# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
||||
# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
||||
# X CONSORTIUM BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN
|
||||
# AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNEC-
|
||||
# TION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
|
||||
#
|
||||
# Except as contained in this notice, the name of the X Consortium shall not
|
||||
# be used in advertising or otherwise to promote the sale, use or other deal-
|
||||
# ings in this Software without prior written authorization from the X Consor-
|
||||
# tium.
|
||||
#
|
||||
#
|
||||
# FSF changes to this file are in the public domain.
|
||||
#
|
||||
# Calling this script install-sh is preferred over install.sh, to prevent
|
||||
# `make' implicit rules from creating a file called install from it
|
||||
# when there is no Makefile.
|
||||
#
|
||||
# This script is compatible with the BSD install script, but was written
|
||||
# from scratch.
|
||||
|
||||
nl='
|
||||
'
|
||||
IFS=" "" $nl"
|
||||
|
||||
# set DOITPROG to echo to test this script
|
||||
|
||||
# Don't use :- since 4.3BSD and earlier shells don't like it.
|
||||
doit=${DOITPROG-}
|
||||
if test -z "$doit"; then
|
||||
doit_exec=exec
|
||||
else
|
||||
doit_exec=$doit
|
||||
fi
|
||||
|
||||
# Put in absolute file names if you don't have them in your path;
|
||||
# or use environment vars.
|
||||
|
||||
chgrpprog=${CHGRPPROG-chgrp}
|
||||
chmodprog=${CHMODPROG-chmod}
|
||||
chownprog=${CHOWNPROG-chown}
|
||||
cmpprog=${CMPPROG-cmp}
|
||||
cpprog=${CPPROG-cp}
|
||||
mkdirprog=${MKDIRPROG-mkdir}
|
||||
mvprog=${MVPROG-mv}
|
||||
rmprog=${RMPROG-rm}
|
||||
stripprog=${STRIPPROG-strip}
|
||||
|
||||
posix_glob='?'
|
||||
initialize_posix_glob='
|
||||
test "$posix_glob" != "?" || {
|
||||
if (set -f) 2>/dev/null; then
|
||||
posix_glob=
|
||||
else
|
||||
posix_glob=:
|
||||
fi
|
||||
}
|
||||
'
|
||||
|
||||
posix_mkdir=
|
||||
|
||||
# Desired mode of installed file.
|
||||
mode=0755
|
||||
|
||||
chgrpcmd=
|
||||
chmodcmd=$chmodprog
|
||||
chowncmd=
|
||||
mvcmd=$mvprog
|
||||
rmcmd="$rmprog -f"
|
||||
stripcmd=
|
||||
|
||||
src=
|
||||
dst=
|
||||
dir_arg=
|
||||
dst_arg=
|
||||
|
||||
copy_on_change=false
|
||||
no_target_directory=
|
||||
|
||||
usage="\
|
||||
Usage: $0 [OPTION]... [-T] SRCFILE DSTFILE
|
||||
or: $0 [OPTION]... SRCFILES... DIRECTORY
|
||||
or: $0 [OPTION]... -t DIRECTORY SRCFILES...
|
||||
or: $0 [OPTION]... -d DIRECTORIES...
|
||||
|
||||
In the 1st form, copy SRCFILE to DSTFILE.
|
||||
In the 2nd and 3rd, copy all SRCFILES to DIRECTORY.
|
||||
In the 4th, create DIRECTORIES.
|
||||
|
||||
Options:
|
||||
--help display this help and exit.
|
||||
--version display version info and exit.
|
||||
|
||||
-c (ignored)
|
||||
-C install only if different (preserve the last data modification time)
|
||||
-d create directories instead of installing files.
|
||||
-g GROUP $chgrpprog installed files to GROUP.
|
||||
-m MODE $chmodprog installed files to MODE.
|
||||
-o USER $chownprog installed files to USER.
|
||||
-s $stripprog installed files.
|
||||
-t DIRECTORY install into DIRECTORY.
|
||||
-T report an error if DSTFILE is a directory.
|
||||
|
||||
Environment variables override the default commands:
|
||||
CHGRPPROG CHMODPROG CHOWNPROG CMPPROG CPPROG MKDIRPROG MVPROG
|
||||
RMPROG STRIPPROG
|
||||
"
|
||||
|
||||
while test $# -ne 0; do
|
||||
case $1 in
|
||||
-c) ;;
|
||||
|
||||
-C) copy_on_change=true;;
|
||||
|
||||
-d) dir_arg=true;;
|
||||
|
||||
-g) chgrpcmd="$chgrpprog $2"
|
||||
shift;;
|
||||
|
||||
--help) echo "$usage"; exit $?;;
|
||||
|
||||
-m) mode=$2
|
||||
case $mode in
|
||||
*' '* | *' '* | *'
|
||||
'* | *'*'* | *'?'* | *'['*)
|
||||
echo "$0: invalid mode: $mode" >&2
|
||||
exit 1;;
|
||||
esac
|
||||
shift;;
|
||||
|
||||
-o) chowncmd="$chownprog $2"
|
||||
shift;;
|
||||
|
||||
-s) stripcmd=$stripprog;;
|
||||
|
||||
-t) dst_arg=$2
|
||||
# Protect names problematic for `test' and other utilities.
|
||||
case $dst_arg in
|
||||
-* | [=\(\)!]) dst_arg=./$dst_arg;;
|
||||
esac
|
||||
shift;;
|
||||
|
||||
-T) no_target_directory=true;;
|
||||
|
||||
--version) echo "$0 $scriptversion"; exit $?;;
|
||||
|
||||
--) shift
|
||||
break;;
|
||||
|
||||
-*) echo "$0: invalid option: $1" >&2
|
||||
exit 1;;
|
||||
|
||||
*) break;;
|
||||
esac
|
||||
shift
|
||||
done
|
||||
|
||||
if test $# -ne 0 && test -z "$dir_arg$dst_arg"; then
|
||||
# When -d is used, all remaining arguments are directories to create.
|
||||
# When -t is used, the destination is already specified.
|
||||
# Otherwise, the last argument is the destination. Remove it from $@.
|
||||
for arg
|
||||
do
|
||||
if test -n "$dst_arg"; then
|
||||
# $@ is not empty: it contains at least $arg.
|
||||
set fnord "$@" "$dst_arg"
|
||||
shift # fnord
|
||||
fi
|
||||
shift # arg
|
||||
dst_arg=$arg
|
||||
# Protect names problematic for `test' and other utilities.
|
||||
case $dst_arg in
|
||||
-* | [=\(\)!]) dst_arg=./$dst_arg;;
|
||||
esac
|
||||
done
|
||||
fi
|
||||
|
||||
if test $# -eq 0; then
|
||||
if test -z "$dir_arg"; then
|
||||
echo "$0: no input file specified." >&2
|
||||
exit 1
|
||||
fi
|
||||
# It's OK to call `install-sh -d' without argument.
|
||||
# This can happen when creating conditional directories.
|
||||
exit 0
|
||||
fi
|
||||
|
||||
if test -z "$dir_arg"; then
|
||||
do_exit='(exit $ret); exit $ret'
|
||||
trap "ret=129; $do_exit" 1
|
||||
trap "ret=130; $do_exit" 2
|
||||
trap "ret=141; $do_exit" 13
|
||||
trap "ret=143; $do_exit" 15
|
||||
|
||||
# Set umask so as not to create temps with too-generous modes.
|
||||
# However, 'strip' requires both read and write access to temps.
|
||||
case $mode in
|
||||
# Optimize common cases.
|
||||
*644) cp_umask=133;;
|
||||
*755) cp_umask=22;;
|
||||
|
||||
*[0-7])
|
||||
if test -z "$stripcmd"; then
|
||||
u_plus_rw=
|
||||
else
|
||||
u_plus_rw='% 200'
|
||||
fi
|
||||
cp_umask=`expr '(' 777 - $mode % 1000 ')' $u_plus_rw`;;
|
||||
*)
|
||||
if test -z "$stripcmd"; then
|
||||
u_plus_rw=
|
||||
else
|
||||
u_plus_rw=,u+rw
|
||||
fi
|
||||
cp_umask=$mode$u_plus_rw;;
|
||||
esac
|
||||
fi
|
||||
|
||||
for src
|
||||
do
|
||||
# Protect names problematic for `test' and other utilities.
|
||||
case $src in
|
||||
-* | [=\(\)!]) src=./$src;;
|
||||
esac
|
||||
|
||||
if test -n "$dir_arg"; then
|
||||
dst=$src
|
||||
dstdir=$dst
|
||||
test -d "$dstdir"
|
||||
dstdir_status=$?
|
||||
else
|
||||
|
||||
# Waiting for this to be detected by the "$cpprog $src $dsttmp" command
|
||||
# might cause directories to be created, which would be especially bad
|
||||
# if $src (and thus $dsttmp) contains '*'.
|
||||
if test ! -f "$src" && test ! -d "$src"; then
|
||||
echo "$0: $src does not exist." >&2
|
||||
exit 1
|
||||
fi
|
||||
|
||||
if test -z "$dst_arg"; then
|
||||
echo "$0: no destination specified." >&2
|
||||
exit 1
|
||||
fi
|
||||
dst=$dst_arg
|
||||
|
||||
# If destination is a directory, append the input filename; won't work
|
||||
# if double slashes aren't ignored.
|
||||
if test -d "$dst"; then
|
||||
if test -n "$no_target_directory"; then
|
||||
echo "$0: $dst_arg: Is a directory" >&2
|
||||
exit 1
|
||||
fi
|
||||
dstdir=$dst
|
||||
dst=$dstdir/`basename "$src"`
|
||||
dstdir_status=0
|
||||
else
|
||||
# Prefer dirname, but fall back on a substitute if dirname fails.
|
||||
dstdir=`
|
||||
(dirname "$dst") 2>/dev/null ||
|
||||
expr X"$dst" : 'X\(.*[^/]\)//*[^/][^/]*/*$' \| \
|
||||
X"$dst" : 'X\(//\)[^/]' \| \
|
||||
X"$dst" : 'X\(//\)$' \| \
|
||||
X"$dst" : 'X\(/\)' \| . 2>/dev/null ||
|
||||
echo X"$dst" |
|
||||
sed '/^X\(.*[^/]\)\/\/*[^/][^/]*\/*$/{
|
||||
s//\1/
|
||||
q
|
||||
}
|
||||
/^X\(\/\/\)[^/].*/{
|
||||
s//\1/
|
||||
q
|
||||
}
|
||||
/^X\(\/\/\)$/{
|
||||
s//\1/
|
||||
q
|
||||
}
|
||||
/^X\(\/\).*/{
|
||||
s//\1/
|
||||
q
|
||||
}
|
||||
s/.*/./; q'
|
||||
`
|
||||
|
||||
test -d "$dstdir"
|
||||
dstdir_status=$?
|
||||
fi
|
||||
fi
|
||||
|
||||
obsolete_mkdir_used=false
|
||||
|
||||
if test $dstdir_status != 0; then
|
||||
case $posix_mkdir in
|
||||
'')
|
||||
# Create intermediate dirs using mode 755 as modified by the umask.
|
||||
# This is like FreeBSD 'install' as of 1997-10-28.
|
||||
umask=`umask`
|
||||
case $stripcmd.$umask in
|
||||
# Optimize common cases.
|
||||
*[2367][2367]) mkdir_umask=$umask;;
|
||||
.*0[02][02] | .[02][02] | .[02]) mkdir_umask=22;;
|
||||
|
||||
*[0-7])
|
||||
mkdir_umask=`expr $umask + 22 \
|
||||
- $umask % 100 % 40 + $umask % 20 \
|
||||
- $umask % 10 % 4 + $umask % 2
|
||||
`;;
|
||||
*) mkdir_umask=$umask,go-w;;
|
||||
esac
|
||||
|
||||
# With -d, create the new directory with the user-specified mode.
|
||||
# Otherwise, rely on $mkdir_umask.
|
||||
if test -n "$dir_arg"; then
|
||||
mkdir_mode=-m$mode
|
||||
else
|
||||
mkdir_mode=
|
||||
fi
|
||||
|
||||
posix_mkdir=false
|
||||
case $umask in
|
||||
*[123567][0-7][0-7])
|
||||
# POSIX mkdir -p sets u+wx bits regardless of umask, which
|
||||
# is incompatible with FreeBSD 'install' when (umask & 300) != 0.
|
||||
;;
|
||||
*)
|
||||
tmpdir=${TMPDIR-/tmp}/ins$RANDOM-$$
|
||||
trap 'ret=$?; rmdir "$tmpdir/d" "$tmpdir" 2>/dev/null; exit $ret' 0
|
||||
|
||||
if (umask $mkdir_umask &&
|
||||
exec $mkdirprog $mkdir_mode -p -- "$tmpdir/d") >/dev/null 2>&1
|
||||
then
|
||||
if test -z "$dir_arg" || {
|
||||
# Check for POSIX incompatibilities with -m.
|
||||
# HP-UX 11.23 and IRIX 6.5 mkdir -m -p sets group- or
|
||||
# other-writeable bit of parent directory when it shouldn't.
|
||||
# FreeBSD 6.1 mkdir -m -p sets mode of existing directory.
|
||||
ls_ld_tmpdir=`ls -ld "$tmpdir"`
|
||||
case $ls_ld_tmpdir in
|
||||
d????-?r-*) different_mode=700;;
|
||||
d????-?--*) different_mode=755;;
|
||||
*) false;;
|
||||
esac &&
|
||||
$mkdirprog -m$different_mode -p -- "$tmpdir" && {
|
||||
ls_ld_tmpdir_1=`ls -ld "$tmpdir"`
|
||||
test "$ls_ld_tmpdir" = "$ls_ld_tmpdir_1"
|
||||
}
|
||||
}
|
||||
then posix_mkdir=:
|
||||
fi
|
||||
rmdir "$tmpdir/d" "$tmpdir"
|
||||
else
|
||||
# Remove any dirs left behind by ancient mkdir implementations.
|
||||
rmdir ./$mkdir_mode ./-p ./-- 2>/dev/null
|
||||
fi
|
||||
trap '' 0;;
|
||||
esac;;
|
||||
esac
|
||||
|
||||
if
|
||||
$posix_mkdir && (
|
||||
umask $mkdir_umask &&
|
||||
$doit_exec $mkdirprog $mkdir_mode -p -- "$dstdir"
|
||||
)
|
||||
then :
|
||||
else
|
||||
|
||||
# The umask is ridiculous, or mkdir does not conform to POSIX,
|
||||
# or it failed possibly due to a race condition. Create the
|
||||
# directory the slow way, step by step, checking for races as we go.
|
||||
|
||||
case $dstdir in
|
||||
/*) prefix='/';;
|
||||
[-=\(\)!]*) prefix='./';;
|
||||
*) prefix='';;
|
||||
esac
|
||||
|
||||
eval "$initialize_posix_glob"
|
||||
|
||||
oIFS=$IFS
|
||||
IFS=/
|
||||
$posix_glob set -f
|
||||
set fnord $dstdir
|
||||
shift
|
||||
$posix_glob set +f
|
||||
IFS=$oIFS
|
||||
|
||||
prefixes=
|
||||
|
||||
for d
|
||||
do
|
||||
test X"$d" = X && continue
|
||||
|
||||
prefix=$prefix$d
|
||||
if test -d "$prefix"; then
|
||||
prefixes=
|
||||
else
|
||||
if $posix_mkdir; then
|
||||
(umask=$mkdir_umask &&
|
||||
$doit_exec $mkdirprog $mkdir_mode -p -- "$dstdir") && break
|
||||
# Don't fail if two instances are running concurrently.
|
||||
test -d "$prefix" || exit 1
|
||||
else
|
||||
case $prefix in
|
||||
*\'*) qprefix=`echo "$prefix" | sed "s/'/'\\\\\\\\''/g"`;;
|
||||
*) qprefix=$prefix;;
|
||||
esac
|
||||
prefixes="$prefixes '$qprefix'"
|
||||
fi
|
||||
fi
|
||||
prefix=$prefix/
|
||||
done
|
||||
|
||||
if test -n "$prefixes"; then
|
||||
# Don't fail if two instances are running concurrently.
|
||||
(umask $mkdir_umask &&
|
||||
eval "\$doit_exec \$mkdirprog $prefixes") ||
|
||||
test -d "$dstdir" || exit 1
|
||||
obsolete_mkdir_used=true
|
||||
fi
|
||||
fi
|
||||
fi
|
||||
|
||||
if test -n "$dir_arg"; then
|
||||
{ test -z "$chowncmd" || $doit $chowncmd "$dst"; } &&
|
||||
{ test -z "$chgrpcmd" || $doit $chgrpcmd "$dst"; } &&
|
||||
{ test "$obsolete_mkdir_used$chowncmd$chgrpcmd" = false ||
|
||||
test -z "$chmodcmd" || $doit $chmodcmd $mode "$dst"; } || exit 1
|
||||
else
|
||||
|
||||
# Make a couple of temp file names in the proper directory.
|
||||
dsttmp=$dstdir/_inst.$$_
|
||||
rmtmp=$dstdir/_rm.$$_
|
||||
|
||||
# Trap to clean up those temp files at exit.
|
||||
trap 'ret=$?; rm -f "$dsttmp" "$rmtmp" && exit $ret' 0
|
||||
|
||||
# Copy the file name to the temp name.
|
||||
(umask $cp_umask && $doit_exec $cpprog "$src" "$dsttmp") &&
|
||||
|
||||
# and set any options; do chmod last to preserve setuid bits.
|
||||
#
|
||||
# If any of these fail, we abort the whole thing. If we want to
|
||||
# ignore errors from any of these, just make sure not to ignore
|
||||
# errors from the above "$doit $cpprog $src $dsttmp" command.
|
||||
#
|
||||
{ test -z "$chowncmd" || $doit $chowncmd "$dsttmp"; } &&
|
||||
{ test -z "$chgrpcmd" || $doit $chgrpcmd "$dsttmp"; } &&
|
||||
{ test -z "$stripcmd" || $doit $stripcmd "$dsttmp"; } &&
|
||||
{ test -z "$chmodcmd" || $doit $chmodcmd $mode "$dsttmp"; } &&
|
||||
|
||||
# If -C, don't bother to copy if it wouldn't change the file.
|
||||
if $copy_on_change &&
|
||||
old=`LC_ALL=C ls -dlL "$dst" 2>/dev/null` &&
|
||||
new=`LC_ALL=C ls -dlL "$dsttmp" 2>/dev/null` &&
|
||||
|
||||
eval "$initialize_posix_glob" &&
|
||||
$posix_glob set -f &&
|
||||
set X $old && old=:$2:$4:$5:$6 &&
|
||||
set X $new && new=:$2:$4:$5:$6 &&
|
||||
$posix_glob set +f &&
|
||||
|
||||
test "$old" = "$new" &&
|
||||
$cmpprog "$dst" "$dsttmp" >/dev/null 2>&1
|
||||
then
|
||||
rm -f "$dsttmp"
|
||||
else
|
||||
# Rename the file to the real destination.
|
||||
$doit $mvcmd -f "$dsttmp" "$dst" 2>/dev/null ||
|
||||
|
||||
# The rename failed, perhaps because mv can't rename something else
|
||||
# to itself, or perhaps because mv is so ancient that it does not
|
||||
# support -f.
|
||||
{
|
||||
# Now remove or move aside any old file at destination location.
|
||||
# We try this two ways since rm can't unlink itself on some
|
||||
# systems and the destination file might be busy for other
|
||||
# reasons. In this case, the final cleanup might fail but the new
|
||||
# file should still install successfully.
|
||||
{
|
||||
test ! -f "$dst" ||
|
||||
$doit $rmcmd -f "$dst" 2>/dev/null ||
|
||||
{ $doit $mvcmd -f "$dst" "$rmtmp" 2>/dev/null &&
|
||||
{ $doit $rmcmd -f "$rmtmp" 2>/dev/null; :; }
|
||||
} ||
|
||||
{ echo "$0: cannot unlink or rename $dst" >&2
|
||||
(exit 1); exit 1
|
||||
}
|
||||
} &&
|
||||
|
||||
# Now rename the file to the real destination.
|
||||
$doit $mvcmd "$dsttmp" "$dst"
|
||||
}
|
||||
fi || exit 1
|
||||
|
||||
trap '' 0
|
||||
fi
|
||||
done
|
||||
|
||||
# Local variables:
|
||||
# eval: (add-hook 'write-file-hooks 'time-stamp)
|
||||
# time-stamp-start: "scriptversion="
|
||||
# time-stamp-format: "%:y-%02m-%02d.%02H"
|
||||
# time-stamp-time-zone: "UTC"
|
||||
# time-stamp-end: "; # UTC"
|
||||
# End:
|
||||
File diff suppressed because it is too large
Load Diff
@@ -1,331 +0,0 @@
|
||||
#! /bin/sh
|
||||
# Common stub for a few missing GNU programs while installing.
|
||||
|
||||
scriptversion=2012-01-06.13; # UTC
|
||||
|
||||
# Copyright (C) 1996, 1997, 1999, 2000, 2002, 2003, 2004, 2005, 2006,
|
||||
# 2008, 2009, 2010, 2011, 2012 Free Software Foundation, Inc.
|
||||
# Originally by Fran,cois Pinard <pinard@iro.umontreal.ca>, 1996.
|
||||
|
||||
# This program is free software; you can redistribute it and/or modify
|
||||
# it under the terms of the GNU General Public License as published by
|
||||
# the Free Software Foundation; either version 2, or (at your option)
|
||||
# any later version.
|
||||
|
||||
# This program is distributed in the hope that it will be useful,
|
||||
# but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
||||
# GNU General Public License for more details.
|
||||
|
||||
# You should have received a copy of the GNU General Public License
|
||||
# along with this program. If not, see <http://www.gnu.org/licenses/>.
|
||||
|
||||
# As a special exception to the GNU General Public License, if you
|
||||
# distribute this file as part of a program that contains a
|
||||
# configuration script generated by Autoconf, you may include it under
|
||||
# the same distribution terms that you use for the rest of that program.
|
||||
|
||||
if test $# -eq 0; then
|
||||
echo 1>&2 "Try \`$0 --help' for more information"
|
||||
exit 1
|
||||
fi
|
||||
|
||||
run=:
|
||||
sed_output='s/.* --output[ =]\([^ ]*\).*/\1/p'
|
||||
sed_minuso='s/.* -o \([^ ]*\).*/\1/p'
|
||||
|
||||
# In the cases where this matters, `missing' is being run in the
|
||||
# srcdir already.
|
||||
if test -f configure.ac; then
|
||||
configure_ac=configure.ac
|
||||
else
|
||||
configure_ac=configure.in
|
||||
fi
|
||||
|
||||
msg="missing on your system"
|
||||
|
||||
case $1 in
|
||||
--run)
|
||||
# Try to run requested program, and just exit if it succeeds.
|
||||
run=
|
||||
shift
|
||||
"$@" && exit 0
|
||||
# Exit code 63 means version mismatch. This often happens
|
||||
# when the user try to use an ancient version of a tool on
|
||||
# a file that requires a minimum version. In this case we
|
||||
# we should proceed has if the program had been absent, or
|
||||
# if --run hadn't been passed.
|
||||
if test $? = 63; then
|
||||
run=:
|
||||
msg="probably too old"
|
||||
fi
|
||||
;;
|
||||
|
||||
-h|--h|--he|--hel|--help)
|
||||
echo "\
|
||||
$0 [OPTION]... PROGRAM [ARGUMENT]...
|
||||
|
||||
Handle \`PROGRAM [ARGUMENT]...' for when PROGRAM is missing, or return an
|
||||
error status if there is no known handling for PROGRAM.
|
||||
|
||||
Options:
|
||||
-h, --help display this help and exit
|
||||
-v, --version output version information and exit
|
||||
--run try to run the given command, and emulate it if it fails
|
||||
|
||||
Supported PROGRAM values:
|
||||
aclocal touch file \`aclocal.m4'
|
||||
autoconf touch file \`configure'
|
||||
autoheader touch file \`config.h.in'
|
||||
autom4te touch the output file, or create a stub one
|
||||
automake touch all \`Makefile.in' files
|
||||
bison create \`y.tab.[ch]', if possible, from existing .[ch]
|
||||
flex create \`lex.yy.c', if possible, from existing .c
|
||||
help2man touch the output file
|
||||
lex create \`lex.yy.c', if possible, from existing .c
|
||||
makeinfo touch the output file
|
||||
yacc create \`y.tab.[ch]', if possible, from existing .[ch]
|
||||
|
||||
Version suffixes to PROGRAM as well as the prefixes \`gnu-', \`gnu', and
|
||||
\`g' are ignored when checking the name.
|
||||
|
||||
Send bug reports to <bug-automake@gnu.org>."
|
||||
exit $?
|
||||
;;
|
||||
|
||||
-v|--v|--ve|--ver|--vers|--versi|--versio|--version)
|
||||
echo "missing $scriptversion (GNU Automake)"
|
||||
exit $?
|
||||
;;
|
||||
|
||||
-*)
|
||||
echo 1>&2 "$0: Unknown \`$1' option"
|
||||
echo 1>&2 "Try \`$0 --help' for more information"
|
||||
exit 1
|
||||
;;
|
||||
|
||||
esac
|
||||
|
||||
# normalize program name to check for.
|
||||
program=`echo "$1" | sed '
|
||||
s/^gnu-//; t
|
||||
s/^gnu//; t
|
||||
s/^g//; t'`
|
||||
|
||||
# Now exit if we have it, but it failed. Also exit now if we
|
||||
# don't have it and --version was passed (most likely to detect
|
||||
# the program). This is about non-GNU programs, so use $1 not
|
||||
# $program.
|
||||
case $1 in
|
||||
lex*|yacc*)
|
||||
# Not GNU programs, they don't have --version.
|
||||
;;
|
||||
|
||||
*)
|
||||
if test -z "$run" && ($1 --version) > /dev/null 2>&1; then
|
||||
# We have it, but it failed.
|
||||
exit 1
|
||||
elif test "x$2" = "x--version" || test "x$2" = "x--help"; then
|
||||
# Could not run --version or --help. This is probably someone
|
||||
# running `$TOOL --version' or `$TOOL --help' to check whether
|
||||
# $TOOL exists and not knowing $TOOL uses missing.
|
||||
exit 1
|
||||
fi
|
||||
;;
|
||||
esac
|
||||
|
||||
# If it does not exist, or fails to run (possibly an outdated version),
|
||||
# try to emulate it.
|
||||
case $program in
|
||||
aclocal*)
|
||||
echo 1>&2 "\
|
||||
WARNING: \`$1' is $msg. You should only need it if
|
||||
you modified \`acinclude.m4' or \`${configure_ac}'. You might want
|
||||
to install the \`Automake' and \`Perl' packages. Grab them from
|
||||
any GNU archive site."
|
||||
touch aclocal.m4
|
||||
;;
|
||||
|
||||
autoconf*)
|
||||
echo 1>&2 "\
|
||||
WARNING: \`$1' is $msg. You should only need it if
|
||||
you modified \`${configure_ac}'. You might want to install the
|
||||
\`Autoconf' and \`GNU m4' packages. Grab them from any GNU
|
||||
archive site."
|
||||
touch configure
|
||||
;;
|
||||
|
||||
autoheader*)
|
||||
echo 1>&2 "\
|
||||
WARNING: \`$1' is $msg. You should only need it if
|
||||
you modified \`acconfig.h' or \`${configure_ac}'. You might want
|
||||
to install the \`Autoconf' and \`GNU m4' packages. Grab them
|
||||
from any GNU archive site."
|
||||
files=`sed -n 's/^[ ]*A[CM]_CONFIG_HEADER(\([^)]*\)).*/\1/p' ${configure_ac}`
|
||||
test -z "$files" && files="config.h"
|
||||
touch_files=
|
||||
for f in $files; do
|
||||
case $f in
|
||||
*:*) touch_files="$touch_files "`echo "$f" |
|
||||
sed -e 's/^[^:]*://' -e 's/:.*//'`;;
|
||||
*) touch_files="$touch_files $f.in";;
|
||||
esac
|
||||
done
|
||||
touch $touch_files
|
||||
;;
|
||||
|
||||
automake*)
|
||||
echo 1>&2 "\
|
||||
WARNING: \`$1' is $msg. You should only need it if
|
||||
you modified \`Makefile.am', \`acinclude.m4' or \`${configure_ac}'.
|
||||
You might want to install the \`Automake' and \`Perl' packages.
|
||||
Grab them from any GNU archive site."
|
||||
find . -type f -name Makefile.am -print |
|
||||
sed 's/\.am$/.in/' |
|
||||
while read f; do touch "$f"; done
|
||||
;;
|
||||
|
||||
autom4te*)
|
||||
echo 1>&2 "\
|
||||
WARNING: \`$1' is needed, but is $msg.
|
||||
You might have modified some files without having the
|
||||
proper tools for further handling them.
|
||||
You can get \`$1' as part of \`Autoconf' from any GNU
|
||||
archive site."
|
||||
|
||||
file=`echo "$*" | sed -n "$sed_output"`
|
||||
test -z "$file" && file=`echo "$*" | sed -n "$sed_minuso"`
|
||||
if test -f "$file"; then
|
||||
touch $file
|
||||
else
|
||||
test -z "$file" || exec >$file
|
||||
echo "#! /bin/sh"
|
||||
echo "# Created by GNU Automake missing as a replacement of"
|
||||
echo "# $ $@"
|
||||
echo "exit 0"
|
||||
chmod +x $file
|
||||
exit 1
|
||||
fi
|
||||
;;
|
||||
|
||||
bison*|yacc*)
|
||||
echo 1>&2 "\
|
||||
WARNING: \`$1' $msg. You should only need it if
|
||||
you modified a \`.y' file. You may need the \`Bison' package
|
||||
in order for those modifications to take effect. You can get
|
||||
\`Bison' from any GNU archive site."
|
||||
rm -f y.tab.c y.tab.h
|
||||
if test $# -ne 1; then
|
||||
eval LASTARG=\${$#}
|
||||
case $LASTARG in
|
||||
*.y)
|
||||
SRCFILE=`echo "$LASTARG" | sed 's/y$/c/'`
|
||||
if test -f "$SRCFILE"; then
|
||||
cp "$SRCFILE" y.tab.c
|
||||
fi
|
||||
SRCFILE=`echo "$LASTARG" | sed 's/y$/h/'`
|
||||
if test -f "$SRCFILE"; then
|
||||
cp "$SRCFILE" y.tab.h
|
||||
fi
|
||||
;;
|
||||
esac
|
||||
fi
|
||||
if test ! -f y.tab.h; then
|
||||
echo >y.tab.h
|
||||
fi
|
||||
if test ! -f y.tab.c; then
|
||||
echo 'main() { return 0; }' >y.tab.c
|
||||
fi
|
||||
;;
|
||||
|
||||
lex*|flex*)
|
||||
echo 1>&2 "\
|
||||
WARNING: \`$1' is $msg. You should only need it if
|
||||
you modified a \`.l' file. You may need the \`Flex' package
|
||||
in order for those modifications to take effect. You can get
|
||||
\`Flex' from any GNU archive site."
|
||||
rm -f lex.yy.c
|
||||
if test $# -ne 1; then
|
||||
eval LASTARG=\${$#}
|
||||
case $LASTARG in
|
||||
*.l)
|
||||
SRCFILE=`echo "$LASTARG" | sed 's/l$/c/'`
|
||||
if test -f "$SRCFILE"; then
|
||||
cp "$SRCFILE" lex.yy.c
|
||||
fi
|
||||
;;
|
||||
esac
|
||||
fi
|
||||
if test ! -f lex.yy.c; then
|
||||
echo 'main() { return 0; }' >lex.yy.c
|
||||
fi
|
||||
;;
|
||||
|
||||
help2man*)
|
||||
echo 1>&2 "\
|
||||
WARNING: \`$1' is $msg. You should only need it if
|
||||
you modified a dependency of a manual page. You may need the
|
||||
\`Help2man' package in order for those modifications to take
|
||||
effect. You can get \`Help2man' from any GNU archive site."
|
||||
|
||||
file=`echo "$*" | sed -n "$sed_output"`
|
||||
test -z "$file" && file=`echo "$*" | sed -n "$sed_minuso"`
|
||||
if test -f "$file"; then
|
||||
touch $file
|
||||
else
|
||||
test -z "$file" || exec >$file
|
||||
echo ".ab help2man is required to generate this page"
|
||||
exit $?
|
||||
fi
|
||||
;;
|
||||
|
||||
makeinfo*)
|
||||
echo 1>&2 "\
|
||||
WARNING: \`$1' is $msg. You should only need it if
|
||||
you modified a \`.texi' or \`.texinfo' file, or any other file
|
||||
indirectly affecting the aspect of the manual. The spurious
|
||||
call might also be the consequence of using a buggy \`make' (AIX,
|
||||
DU, IRIX). You might want to install the \`Texinfo' package or
|
||||
the \`GNU make' package. Grab either from any GNU archive site."
|
||||
# The file to touch is that specified with -o ...
|
||||
file=`echo "$*" | sed -n "$sed_output"`
|
||||
test -z "$file" && file=`echo "$*" | sed -n "$sed_minuso"`
|
||||
if test -z "$file"; then
|
||||
# ... or it is the one specified with @setfilename ...
|
||||
infile=`echo "$*" | sed 's/.* \([^ ]*\) *$/\1/'`
|
||||
file=`sed -n '
|
||||
/^@setfilename/{
|
||||
s/.* \([^ ]*\) *$/\1/
|
||||
p
|
||||
q
|
||||
}' $infile`
|
||||
# ... or it is derived from the source name (dir/f.texi becomes f.info)
|
||||
test -z "$file" && file=`echo "$infile" | sed 's,.*/,,;s,.[^.]*$,,'`.info
|
||||
fi
|
||||
# If the file does not exist, the user really needs makeinfo;
|
||||
# let's fail without touching anything.
|
||||
test -f $file || exit 1
|
||||
touch $file
|
||||
;;
|
||||
|
||||
*)
|
||||
echo 1>&2 "\
|
||||
WARNING: \`$1' is needed, and is $msg.
|
||||
You might have modified some files without having the
|
||||
proper tools for further handling them. Check the \`README' file,
|
||||
it often tells you about the needed prerequisites for installing
|
||||
this package. You may also peek at any GNU archive site, in case
|
||||
some other package would contain this missing \`$1' program."
|
||||
exit 1
|
||||
;;
|
||||
esac
|
||||
|
||||
exit 0
|
||||
|
||||
# Local variables:
|
||||
# eval: (add-hook 'write-file-hooks 'time-stamp)
|
||||
# time-stamp-start: "scriptversion="
|
||||
# time-stamp-format: "%:y-%02m-%02d.%02H"
|
||||
# time-stamp-time-zone: "UTC"
|
||||
# time-stamp-end: "; # UTC"
|
||||
# End:
|
||||
18222
test/gmock-1.7.0/gtest/configure
vendored
18222
test/gmock-1.7.0/gtest/configure
vendored
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
8001
test/gmock-1.7.0/gtest/m4/libtool.m4
vendored
8001
test/gmock-1.7.0/gtest/m4/libtool.m4
vendored
File diff suppressed because it is too large
Load Diff
384
test/gmock-1.7.0/gtest/m4/ltoptions.m4
vendored
384
test/gmock-1.7.0/gtest/m4/ltoptions.m4
vendored
@@ -1,384 +0,0 @@
|
||||
# Helper functions for option handling. -*- Autoconf -*-
|
||||
#
|
||||
# Copyright (C) 2004, 2005, 2007, 2008, 2009 Free Software Foundation,
|
||||
# Inc.
|
||||
# Written by Gary V. Vaughan, 2004
|
||||
#
|
||||
# This file is free software; the Free Software Foundation gives
|
||||
# unlimited permission to copy and/or distribute it, with or without
|
||||
# modifications, as long as this notice is preserved.
|
||||
|
||||
# serial 7 ltoptions.m4
|
||||
|
||||
# This is to help aclocal find these macros, as it can't see m4_define.
|
||||
AC_DEFUN([LTOPTIONS_VERSION], [m4_if([1])])
|
||||
|
||||
|
||||
# _LT_MANGLE_OPTION(MACRO-NAME, OPTION-NAME)
|
||||
# ------------------------------------------
|
||||
m4_define([_LT_MANGLE_OPTION],
|
||||
[[_LT_OPTION_]m4_bpatsubst($1__$2, [[^a-zA-Z0-9_]], [_])])
|
||||
|
||||
|
||||
# _LT_SET_OPTION(MACRO-NAME, OPTION-NAME)
|
||||
# ---------------------------------------
|
||||
# Set option OPTION-NAME for macro MACRO-NAME, and if there is a
|
||||
# matching handler defined, dispatch to it. Other OPTION-NAMEs are
|
||||
# saved as a flag.
|
||||
m4_define([_LT_SET_OPTION],
|
||||
[m4_define(_LT_MANGLE_OPTION([$1], [$2]))dnl
|
||||
m4_ifdef(_LT_MANGLE_DEFUN([$1], [$2]),
|
||||
_LT_MANGLE_DEFUN([$1], [$2]),
|
||||
[m4_warning([Unknown $1 option `$2'])])[]dnl
|
||||
])
|
||||
|
||||
|
||||
# _LT_IF_OPTION(MACRO-NAME, OPTION-NAME, IF-SET, [IF-NOT-SET])
|
||||
# ------------------------------------------------------------
|
||||
# Execute IF-SET if OPTION is set, IF-NOT-SET otherwise.
|
||||
m4_define([_LT_IF_OPTION],
|
||||
[m4_ifdef(_LT_MANGLE_OPTION([$1], [$2]), [$3], [$4])])
|
||||
|
||||
|
||||
# _LT_UNLESS_OPTIONS(MACRO-NAME, OPTION-LIST, IF-NOT-SET)
|
||||
# -------------------------------------------------------
|
||||
# Execute IF-NOT-SET unless all options in OPTION-LIST for MACRO-NAME
|
||||
# are set.
|
||||
m4_define([_LT_UNLESS_OPTIONS],
|
||||
[m4_foreach([_LT_Option], m4_split(m4_normalize([$2])),
|
||||
[m4_ifdef(_LT_MANGLE_OPTION([$1], _LT_Option),
|
||||
[m4_define([$0_found])])])[]dnl
|
||||
m4_ifdef([$0_found], [m4_undefine([$0_found])], [$3
|
||||
])[]dnl
|
||||
])
|
||||
|
||||
|
||||
# _LT_SET_OPTIONS(MACRO-NAME, OPTION-LIST)
|
||||
# ----------------------------------------
|
||||
# OPTION-LIST is a space-separated list of Libtool options associated
|
||||
# with MACRO-NAME. If any OPTION has a matching handler declared with
|
||||
# LT_OPTION_DEFINE, dispatch to that macro; otherwise complain about
|
||||
# the unknown option and exit.
|
||||
m4_defun([_LT_SET_OPTIONS],
|
||||
[# Set options
|
||||
m4_foreach([_LT_Option], m4_split(m4_normalize([$2])),
|
||||
[_LT_SET_OPTION([$1], _LT_Option)])
|
||||
|
||||
m4_if([$1],[LT_INIT],[
|
||||
dnl
|
||||
dnl Simply set some default values (i.e off) if boolean options were not
|
||||
dnl specified:
|
||||
_LT_UNLESS_OPTIONS([LT_INIT], [dlopen], [enable_dlopen=no
|
||||
])
|
||||
_LT_UNLESS_OPTIONS([LT_INIT], [win32-dll], [enable_win32_dll=no
|
||||
])
|
||||
dnl
|
||||
dnl If no reference was made to various pairs of opposing options, then
|
||||
dnl we run the default mode handler for the pair. For example, if neither
|
||||
dnl `shared' nor `disable-shared' was passed, we enable building of shared
|
||||
dnl archives by default:
|
||||
_LT_UNLESS_OPTIONS([LT_INIT], [shared disable-shared], [_LT_ENABLE_SHARED])
|
||||
_LT_UNLESS_OPTIONS([LT_INIT], [static disable-static], [_LT_ENABLE_STATIC])
|
||||
_LT_UNLESS_OPTIONS([LT_INIT], [pic-only no-pic], [_LT_WITH_PIC])
|
||||
_LT_UNLESS_OPTIONS([LT_INIT], [fast-install disable-fast-install],
|
||||
[_LT_ENABLE_FAST_INSTALL])
|
||||
])
|
||||
])# _LT_SET_OPTIONS
|
||||
|
||||
|
||||
## --------------------------------- ##
|
||||
## Macros to handle LT_INIT options. ##
|
||||
## --------------------------------- ##
|
||||
|
||||
# _LT_MANGLE_DEFUN(MACRO-NAME, OPTION-NAME)
|
||||
# -----------------------------------------
|
||||
m4_define([_LT_MANGLE_DEFUN],
|
||||
[[_LT_OPTION_DEFUN_]m4_bpatsubst(m4_toupper([$1__$2]), [[^A-Z0-9_]], [_])])
|
||||
|
||||
|
||||
# LT_OPTION_DEFINE(MACRO-NAME, OPTION-NAME, CODE)
|
||||
# -----------------------------------------------
|
||||
m4_define([LT_OPTION_DEFINE],
|
||||
[m4_define(_LT_MANGLE_DEFUN([$1], [$2]), [$3])[]dnl
|
||||
])# LT_OPTION_DEFINE
|
||||
|
||||
|
||||
# dlopen
|
||||
# ------
|
||||
LT_OPTION_DEFINE([LT_INIT], [dlopen], [enable_dlopen=yes
|
||||
])
|
||||
|
||||
AU_DEFUN([AC_LIBTOOL_DLOPEN],
|
||||
[_LT_SET_OPTION([LT_INIT], [dlopen])
|
||||
AC_DIAGNOSE([obsolete],
|
||||
[$0: Remove this warning and the call to _LT_SET_OPTION when you
|
||||
put the `dlopen' option into LT_INIT's first parameter.])
|
||||
])
|
||||
|
||||
dnl aclocal-1.4 backwards compatibility:
|
||||
dnl AC_DEFUN([AC_LIBTOOL_DLOPEN], [])
|
||||
|
||||
|
||||
# win32-dll
|
||||
# ---------
|
||||
# Declare package support for building win32 dll's.
|
||||
LT_OPTION_DEFINE([LT_INIT], [win32-dll],
|
||||
[enable_win32_dll=yes
|
||||
|
||||
case $host in
|
||||
*-*-cygwin* | *-*-mingw* | *-*-pw32* | *-*-cegcc*)
|
||||
AC_CHECK_TOOL(AS, as, false)
|
||||
AC_CHECK_TOOL(DLLTOOL, dlltool, false)
|
||||
AC_CHECK_TOOL(OBJDUMP, objdump, false)
|
||||
;;
|
||||
esac
|
||||
|
||||
test -z "$AS" && AS=as
|
||||
_LT_DECL([], [AS], [1], [Assembler program])dnl
|
||||
|
||||
test -z "$DLLTOOL" && DLLTOOL=dlltool
|
||||
_LT_DECL([], [DLLTOOL], [1], [DLL creation program])dnl
|
||||
|
||||
test -z "$OBJDUMP" && OBJDUMP=objdump
|
||||
_LT_DECL([], [OBJDUMP], [1], [Object dumper program])dnl
|
||||
])# win32-dll
|
||||
|
||||
AU_DEFUN([AC_LIBTOOL_WIN32_DLL],
|
||||
[AC_REQUIRE([AC_CANONICAL_HOST])dnl
|
||||
_LT_SET_OPTION([LT_INIT], [win32-dll])
|
||||
AC_DIAGNOSE([obsolete],
|
||||
[$0: Remove this warning and the call to _LT_SET_OPTION when you
|
||||
put the `win32-dll' option into LT_INIT's first parameter.])
|
||||
])
|
||||
|
||||
dnl aclocal-1.4 backwards compatibility:
|
||||
dnl AC_DEFUN([AC_LIBTOOL_WIN32_DLL], [])
|
||||
|
||||
|
||||
# _LT_ENABLE_SHARED([DEFAULT])
|
||||
# ----------------------------
|
||||
# implement the --enable-shared flag, and supports the `shared' and
|
||||
# `disable-shared' LT_INIT options.
|
||||
# DEFAULT is either `yes' or `no'. If omitted, it defaults to `yes'.
|
||||
m4_define([_LT_ENABLE_SHARED],
|
||||
[m4_define([_LT_ENABLE_SHARED_DEFAULT], [m4_if($1, no, no, yes)])dnl
|
||||
AC_ARG_ENABLE([shared],
|
||||
[AS_HELP_STRING([--enable-shared@<:@=PKGS@:>@],
|
||||
[build shared libraries @<:@default=]_LT_ENABLE_SHARED_DEFAULT[@:>@])],
|
||||
[p=${PACKAGE-default}
|
||||
case $enableval in
|
||||
yes) enable_shared=yes ;;
|
||||
no) enable_shared=no ;;
|
||||
*)
|
||||
enable_shared=no
|
||||
# Look at the argument we got. We use all the common list separators.
|
||||
lt_save_ifs="$IFS"; IFS="${IFS}$PATH_SEPARATOR,"
|
||||
for pkg in $enableval; do
|
||||
IFS="$lt_save_ifs"
|
||||
if test "X$pkg" = "X$p"; then
|
||||
enable_shared=yes
|
||||
fi
|
||||
done
|
||||
IFS="$lt_save_ifs"
|
||||
;;
|
||||
esac],
|
||||
[enable_shared=]_LT_ENABLE_SHARED_DEFAULT)
|
||||
|
||||
_LT_DECL([build_libtool_libs], [enable_shared], [0],
|
||||
[Whether or not to build shared libraries])
|
||||
])# _LT_ENABLE_SHARED
|
||||
|
||||
LT_OPTION_DEFINE([LT_INIT], [shared], [_LT_ENABLE_SHARED([yes])])
|
||||
LT_OPTION_DEFINE([LT_INIT], [disable-shared], [_LT_ENABLE_SHARED([no])])
|
||||
|
||||
# Old names:
|
||||
AC_DEFUN([AC_ENABLE_SHARED],
|
||||
[_LT_SET_OPTION([LT_INIT], m4_if([$1], [no], [disable-])[shared])
|
||||
])
|
||||
|
||||
AC_DEFUN([AC_DISABLE_SHARED],
|
||||
[_LT_SET_OPTION([LT_INIT], [disable-shared])
|
||||
])
|
||||
|
||||
AU_DEFUN([AM_ENABLE_SHARED], [AC_ENABLE_SHARED($@)])
|
||||
AU_DEFUN([AM_DISABLE_SHARED], [AC_DISABLE_SHARED($@)])
|
||||
|
||||
dnl aclocal-1.4 backwards compatibility:
|
||||
dnl AC_DEFUN([AM_ENABLE_SHARED], [])
|
||||
dnl AC_DEFUN([AM_DISABLE_SHARED], [])
|
||||
|
||||
|
||||
|
||||
# _LT_ENABLE_STATIC([DEFAULT])
|
||||
# ----------------------------
|
||||
# implement the --enable-static flag, and support the `static' and
|
||||
# `disable-static' LT_INIT options.
|
||||
# DEFAULT is either `yes' or `no'. If omitted, it defaults to `yes'.
|
||||
m4_define([_LT_ENABLE_STATIC],
|
||||
[m4_define([_LT_ENABLE_STATIC_DEFAULT], [m4_if($1, no, no, yes)])dnl
|
||||
AC_ARG_ENABLE([static],
|
||||
[AS_HELP_STRING([--enable-static@<:@=PKGS@:>@],
|
||||
[build static libraries @<:@default=]_LT_ENABLE_STATIC_DEFAULT[@:>@])],
|
||||
[p=${PACKAGE-default}
|
||||
case $enableval in
|
||||
yes) enable_static=yes ;;
|
||||
no) enable_static=no ;;
|
||||
*)
|
||||
enable_static=no
|
||||
# Look at the argument we got. We use all the common list separators.
|
||||
lt_save_ifs="$IFS"; IFS="${IFS}$PATH_SEPARATOR,"
|
||||
for pkg in $enableval; do
|
||||
IFS="$lt_save_ifs"
|
||||
if test "X$pkg" = "X$p"; then
|
||||
enable_static=yes
|
||||
fi
|
||||
done
|
||||
IFS="$lt_save_ifs"
|
||||
;;
|
||||
esac],
|
||||
[enable_static=]_LT_ENABLE_STATIC_DEFAULT)
|
||||
|
||||
_LT_DECL([build_old_libs], [enable_static], [0],
|
||||
[Whether or not to build static libraries])
|
||||
])# _LT_ENABLE_STATIC
|
||||
|
||||
LT_OPTION_DEFINE([LT_INIT], [static], [_LT_ENABLE_STATIC([yes])])
|
||||
LT_OPTION_DEFINE([LT_INIT], [disable-static], [_LT_ENABLE_STATIC([no])])
|
||||
|
||||
# Old names:
|
||||
AC_DEFUN([AC_ENABLE_STATIC],
|
||||
[_LT_SET_OPTION([LT_INIT], m4_if([$1], [no], [disable-])[static])
|
||||
])
|
||||
|
||||
AC_DEFUN([AC_DISABLE_STATIC],
|
||||
[_LT_SET_OPTION([LT_INIT], [disable-static])
|
||||
])
|
||||
|
||||
AU_DEFUN([AM_ENABLE_STATIC], [AC_ENABLE_STATIC($@)])
|
||||
AU_DEFUN([AM_DISABLE_STATIC], [AC_DISABLE_STATIC($@)])
|
||||
|
||||
dnl aclocal-1.4 backwards compatibility:
|
||||
dnl AC_DEFUN([AM_ENABLE_STATIC], [])
|
||||
dnl AC_DEFUN([AM_DISABLE_STATIC], [])
|
||||
|
||||
|
||||
|
||||
# _LT_ENABLE_FAST_INSTALL([DEFAULT])
|
||||
# ----------------------------------
|
||||
# implement the --enable-fast-install flag, and support the `fast-install'
|
||||
# and `disable-fast-install' LT_INIT options.
|
||||
# DEFAULT is either `yes' or `no'. If omitted, it defaults to `yes'.
|
||||
m4_define([_LT_ENABLE_FAST_INSTALL],
|
||||
[m4_define([_LT_ENABLE_FAST_INSTALL_DEFAULT], [m4_if($1, no, no, yes)])dnl
|
||||
AC_ARG_ENABLE([fast-install],
|
||||
[AS_HELP_STRING([--enable-fast-install@<:@=PKGS@:>@],
|
||||
[optimize for fast installation @<:@default=]_LT_ENABLE_FAST_INSTALL_DEFAULT[@:>@])],
|
||||
[p=${PACKAGE-default}
|
||||
case $enableval in
|
||||
yes) enable_fast_install=yes ;;
|
||||
no) enable_fast_install=no ;;
|
||||
*)
|
||||
enable_fast_install=no
|
||||
# Look at the argument we got. We use all the common list separators.
|
||||
lt_save_ifs="$IFS"; IFS="${IFS}$PATH_SEPARATOR,"
|
||||
for pkg in $enableval; do
|
||||
IFS="$lt_save_ifs"
|
||||
if test "X$pkg" = "X$p"; then
|
||||
enable_fast_install=yes
|
||||
fi
|
||||
done
|
||||
IFS="$lt_save_ifs"
|
||||
;;
|
||||
esac],
|
||||
[enable_fast_install=]_LT_ENABLE_FAST_INSTALL_DEFAULT)
|
||||
|
||||
_LT_DECL([fast_install], [enable_fast_install], [0],
|
||||
[Whether or not to optimize for fast installation])dnl
|
||||
])# _LT_ENABLE_FAST_INSTALL
|
||||
|
||||
LT_OPTION_DEFINE([LT_INIT], [fast-install], [_LT_ENABLE_FAST_INSTALL([yes])])
|
||||
LT_OPTION_DEFINE([LT_INIT], [disable-fast-install], [_LT_ENABLE_FAST_INSTALL([no])])
|
||||
|
||||
# Old names:
|
||||
AU_DEFUN([AC_ENABLE_FAST_INSTALL],
|
||||
[_LT_SET_OPTION([LT_INIT], m4_if([$1], [no], [disable-])[fast-install])
|
||||
AC_DIAGNOSE([obsolete],
|
||||
[$0: Remove this warning and the call to _LT_SET_OPTION when you put
|
||||
the `fast-install' option into LT_INIT's first parameter.])
|
||||
])
|
||||
|
||||
AU_DEFUN([AC_DISABLE_FAST_INSTALL],
|
||||
[_LT_SET_OPTION([LT_INIT], [disable-fast-install])
|
||||
AC_DIAGNOSE([obsolete],
|
||||
[$0: Remove this warning and the call to _LT_SET_OPTION when you put
|
||||
the `disable-fast-install' option into LT_INIT's first parameter.])
|
||||
])
|
||||
|
||||
dnl aclocal-1.4 backwards compatibility:
|
||||
dnl AC_DEFUN([AC_ENABLE_FAST_INSTALL], [])
|
||||
dnl AC_DEFUN([AM_DISABLE_FAST_INSTALL], [])
|
||||
|
||||
|
||||
# _LT_WITH_PIC([MODE])
|
||||
# --------------------
|
||||
# implement the --with-pic flag, and support the `pic-only' and `no-pic'
|
||||
# LT_INIT options.
|
||||
# MODE is either `yes' or `no'. If omitted, it defaults to `both'.
|
||||
m4_define([_LT_WITH_PIC],
|
||||
[AC_ARG_WITH([pic],
|
||||
[AS_HELP_STRING([--with-pic@<:@=PKGS@:>@],
|
||||
[try to use only PIC/non-PIC objects @<:@default=use both@:>@])],
|
||||
[lt_p=${PACKAGE-default}
|
||||
case $withval in
|
||||
yes|no) pic_mode=$withval ;;
|
||||
*)
|
||||
pic_mode=default
|
||||
# Look at the argument we got. We use all the common list separators.
|
||||
lt_save_ifs="$IFS"; IFS="${IFS}$PATH_SEPARATOR,"
|
||||
for lt_pkg in $withval; do
|
||||
IFS="$lt_save_ifs"
|
||||
if test "X$lt_pkg" = "X$lt_p"; then
|
||||
pic_mode=yes
|
||||
fi
|
||||
done
|
||||
IFS="$lt_save_ifs"
|
||||
;;
|
||||
esac],
|
||||
[pic_mode=default])
|
||||
|
||||
test -z "$pic_mode" && pic_mode=m4_default([$1], [default])
|
||||
|
||||
_LT_DECL([], [pic_mode], [0], [What type of objects to build])dnl
|
||||
])# _LT_WITH_PIC
|
||||
|
||||
LT_OPTION_DEFINE([LT_INIT], [pic-only], [_LT_WITH_PIC([yes])])
|
||||
LT_OPTION_DEFINE([LT_INIT], [no-pic], [_LT_WITH_PIC([no])])
|
||||
|
||||
# Old name:
|
||||
AU_DEFUN([AC_LIBTOOL_PICMODE],
|
||||
[_LT_SET_OPTION([LT_INIT], [pic-only])
|
||||
AC_DIAGNOSE([obsolete],
|
||||
[$0: Remove this warning and the call to _LT_SET_OPTION when you
|
||||
put the `pic-only' option into LT_INIT's first parameter.])
|
||||
])
|
||||
|
||||
dnl aclocal-1.4 backwards compatibility:
|
||||
dnl AC_DEFUN([AC_LIBTOOL_PICMODE], [])
|
||||
|
||||
## ----------------- ##
|
||||
## LTDL_INIT Options ##
|
||||
## ----------------- ##
|
||||
|
||||
m4_define([_LTDL_MODE], [])
|
||||
LT_OPTION_DEFINE([LTDL_INIT], [nonrecursive],
|
||||
[m4_define([_LTDL_MODE], [nonrecursive])])
|
||||
LT_OPTION_DEFINE([LTDL_INIT], [recursive],
|
||||
[m4_define([_LTDL_MODE], [recursive])])
|
||||
LT_OPTION_DEFINE([LTDL_INIT], [subproject],
|
||||
[m4_define([_LTDL_MODE], [subproject])])
|
||||
|
||||
m4_define([_LTDL_TYPE], [])
|
||||
LT_OPTION_DEFINE([LTDL_INIT], [installable],
|
||||
[m4_define([_LTDL_TYPE], [installable])])
|
||||
LT_OPTION_DEFINE([LTDL_INIT], [convenience],
|
||||
[m4_define([_LTDL_TYPE], [convenience])])
|
||||
123
test/gmock-1.7.0/gtest/m4/ltsugar.m4
vendored
123
test/gmock-1.7.0/gtest/m4/ltsugar.m4
vendored
@@ -1,123 +0,0 @@
|
||||
# ltsugar.m4 -- libtool m4 base layer. -*-Autoconf-*-
|
||||
#
|
||||
# Copyright (C) 2004, 2005, 2007, 2008 Free Software Foundation, Inc.
|
||||
# Written by Gary V. Vaughan, 2004
|
||||
#
|
||||
# This file is free software; the Free Software Foundation gives
|
||||
# unlimited permission to copy and/or distribute it, with or without
|
||||
# modifications, as long as this notice is preserved.
|
||||
|
||||
# serial 6 ltsugar.m4
|
||||
|
||||
# This is to help aclocal find these macros, as it can't see m4_define.
|
||||
AC_DEFUN([LTSUGAR_VERSION], [m4_if([0.1])])
|
||||
|
||||
|
||||
# lt_join(SEP, ARG1, [ARG2...])
|
||||
# -----------------------------
|
||||
# Produce ARG1SEPARG2...SEPARGn, omitting [] arguments and their
|
||||
# associated separator.
|
||||
# Needed until we can rely on m4_join from Autoconf 2.62, since all earlier
|
||||
# versions in m4sugar had bugs.
|
||||
m4_define([lt_join],
|
||||
[m4_if([$#], [1], [],
|
||||
[$#], [2], [[$2]],
|
||||
[m4_if([$2], [], [], [[$2]_])$0([$1], m4_shift(m4_shift($@)))])])
|
||||
m4_define([_lt_join],
|
||||
[m4_if([$#$2], [2], [],
|
||||
[m4_if([$2], [], [], [[$1$2]])$0([$1], m4_shift(m4_shift($@)))])])
|
||||
|
||||
|
||||
# lt_car(LIST)
|
||||
# lt_cdr(LIST)
|
||||
# ------------
|
||||
# Manipulate m4 lists.
|
||||
# These macros are necessary as long as will still need to support
|
||||
# Autoconf-2.59 which quotes differently.
|
||||
m4_define([lt_car], [[$1]])
|
||||
m4_define([lt_cdr],
|
||||
[m4_if([$#], 0, [m4_fatal([$0: cannot be called without arguments])],
|
||||
[$#], 1, [],
|
||||
[m4_dquote(m4_shift($@))])])
|
||||
m4_define([lt_unquote], $1)
|
||||
|
||||
|
||||
# lt_append(MACRO-NAME, STRING, [SEPARATOR])
|
||||
# ------------------------------------------
|
||||
# Redefine MACRO-NAME to hold its former content plus `SEPARATOR'`STRING'.
|
||||
# Note that neither SEPARATOR nor STRING are expanded; they are appended
|
||||
# to MACRO-NAME as is (leaving the expansion for when MACRO-NAME is invoked).
|
||||
# No SEPARATOR is output if MACRO-NAME was previously undefined (different
|
||||
# than defined and empty).
|
||||
#
|
||||
# This macro is needed until we can rely on Autoconf 2.62, since earlier
|
||||
# versions of m4sugar mistakenly expanded SEPARATOR but not STRING.
|
||||
m4_define([lt_append],
|
||||
[m4_define([$1],
|
||||
m4_ifdef([$1], [m4_defn([$1])[$3]])[$2])])
|
||||
|
||||
|
||||
|
||||
# lt_combine(SEP, PREFIX-LIST, INFIX, SUFFIX1, [SUFFIX2...])
|
||||
# ----------------------------------------------------------
|
||||
# Produce a SEP delimited list of all paired combinations of elements of
|
||||
# PREFIX-LIST with SUFFIX1 through SUFFIXn. Each element of the list
|
||||
# has the form PREFIXmINFIXSUFFIXn.
|
||||
# Needed until we can rely on m4_combine added in Autoconf 2.62.
|
||||
m4_define([lt_combine],
|
||||
[m4_if(m4_eval([$# > 3]), [1],
|
||||
[m4_pushdef([_Lt_sep], [m4_define([_Lt_sep], m4_defn([lt_car]))])]]dnl
|
||||
[[m4_foreach([_Lt_prefix], [$2],
|
||||
[m4_foreach([_Lt_suffix],
|
||||
]m4_dquote(m4_dquote(m4_shift(m4_shift(m4_shift($@)))))[,
|
||||
[_Lt_sep([$1])[]m4_defn([_Lt_prefix])[$3]m4_defn([_Lt_suffix])])])])])
|
||||
|
||||
|
||||
# lt_if_append_uniq(MACRO-NAME, VARNAME, [SEPARATOR], [UNIQ], [NOT-UNIQ])
|
||||
# -----------------------------------------------------------------------
|
||||
# Iff MACRO-NAME does not yet contain VARNAME, then append it (delimited
|
||||
# by SEPARATOR if supplied) and expand UNIQ, else NOT-UNIQ.
|
||||
m4_define([lt_if_append_uniq],
|
||||
[m4_ifdef([$1],
|
||||
[m4_if(m4_index([$3]m4_defn([$1])[$3], [$3$2$3]), [-1],
|
||||
[lt_append([$1], [$2], [$3])$4],
|
||||
[$5])],
|
||||
[lt_append([$1], [$2], [$3])$4])])
|
||||
|
||||
|
||||
# lt_dict_add(DICT, KEY, VALUE)
|
||||
# -----------------------------
|
||||
m4_define([lt_dict_add],
|
||||
[m4_define([$1($2)], [$3])])
|
||||
|
||||
|
||||
# lt_dict_add_subkey(DICT, KEY, SUBKEY, VALUE)
|
||||
# --------------------------------------------
|
||||
m4_define([lt_dict_add_subkey],
|
||||
[m4_define([$1($2:$3)], [$4])])
|
||||
|
||||
|
||||
# lt_dict_fetch(DICT, KEY, [SUBKEY])
|
||||
# ----------------------------------
|
||||
m4_define([lt_dict_fetch],
|
||||
[m4_ifval([$3],
|
||||
m4_ifdef([$1($2:$3)], [m4_defn([$1($2:$3)])]),
|
||||
m4_ifdef([$1($2)], [m4_defn([$1($2)])]))])
|
||||
|
||||
|
||||
# lt_if_dict_fetch(DICT, KEY, [SUBKEY], VALUE, IF-TRUE, [IF-FALSE])
|
||||
# -----------------------------------------------------------------
|
||||
m4_define([lt_if_dict_fetch],
|
||||
[m4_if(lt_dict_fetch([$1], [$2], [$3]), [$4],
|
||||
[$5],
|
||||
[$6])])
|
||||
|
||||
|
||||
# lt_dict_filter(DICT, [SUBKEY], VALUE, [SEPARATOR], KEY, [...])
|
||||
# --------------------------------------------------------------
|
||||
m4_define([lt_dict_filter],
|
||||
[m4_if([$5], [], [],
|
||||
[lt_join(m4_quote(m4_default([$4], [[, ]])),
|
||||
lt_unquote(m4_split(m4_normalize(m4_foreach(_Lt_key, lt_car([m4_shiftn(4, $@)]),
|
||||
[lt_if_dict_fetch([$1], _Lt_key, [$2], [$3], [_Lt_key ])])))))])[]dnl
|
||||
])
|
||||
23
test/gmock-1.7.0/gtest/m4/ltversion.m4
vendored
23
test/gmock-1.7.0/gtest/m4/ltversion.m4
vendored
@@ -1,23 +0,0 @@
|
||||
# ltversion.m4 -- version numbers -*- Autoconf -*-
|
||||
#
|
||||
# Copyright (C) 2004 Free Software Foundation, Inc.
|
||||
# Written by Scott James Remnant, 2004
|
||||
#
|
||||
# This file is free software; the Free Software Foundation gives
|
||||
# unlimited permission to copy and/or distribute it, with or without
|
||||
# modifications, as long as this notice is preserved.
|
||||
|
||||
# @configure_input@
|
||||
|
||||
# serial 3337 ltversion.m4
|
||||
# This file is part of GNU Libtool
|
||||
|
||||
m4_define([LT_PACKAGE_VERSION], [2.4.2])
|
||||
m4_define([LT_PACKAGE_REVISION], [1.3337])
|
||||
|
||||
AC_DEFUN([LTVERSION_VERSION],
|
||||
[macro_version='2.4.2'
|
||||
macro_revision='1.3337'
|
||||
_LT_DECL(, macro_version, 0, [Which release of libtool.m4 was used?])
|
||||
_LT_DECL(, macro_revision, 0)
|
||||
])
|
||||
98
test/gmock-1.7.0/gtest/m4/lt~obsolete.m4
vendored
98
test/gmock-1.7.0/gtest/m4/lt~obsolete.m4
vendored
@@ -1,98 +0,0 @@
|
||||
# lt~obsolete.m4 -- aclocal satisfying obsolete definitions. -*-Autoconf-*-
|
||||
#
|
||||
# Copyright (C) 2004, 2005, 2007, 2009 Free Software Foundation, Inc.
|
||||
# Written by Scott James Remnant, 2004.
|
||||
#
|
||||
# This file is free software; the Free Software Foundation gives
|
||||
# unlimited permission to copy and/or distribute it, with or without
|
||||
# modifications, as long as this notice is preserved.
|
||||
|
||||
# serial 5 lt~obsolete.m4
|
||||
|
||||
# These exist entirely to fool aclocal when bootstrapping libtool.
|
||||
#
|
||||
# In the past libtool.m4 has provided macros via AC_DEFUN (or AU_DEFUN)
|
||||
# which have later been changed to m4_define as they aren't part of the
|
||||
# exported API, or moved to Autoconf or Automake where they belong.
|
||||
#
|
||||
# The trouble is, aclocal is a bit thick. It'll see the old AC_DEFUN
|
||||
# in /usr/share/aclocal/libtool.m4 and remember it, then when it sees us
|
||||
# using a macro with the same name in our local m4/libtool.m4 it'll
|
||||
# pull the old libtool.m4 in (it doesn't see our shiny new m4_define
|
||||
# and doesn't know about Autoconf macros at all.)
|
||||
#
|
||||
# So we provide this file, which has a silly filename so it's always
|
||||
# included after everything else. This provides aclocal with the
|
||||
# AC_DEFUNs it wants, but when m4 processes it, it doesn't do anything
|
||||
# because those macros already exist, or will be overwritten later.
|
||||
# We use AC_DEFUN over AU_DEFUN for compatibility with aclocal-1.6.
|
||||
#
|
||||
# Anytime we withdraw an AC_DEFUN or AU_DEFUN, remember to add it here.
|
||||
# Yes, that means every name once taken will need to remain here until
|
||||
# we give up compatibility with versions before 1.7, at which point
|
||||
# we need to keep only those names which we still refer to.
|
||||
|
||||
# This is to help aclocal find these macros, as it can't see m4_define.
|
||||
AC_DEFUN([LTOBSOLETE_VERSION], [m4_if([1])])
|
||||
|
||||
m4_ifndef([AC_LIBTOOL_LINKER_OPTION], [AC_DEFUN([AC_LIBTOOL_LINKER_OPTION])])
|
||||
m4_ifndef([AC_PROG_EGREP], [AC_DEFUN([AC_PROG_EGREP])])
|
||||
m4_ifndef([_LT_AC_PROG_ECHO_BACKSLASH], [AC_DEFUN([_LT_AC_PROG_ECHO_BACKSLASH])])
|
||||
m4_ifndef([_LT_AC_SHELL_INIT], [AC_DEFUN([_LT_AC_SHELL_INIT])])
|
||||
m4_ifndef([_LT_AC_SYS_LIBPATH_AIX], [AC_DEFUN([_LT_AC_SYS_LIBPATH_AIX])])
|
||||
m4_ifndef([_LT_PROG_LTMAIN], [AC_DEFUN([_LT_PROG_LTMAIN])])
|
||||
m4_ifndef([_LT_AC_TAGVAR], [AC_DEFUN([_LT_AC_TAGVAR])])
|
||||
m4_ifndef([AC_LTDL_ENABLE_INSTALL], [AC_DEFUN([AC_LTDL_ENABLE_INSTALL])])
|
||||
m4_ifndef([AC_LTDL_PREOPEN], [AC_DEFUN([AC_LTDL_PREOPEN])])
|
||||
m4_ifndef([_LT_AC_SYS_COMPILER], [AC_DEFUN([_LT_AC_SYS_COMPILER])])
|
||||
m4_ifndef([_LT_AC_LOCK], [AC_DEFUN([_LT_AC_LOCK])])
|
||||
m4_ifndef([AC_LIBTOOL_SYS_OLD_ARCHIVE], [AC_DEFUN([AC_LIBTOOL_SYS_OLD_ARCHIVE])])
|
||||
m4_ifndef([_LT_AC_TRY_DLOPEN_SELF], [AC_DEFUN([_LT_AC_TRY_DLOPEN_SELF])])
|
||||
m4_ifndef([AC_LIBTOOL_PROG_CC_C_O], [AC_DEFUN([AC_LIBTOOL_PROG_CC_C_O])])
|
||||
m4_ifndef([AC_LIBTOOL_SYS_HARD_LINK_LOCKS], [AC_DEFUN([AC_LIBTOOL_SYS_HARD_LINK_LOCKS])])
|
||||
m4_ifndef([AC_LIBTOOL_OBJDIR], [AC_DEFUN([AC_LIBTOOL_OBJDIR])])
|
||||
m4_ifndef([AC_LTDL_OBJDIR], [AC_DEFUN([AC_LTDL_OBJDIR])])
|
||||
m4_ifndef([AC_LIBTOOL_PROG_LD_HARDCODE_LIBPATH], [AC_DEFUN([AC_LIBTOOL_PROG_LD_HARDCODE_LIBPATH])])
|
||||
m4_ifndef([AC_LIBTOOL_SYS_LIB_STRIP], [AC_DEFUN([AC_LIBTOOL_SYS_LIB_STRIP])])
|
||||
m4_ifndef([AC_PATH_MAGIC], [AC_DEFUN([AC_PATH_MAGIC])])
|
||||
m4_ifndef([AC_PROG_LD_GNU], [AC_DEFUN([AC_PROG_LD_GNU])])
|
||||
m4_ifndef([AC_PROG_LD_RELOAD_FLAG], [AC_DEFUN([AC_PROG_LD_RELOAD_FLAG])])
|
||||
m4_ifndef([AC_DEPLIBS_CHECK_METHOD], [AC_DEFUN([AC_DEPLIBS_CHECK_METHOD])])
|
||||
m4_ifndef([AC_LIBTOOL_PROG_COMPILER_NO_RTTI], [AC_DEFUN([AC_LIBTOOL_PROG_COMPILER_NO_RTTI])])
|
||||
m4_ifndef([AC_LIBTOOL_SYS_GLOBAL_SYMBOL_PIPE], [AC_DEFUN([AC_LIBTOOL_SYS_GLOBAL_SYMBOL_PIPE])])
|
||||
m4_ifndef([AC_LIBTOOL_PROG_COMPILER_PIC], [AC_DEFUN([AC_LIBTOOL_PROG_COMPILER_PIC])])
|
||||
m4_ifndef([AC_LIBTOOL_PROG_LD_SHLIBS], [AC_DEFUN([AC_LIBTOOL_PROG_LD_SHLIBS])])
|
||||
m4_ifndef([AC_LIBTOOL_POSTDEP_PREDEP], [AC_DEFUN([AC_LIBTOOL_POSTDEP_PREDEP])])
|
||||
m4_ifndef([LT_AC_PROG_EGREP], [AC_DEFUN([LT_AC_PROG_EGREP])])
|
||||
m4_ifndef([LT_AC_PROG_SED], [AC_DEFUN([LT_AC_PROG_SED])])
|
||||
m4_ifndef([_LT_CC_BASENAME], [AC_DEFUN([_LT_CC_BASENAME])])
|
||||
m4_ifndef([_LT_COMPILER_BOILERPLATE], [AC_DEFUN([_LT_COMPILER_BOILERPLATE])])
|
||||
m4_ifndef([_LT_LINKER_BOILERPLATE], [AC_DEFUN([_LT_LINKER_BOILERPLATE])])
|
||||
m4_ifndef([_AC_PROG_LIBTOOL], [AC_DEFUN([_AC_PROG_LIBTOOL])])
|
||||
m4_ifndef([AC_LIBTOOL_SETUP], [AC_DEFUN([AC_LIBTOOL_SETUP])])
|
||||
m4_ifndef([_LT_AC_CHECK_DLFCN], [AC_DEFUN([_LT_AC_CHECK_DLFCN])])
|
||||
m4_ifndef([AC_LIBTOOL_SYS_DYNAMIC_LINKER], [AC_DEFUN([AC_LIBTOOL_SYS_DYNAMIC_LINKER])])
|
||||
m4_ifndef([_LT_AC_TAGCONFIG], [AC_DEFUN([_LT_AC_TAGCONFIG])])
|
||||
m4_ifndef([AC_DISABLE_FAST_INSTALL], [AC_DEFUN([AC_DISABLE_FAST_INSTALL])])
|
||||
m4_ifndef([_LT_AC_LANG_CXX], [AC_DEFUN([_LT_AC_LANG_CXX])])
|
||||
m4_ifndef([_LT_AC_LANG_F77], [AC_DEFUN([_LT_AC_LANG_F77])])
|
||||
m4_ifndef([_LT_AC_LANG_GCJ], [AC_DEFUN([_LT_AC_LANG_GCJ])])
|
||||
m4_ifndef([AC_LIBTOOL_LANG_C_CONFIG], [AC_DEFUN([AC_LIBTOOL_LANG_C_CONFIG])])
|
||||
m4_ifndef([_LT_AC_LANG_C_CONFIG], [AC_DEFUN([_LT_AC_LANG_C_CONFIG])])
|
||||
m4_ifndef([AC_LIBTOOL_LANG_CXX_CONFIG], [AC_DEFUN([AC_LIBTOOL_LANG_CXX_CONFIG])])
|
||||
m4_ifndef([_LT_AC_LANG_CXX_CONFIG], [AC_DEFUN([_LT_AC_LANG_CXX_CONFIG])])
|
||||
m4_ifndef([AC_LIBTOOL_LANG_F77_CONFIG], [AC_DEFUN([AC_LIBTOOL_LANG_F77_CONFIG])])
|
||||
m4_ifndef([_LT_AC_LANG_F77_CONFIG], [AC_DEFUN([_LT_AC_LANG_F77_CONFIG])])
|
||||
m4_ifndef([AC_LIBTOOL_LANG_GCJ_CONFIG], [AC_DEFUN([AC_LIBTOOL_LANG_GCJ_CONFIG])])
|
||||
m4_ifndef([_LT_AC_LANG_GCJ_CONFIG], [AC_DEFUN([_LT_AC_LANG_GCJ_CONFIG])])
|
||||
m4_ifndef([AC_LIBTOOL_LANG_RC_CONFIG], [AC_DEFUN([AC_LIBTOOL_LANG_RC_CONFIG])])
|
||||
m4_ifndef([_LT_AC_LANG_RC_CONFIG], [AC_DEFUN([_LT_AC_LANG_RC_CONFIG])])
|
||||
m4_ifndef([AC_LIBTOOL_CONFIG], [AC_DEFUN([AC_LIBTOOL_CONFIG])])
|
||||
m4_ifndef([_LT_AC_FILE_LTDLL_C], [AC_DEFUN([_LT_AC_FILE_LTDLL_C])])
|
||||
m4_ifndef([_LT_REQUIRED_DARWIN_CHECKS], [AC_DEFUN([_LT_REQUIRED_DARWIN_CHECKS])])
|
||||
m4_ifndef([_LT_AC_PROG_CXXCPP], [AC_DEFUN([_LT_AC_PROG_CXXCPP])])
|
||||
m4_ifndef([_LT_PREPARE_SED_QUOTE_VARS], [AC_DEFUN([_LT_PREPARE_SED_QUOTE_VARS])])
|
||||
m4_ifndef([_LT_PROG_ECHO_BACKSLASH], [AC_DEFUN([_LT_PROG_ECHO_BACKSLASH])])
|
||||
m4_ifndef([_LT_PROG_F77], [AC_DEFUN([_LT_PROG_F77])])
|
||||
m4_ifndef([_LT_PROG_FC], [AC_DEFUN([_LT_PROG_FC])])
|
||||
m4_ifndef([_LT_PROG_CXX], [AC_DEFUN([_LT_PROG_CXX])])
|
||||
2
test/gtest-1.8.0/.gitignore
vendored
Normal file
2
test/gtest-1.8.0/.gitignore
vendored
Normal file
@@ -0,0 +1,2 @@
|
||||
# Ignore CI build directory
|
||||
build/
|
||||
46
test/gtest-1.8.0/.travis.yml
Normal file
46
test/gtest-1.8.0/.travis.yml
Normal file
@@ -0,0 +1,46 @@
|
||||
# Build matrix / environment variable are explained on:
|
||||
# http://about.travis-ci.org/docs/user/build-configuration/
|
||||
# This file can be validated on:
|
||||
# http://lint.travis-ci.org/
|
||||
|
||||
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 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}
|
||||
- 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-3.7
|
||||
- valgrind
|
||||
os:
|
||||
- linux
|
||||
- osx
|
||||
language: cpp
|
||||
compiler:
|
||||
- gcc
|
||||
- clang
|
||||
script: ./travis.sh
|
||||
env:
|
||||
matrix:
|
||||
- GTEST_TARGET=googletest SHARED_LIB=OFF STATIC_LIB=ON CMAKE_PKG=OFF BUILD_TYPE=debug VERBOSE_MAKE=true VERBOSE
|
||||
- GTEST_TARGET=googlemock SHARED_LIB=OFF STATIC_LIB=ON CMAKE_PKG=OFF BUILD_TYPE=debug VERBOSE_MAKE=true VERBOSE
|
||||
- GTEST_TARGET=googlemock SHARED_LIB=OFF STATIC_LIB=ON CMAKE_PKG=OFF BUILD_TYPE=debug CXX_FLAGS=-std=c++11 VERBOSE_MAKE=true VERBOSE
|
||||
# - GTEST_TARGET=googletest SHARED_LIB=ON STATIC_LIB=ON CMAKE_PKG=ON BUILD_TYPE=release VERBOSE_MAKE=false
|
||||
# - GTEST_TARGET=googlemock SHARED_LIB=ON STATIC_LIB=ON CMAKE_PKG=ON BUILD_TYPE=release VERBOSE_MAKE=false
|
||||
notifications:
|
||||
email: false
|
||||
sudo: false
|
||||
16
test/gtest-1.8.0/CMakeLists.txt
Normal file
16
test/gtest-1.8.0/CMakeLists.txt
Normal 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()
|
||||
142
test/gtest-1.8.0/README.md
Normal file
142
test/gtest-1.8.0/README.md
Normal file
@@ -0,0 +1,142 @@
|
||||
|
||||
# Google Test #
|
||||
|
||||
[](https://travis-ci.org/google/googletest)
|
||||
[](https://ci.appveyor.com/project/BillyDonahue/googletest/branch/master)
|
||||
|
||||
Welcome to **Google Test**, Google's C++ test framework!
|
||||
|
||||
This repository is a merger of the formerly separate GoogleTest and
|
||||
GoogleMock projects. These were so closely related that it makes sense to
|
||||
maintain and release them together.
|
||||
|
||||
Please see the project page above for more information as well as the
|
||||
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).
|
||||
|
||||
More detailed documentation for googletest (including build instructions) are
|
||||
in its interior [googletest/README.md](googletest/README.md) file.
|
||||
|
||||
## Features ##
|
||||
|
||||
* An [XUnit](https://en.wikipedia.org/wiki/XUnit) test framework.
|
||||
* Test discovery.
|
||||
* A rich set of assertions.
|
||||
* User-defined assertions.
|
||||
* Death tests.
|
||||
* Fatal and non-fatal failures.
|
||||
* Value-parameterized tests.
|
||||
* Type-parameterized tests.
|
||||
* Various options for running the tests.
|
||||
* XML test report generation.
|
||||
|
||||
## Platforms ##
|
||||
|
||||
Google test has been used on a variety of platforms:
|
||||
|
||||
* Linux
|
||||
* Mac OS X
|
||||
* Windows
|
||||
* Cygwin
|
||||
* MinGW
|
||||
* Windows Mobile
|
||||
* Symbian
|
||||
|
||||
## Who Is Using Google Test? ##
|
||||
|
||||
In addition to many internal projects at Google, Google Test is also used by
|
||||
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](https://github.com/google/protobuf), Google's data
|
||||
interchange format.
|
||||
* The [OpenCV](http://opencv.org/) computer vision library.
|
||||
|
||||
## Related Open Source Projects ##
|
||||
|
||||
[Google Test UI](https://github.com/ospector/gtest-gbar) is test runner that runs
|
||||
your test binary, allows you to track its progress via a progress bar, and
|
||||
displays a list of test failures. Clicking on one shows failure text. Google
|
||||
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](https://en.wikipedia.org/wiki/Test_Anything_Protocol) for test
|
||||
result output. If your test runner understands TAP, you may find it useful.
|
||||
|
||||
## Requirements ##
|
||||
|
||||
Google Test is designed to have fairly minimal requirements to build
|
||||
and use with your projects, but there are some. Currently, we support
|
||||
Linux, Windows, Mac OS X, and Cygwin. We will also make our best
|
||||
effort to support other platforms (e.g. Solaris, AIX, and z/OS).
|
||||
However, since core members of the Google Test project have no access
|
||||
to these platforms, Google Test may have outstanding issues there. If
|
||||
you notice any problems on your platform, please notify
|
||||
<googletestframework@googlegroups.com>. Patches for fixing them are
|
||||
even more welcome!
|
||||
|
||||
### Linux Requirements ###
|
||||
|
||||
These are the base requirements to build and use Google Test from a source
|
||||
package (as described below):
|
||||
|
||||
* GNU-compatible Make or gmake
|
||||
* POSIX-standard shell
|
||||
* POSIX(-2) Regular Expressions (regex.h)
|
||||
* A C++98-standard-compliant compiler
|
||||
|
||||
### Windows Requirements ###
|
||||
|
||||
* Microsoft Visual C++ v7.1 or newer
|
||||
|
||||
### Cygwin Requirements ###
|
||||
|
||||
* Cygwin v1.5.25-14 or newer
|
||||
|
||||
### Mac OS X Requirements ###
|
||||
|
||||
* Mac OS X v10.4 Tiger or newer
|
||||
* Xcode Developer Tools
|
||||
|
||||
### Requirements for Contributors ###
|
||||
|
||||
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](https://www.python.org/) v2.3 or newer (for running some of
|
||||
the tests and re-generating certain source files from templates)
|
||||
* [CMake](https://cmake.org/) v2.6.4 or newer
|
||||
|
||||
## Regenerating Source Files ##
|
||||
|
||||
Some of Google Test's source files are generated from templates (not
|
||||
in the C++ sense) using a script.
|
||||
For example, the
|
||||
file include/gtest/internal/gtest-type-util.h.pump is used to generate
|
||||
gtest-type-util.h in the same directory.
|
||||
|
||||
You don't need to worry about regenerating the source files
|
||||
unless you need to modify them. You would then modify the
|
||||
corresponding `.pump` files and run the '[pump.py](googletest/scripts/pump.py)'
|
||||
generator script. See the [Pump Manual](googletest/docs/PumpManual.md).
|
||||
|
||||
### Contributing Code ###
|
||||
|
||||
We welcome patches. Please read the
|
||||
[Developer's Guide](googletest/docs/DevGuide.md)
|
||||
for how you can contribute. In particular, make sure you have signed
|
||||
the Contributor License Agreement, or we won't be able to accept the
|
||||
patch.
|
||||
|
||||
Happy testing!
|
||||
71
test/gtest-1.8.0/appveyor.yml
Normal file
71
test/gtest-1.8.0/appveyor.yml
Normal file
@@ -0,0 +1,71 @@
|
||||
version: '{build}'
|
||||
|
||||
os: Visual Studio 2015
|
||||
|
||||
environment:
|
||||
matrix:
|
||||
- Toolset: v140
|
||||
- Toolset: v120
|
||||
- Toolset: v110
|
||||
- Toolset: v100
|
||||
|
||||
platform:
|
||||
- Win32
|
||||
- x64
|
||||
|
||||
configuration:
|
||||
# - Release
|
||||
- Debug
|
||||
|
||||
build:
|
||||
verbosity: minimal
|
||||
|
||||
artifacts:
|
||||
- path: '_build/Testing/Temporary/*'
|
||||
name: test_results
|
||||
|
||||
before_build:
|
||||
- ps: |
|
||||
Write-Output "Configuration: $env:CONFIGURATION"
|
||||
Write-Output "Platform: $env:PLATFORM"
|
||||
$generator = switch ($env:TOOLSET)
|
||||
{
|
||||
"v140" {"Visual Studio 14 2015"}
|
||||
"v120" {"Visual Studio 12 2013"}
|
||||
"v110" {"Visual Studio 11 2012"}
|
||||
"v100" {"Visual Studio 10 2010"}
|
||||
}
|
||||
if ($env:PLATFORM -eq "x64")
|
||||
{
|
||||
$generator = "$generator Win64"
|
||||
}
|
||||
|
||||
build_script:
|
||||
- ps: |
|
||||
if (($env:TOOLSET -eq "v100") -and ($env:PLATFORM -eq "x64"))
|
||||
{
|
||||
return
|
||||
}
|
||||
md _build -Force | Out-Null
|
||||
cd _build
|
||||
|
||||
& cmake -G "$generator" -DCMAKE_CONFIGURATION_TYPES="Debug;Release" -Dgtest_build_tests=ON -Dgtest_build_samples=ON -Dgmock_build_tests=ON ..
|
||||
if ($LastExitCode -ne 0) {
|
||||
throw "Exec: $ErrorMessage"
|
||||
}
|
||||
& cmake --build . --config $env:CONFIGURATION
|
||||
if ($LastExitCode -ne 0) {
|
||||
throw "Exec: $ErrorMessage"
|
||||
}
|
||||
|
||||
test_script:
|
||||
- ps: |
|
||||
if (($env:Toolset -eq "v100") -and ($env:PLATFORM -eq "x64"))
|
||||
{
|
||||
return
|
||||
}
|
||||
|
||||
& ctest -C $env:CONFIGURATION --output-on-failure
|
||||
if ($LastExitCode -ne 0) {
|
||||
throw "Exec: $ErrorMessage"
|
||||
}
|
||||
@@ -15,7 +15,7 @@ option(gmock_build_tests "Build all of Google Mock's own tests." OFF)
|
||||
if (EXISTS "${CMAKE_CURRENT_SOURCE_DIR}/gtest/CMakeLists.txt")
|
||||
set(gtest_dir gtest)
|
||||
else()
|
||||
set(gtest_dir ../gtest)
|
||||
set(gtest_dir ../googletest)
|
||||
endif()
|
||||
|
||||
# Defines pre_project_set_up_hermetic_build() and set_up_hermetic_build().
|
||||
@@ -63,6 +63,16 @@ include_directories("${gmock_SOURCE_DIR}/include"
|
||||
# Test sources.
|
||||
"${gtest_SOURCE_DIR}")
|
||||
|
||||
# Summary of tuple support for Microsoft Visual Studio:
|
||||
# Compiler version(MS) version(cmake) Support
|
||||
# ---------- ----------- -------------- -----------------------------
|
||||
# <= VS 2010 <= 10 <= 1600 Use Google Tests's own tuple.
|
||||
# VS 2012 11 1700 std::tr1::tuple + _VARIADIC_MAX=10
|
||||
# VS 2013 12 1800 std::tr1::tuple
|
||||
if (MSVC AND MSVC_VERSION EQUAL 1700)
|
||||
add_definitions(/D _VARIADIC_MAX=10)
|
||||
endif()
|
||||
|
||||
########################################################################
|
||||
#
|
||||
# Defines the gmock & gmock_main libraries. User tests should link
|
||||
@@ -82,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.
|
||||
@@ -134,8 +160,16 @@ if (gmock_build_tests)
|
||||
cxx_library(gmock_main_no_rtti "${cxx_no_rtti}"
|
||||
"${gtest_dir}/src/gtest-all.cc" src/gmock-all.cc src/gmock_main.cc)
|
||||
|
||||
cxx_library(gmock_main_use_own_tuple "${cxx_use_own_tuple}"
|
||||
"${gtest_dir}/src/gtest-all.cc" src/gmock-all.cc src/gmock_main.cc)
|
||||
if (NOT MSVC OR MSVC_VERSION LESS 1600) # 1600 is Visual Studio 2010.
|
||||
# Visual Studio 2010, 2012, and 2013 define symbols in std::tr1 that
|
||||
# conflict with our own definitions. Therefore using our own tuple does not
|
||||
# work on those compilers.
|
||||
cxx_library(gmock_main_use_own_tuple "${cxx_use_own_tuple}"
|
||||
"${gtest_dir}/src/gtest-all.cc" src/gmock-all.cc src/gmock_main.cc)
|
||||
|
||||
cxx_test_with_flags(gmock_use_own_tuple_test "${cxx_use_own_tuple}"
|
||||
gmock_main_use_own_tuple test/gmock-spec-builders_test.cc)
|
||||
endif()
|
||||
|
||||
cxx_test_with_flags(gmock-more-actions_no_exception_test "${cxx_no_exception}"
|
||||
gmock_main_no_exception test/gmock-more-actions_test.cc)
|
||||
@@ -143,9 +177,6 @@ if (gmock_build_tests)
|
||||
cxx_test_with_flags(gmock_no_rtti_test "${cxx_no_rtti}"
|
||||
gmock_main_no_rtti test/gmock-spec-builders_test.cc)
|
||||
|
||||
cxx_test_with_flags(gmock_use_own_tuple_test "${cxx_use_own_tuple}"
|
||||
gmock_main_use_own_tuple test/gmock-spec-builders_test.cc)
|
||||
|
||||
cxx_shared_library(shared_gmock_main "${cxx_default}"
|
||||
"${gtest_dir}/src/gtest-all.cc" src/gmock-all.cc src/gmock_main.cc)
|
||||
|
||||
@@ -42,7 +42,10 @@ pkginclude_internaldir = $(pkgincludedir)/internal
|
||||
pkginclude_internal_HEADERS = \
|
||||
include/gmock/internal/gmock-generated-internal-utils.h \
|
||||
include/gmock/internal/gmock-internal-utils.h \
|
||||
include/gmock/internal/gmock-port.h
|
||||
include/gmock/internal/gmock-port.h \
|
||||
include/gmock/internal/custom/gmock-generated-actions.h \
|
||||
include/gmock/internal/custom/gmock-matchers.h \
|
||||
include/gmock/internal/custom/gmock-port.h
|
||||
|
||||
lib_libgmock_main_la_SOURCES = src/gmock_main.cc
|
||||
lib_libgmock_main_la_LIBADD = lib/libgmock.la
|
||||
@@ -136,7 +139,8 @@ EXTRA_DIST += \
|
||||
include/gmock/gmock-generated-function-mockers.h.pump \
|
||||
include/gmock/gmock-generated-matchers.h.pump \
|
||||
include/gmock/gmock-generated-nice-strict.h.pump \
|
||||
include/gmock/internal/gmock-generated-internal-utils.h.pump
|
||||
include/gmock/internal/gmock-generated-internal-utils.h.pump \
|
||||
include/gmock/internal/custom/gmock-generated-actions.h.pump
|
||||
|
||||
# Script for fusing Google Mock and Google Test source files.
|
||||
EXTRA_DIST += scripts/fuse_gmock_files.py
|
||||
@@ -154,6 +158,10 @@ EXTRA_DIST += \
|
||||
scripts/generator/cpp/utils.py \
|
||||
scripts/generator/gmock_gen.py
|
||||
|
||||
# Script for diagnosing compiler errors in programs that use Google
|
||||
# Mock.
|
||||
EXTRA_DIST += scripts/gmock_doctor.py
|
||||
|
||||
# CMake scripts.
|
||||
EXTRA_DIST += \
|
||||
CMakeLists.txt
|
||||
333
test/gtest-1.8.0/googlemock/README.md
Normal file
333
test/gtest-1.8.0/googlemock/README.md
Normal file
@@ -0,0 +1,333 @@
|
||||
## Google Mock ##
|
||||
|
||||
The Google C++ mocking framework.
|
||||
|
||||
### Overview ###
|
||||
|
||||
Google's framework for writing and using C++ mock classes.
|
||||
It can help you derive better designs of your system and write better tests.
|
||||
|
||||
It is inspired by:
|
||||
|
||||
* [jMock](http://www.jmock.org/),
|
||||
* [EasyMock](http://www.easymock.org/), and
|
||||
* [Hamcrest](http://code.google.com/p/hamcrest/),
|
||||
|
||||
and designed with C++'s specifics in mind.
|
||||
|
||||
Google mock:
|
||||
|
||||
* lets you create mock classes trivially using simple macros.
|
||||
* supports a rich set of matchers and actions.
|
||||
* handles unordered, partially ordered, or completely ordered expectations.
|
||||
* is extensible by users.
|
||||
|
||||
We hope you find it useful!
|
||||
|
||||
### Features ###
|
||||
|
||||
* Provides a declarative syntax for defining mocks.
|
||||
* Can easily define partial (hybrid) mocks, which are a cross of real
|
||||
and mock objects.
|
||||
* Handles functions of arbitrary types and overloaded functions.
|
||||
* Comes with a rich set of matchers for validating function arguments.
|
||||
* Uses an intuitive syntax for controlling the behavior of a mock.
|
||||
* Does automatic verification of expectations (no record-and-replay needed).
|
||||
* Allows arbitrary (partial) ordering constraints on
|
||||
function calls to be expressed,.
|
||||
* Lets a user extend it by defining new matchers and actions.
|
||||
* Does not use exceptions.
|
||||
* Is easy to learn and use.
|
||||
|
||||
Please see the project page above for more information as well as the
|
||||
mailing list for questions, discussions, and development. There is
|
||||
also an IRC channel on OFTC (irc.oftc.net) #gtest available. Please
|
||||
join us!
|
||||
|
||||
Please note that code under [scripts/generator](scripts/generator/) is
|
||||
from [cppclean](http://code.google.com/p/cppclean/) and released under
|
||||
the Apache License, which is different from Google Mock's license.
|
||||
|
||||
## Getting Started ##
|
||||
|
||||
If you are new to the project, we suggest that you read the user
|
||||
documentation in the following order:
|
||||
|
||||
* Learn the [basics](../googletest/docs/Primer.md) of
|
||||
Google Test, if you choose to use Google Mock with it (recommended).
|
||||
* Read [Google Mock for Dummies](docs/ForDummies.md).
|
||||
* Read the instructions below on how to build Google Mock.
|
||||
|
||||
You can also watch Zhanyong's [talk](http://www.youtube.com/watch?v=sYpCyLI47rM) on Google Mock's usage and implementation.
|
||||
|
||||
Once you understand the basics, check out the rest of the docs:
|
||||
|
||||
* [CheatSheet](docs/CheatSheet.md) - all the commonly used stuff
|
||||
at a glance.
|
||||
* [CookBook](docs/CookBook.md) - recipes for getting things done,
|
||||
including advanced techniques.
|
||||
|
||||
If you need help, please check the
|
||||
[KnownIssues](docs/KnownIssues.md) and
|
||||
[FrequentlyAskedQuestions](docs/FrequentlyAskedQuestions.md) before
|
||||
posting a question on the
|
||||
[discussion group](http://groups.google.com/group/googlemock).
|
||||
|
||||
|
||||
### Using Google Mock Without Google Test ###
|
||||
|
||||
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/), 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 ###
|
||||
|
||||
Google Mock is implemented on top of [Google Test](
|
||||
http://github.com/google/googletest/), and depends on it.
|
||||
You must use the bundled version of Google Test when using Google Mock.
|
||||
|
||||
You can also easily configure Google Mock to work with another testing
|
||||
framework, although it will still need Google Test. Please read
|
||||
["Using_Google_Mock_with_Any_Testing_Framework"](
|
||||
docs/ForDummies.md#Using_Google_Mock_with_Any_Testing_Framework)
|
||||
for instructions.
|
||||
|
||||
Google Mock depends on advanced C++ features and thus requires a more
|
||||
modern compiler. The following are needed to use Google Mock:
|
||||
|
||||
#### Linux Requirements ####
|
||||
|
||||
* GNU-compatible Make or "gmake"
|
||||
* POSIX-standard shell
|
||||
* POSIX(-2) Regular Expressions (regex.h)
|
||||
* C++98-standard-compliant compiler (e.g. GCC 3.4 or newer)
|
||||
|
||||
#### Windows Requirements ####
|
||||
|
||||
* Microsoft Visual C++ 8.0 SP1 or newer
|
||||
|
||||
#### Mac OS X Requirements ####
|
||||
|
||||
* Mac OS X 10.4 Tiger or newer
|
||||
* Developer Tools Installed
|
||||
|
||||
### Requirements for Contributors ###
|
||||
|
||||
We welcome patches. If you plan to contribute a patch, you need to
|
||||
build Google Mock and its tests, which has further requirements:
|
||||
|
||||
* Automake version 1.9 or newer
|
||||
* Autoconf version 2.59 or newer
|
||||
* Libtool / Libtoolize
|
||||
* Python version 2.3 or newer (for running some of the tests and
|
||||
re-generating certain source files from templates)
|
||||
|
||||
### Building Google Mock ###
|
||||
|
||||
#### Preparing to Build (Unix only) ####
|
||||
|
||||
If you are using a Unix system and plan to use the GNU Autotools build
|
||||
system to build Google Mock (described below), you'll need to
|
||||
configure it now.
|
||||
|
||||
To prepare the Autotools build system:
|
||||
|
||||
cd googlemock
|
||||
autoreconf -fvi
|
||||
|
||||
To build Google Mock and your tests that use it, you need to tell your
|
||||
build system where to find its headers and source files. The exact
|
||||
way to do it depends on which build system you use, and is usually
|
||||
straightforward.
|
||||
|
||||
This section shows how you can integrate Google Mock into your
|
||||
existing build system.
|
||||
|
||||
Suppose you put Google Mock in directory `${GMOCK_DIR}` and Google Test
|
||||
in `${GTEST_DIR}` (the latter is `${GMOCK_DIR}/gtest` by default). To
|
||||
build Google Mock, create a library build target (or a project as
|
||||
called by Visual Studio and Xcode) to compile
|
||||
|
||||
${GTEST_DIR}/src/gtest-all.cc and ${GMOCK_DIR}/src/gmock-all.cc
|
||||
|
||||
with
|
||||
|
||||
${GTEST_DIR}/include and ${GMOCK_DIR}/include
|
||||
|
||||
in the system header search path, and
|
||||
|
||||
${GTEST_DIR} and ${GMOCK_DIR}
|
||||
|
||||
in the normal header search path. Assuming a Linux-like system and gcc,
|
||||
something like the following will do:
|
||||
|
||||
g++ -isystem ${GTEST_DIR}/include -I${GTEST_DIR} \
|
||||
-isystem ${GMOCK_DIR}/include -I${GMOCK_DIR} \
|
||||
-pthread -c ${GTEST_DIR}/src/gtest-all.cc
|
||||
g++ -isystem ${GTEST_DIR}/include -I${GTEST_DIR} \
|
||||
-isystem ${GMOCK_DIR}/include -I${GMOCK_DIR} \
|
||||
-pthread -c ${GMOCK_DIR}/src/gmock-all.cc
|
||||
ar -rv libgmock.a gtest-all.o gmock-all.o
|
||||
|
||||
(We need -pthread as Google Test and Google Mock use threads.)
|
||||
|
||||
Next, you should compile your test source file with
|
||||
${GTEST\_DIR}/include and ${GMOCK\_DIR}/include in the header search
|
||||
path, and link it with gmock and any other necessary libraries:
|
||||
|
||||
g++ -isystem ${GTEST_DIR}/include -isystem ${GMOCK_DIR}/include \
|
||||
-pthread path/to/your_test.cc libgmock.a -o your_test
|
||||
|
||||
As an example, the make/ directory contains a Makefile that you can
|
||||
use to build Google Mock on systems where GNU make is available
|
||||
(e.g. Linux, Mac OS X, and Cygwin). It doesn't try to build Google
|
||||
Mock's own tests. Instead, it just builds the Google Mock library and
|
||||
a sample test. You can use it as a starting point for your own build
|
||||
script.
|
||||
|
||||
If the default settings are correct for your environment, the
|
||||
following commands should succeed:
|
||||
|
||||
cd ${GMOCK_DIR}/make
|
||||
make
|
||||
./gmock_test
|
||||
|
||||
If you see errors, try to tweak the contents of
|
||||
[make/Makefile](make/Makefile) to make them go away.
|
||||
|
||||
### Windows ###
|
||||
|
||||
The msvc/2005 directory contains VC++ 2005 projects and the msvc/2010
|
||||
directory contains VC++ 2010 projects for building Google Mock and
|
||||
selected tests.
|
||||
|
||||
Change to the appropriate directory and run "msbuild gmock.sln" to
|
||||
build the library and tests (or open the gmock.sln in the MSVC IDE).
|
||||
If you want to create your own project to use with Google Mock, you'll
|
||||
have to configure it to use the `gmock_config` propety sheet. For that:
|
||||
|
||||
* Open the Property Manager window (View | Other Windows | Property Manager)
|
||||
* Right-click on your project and select "Add Existing Property Sheet..."
|
||||
* Navigate to `gmock_config.vsprops` or `gmock_config.props` and select it.
|
||||
* In Project Properties | Configuration Properties | General | Additional
|
||||
Include Directories, type <path to Google Mock>/include.
|
||||
|
||||
### Tweaking Google Mock ###
|
||||
|
||||
Google Mock can be used in diverse environments. The default
|
||||
configuration may not work (or may not work well) out of the box in
|
||||
some environments. However, you can easily tweak Google Mock by
|
||||
defining control macros on the compiler command line. Generally,
|
||||
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 [${GTEST\_DIR}/include/gtest/internal/gtest-port.h](
|
||||
../googletest/include/gtest/internal/gtest-port.h).
|
||||
|
||||
### Choosing a TR1 Tuple Library ###
|
||||
|
||||
Google Mock uses the C++ Technical Report 1 (TR1) tuple library
|
||||
heavily. Unfortunately TR1 tuple is not yet widely available with all
|
||||
compilers. The good news is that Google Test 1.4.0+ implements a
|
||||
subset of TR1 tuple that's enough for Google Mock's need. Google Mock
|
||||
will automatically use that implementation when the compiler doesn't
|
||||
provide TR1 tuple.
|
||||
|
||||
Usually you don't need to care about which tuple library Google Test
|
||||
and Google Mock use. However, if your project already uses TR1 tuple,
|
||||
you need to tell Google Test and Google Mock to use the same TR1 tuple
|
||||
library the rest of your project uses, or the two tuple
|
||||
implementations will clash. To do that, add
|
||||
|
||||
-DGTEST_USE_OWN_TR1_TUPLE=0
|
||||
|
||||
to the compiler flags while compiling Google Test, Google Mock, and
|
||||
your tests. If you want to force Google Test and Google Mock to use
|
||||
their own tuple library, just add
|
||||
|
||||
-DGTEST_USE_OWN_TR1_TUPLE=1
|
||||
|
||||
to the compiler flags instead.
|
||||
|
||||
If you want to use Boost's TR1 tuple library with Google Mock, please
|
||||
refer to the Boost website (http://www.boost.org/) for how to obtain
|
||||
it and set it up.
|
||||
|
||||
### As a Shared Library (DLL) ###
|
||||
|
||||
Google Mock is compact, so most users can build and link it as a static
|
||||
library for the simplicity. Google Mock can be used as a DLL, but the
|
||||
same DLL must contain Google Test as well. See
|
||||
[Google Test's README][gtest_readme]
|
||||
for instructions on how to set up necessary compiler settings.
|
||||
|
||||
### Tweaking Google Mock ###
|
||||
|
||||
Most of Google Test's control macros apply to Google Mock as well.
|
||||
Please see [Google Test's README][gtest_readme] for how to tweak them.
|
||||
|
||||
### Upgrading from an Earlier Version ###
|
||||
|
||||
We strive to keep Google Mock releases backward compatible.
|
||||
Sometimes, though, we have to make some breaking changes for the
|
||||
users' long-term benefits. This section describes what you'll need to
|
||||
do if you are upgrading from an earlier version of Google Mock.
|
||||
|
||||
#### Upgrading from 1.1.0 or Earlier ####
|
||||
|
||||
You may need to explicitly enable or disable Google Test's own TR1
|
||||
tuple library. See the instructions in section "[Choosing a TR1 Tuple
|
||||
Library](../googletest/#choosing-a-tr1-tuple-library)".
|
||||
|
||||
#### Upgrading from 1.4.0 or Earlier ####
|
||||
|
||||
On platforms where the pthread library is available, Google Test and
|
||||
Google Mock use it in order to be thread-safe. For this to work, you
|
||||
may need to tweak your compiler and/or linker flags. Please see the
|
||||
"[Multi-threaded Tests](../googletest#multi-threaded-tests
|
||||
)" section in file Google Test's README for what you may need to do.
|
||||
|
||||
If you have custom matchers defined using `MatcherInterface` or
|
||||
`MakePolymorphicMatcher()`, you'll need to update their definitions to
|
||||
use the new matcher API (
|
||||
[monomorphic](http://code.google.com/p/googlemock/wiki/CookBook#Writing_New_Monomorphic_Matchers),
|
||||
[polymorphic](http://code.google.com/p/googlemock/wiki/CookBook#Writing_New_Polymorphic_Matchers)).
|
||||
Matchers defined using `MATCHER()` or `MATCHER_P*()` aren't affected.
|
||||
|
||||
### Developing Google Mock ###
|
||||
|
||||
This section discusses how to make your own changes to Google Mock.
|
||||
|
||||
#### Testing Google Mock Itself ####
|
||||
|
||||
To make sure your changes work as intended and don't break existing
|
||||
functionality, you'll want to compile and run Google Test's own tests.
|
||||
For that you'll need Autotools. First, make sure you have followed
|
||||
the instructions above to configure Google Mock.
|
||||
Then, create a build output directory and enter it. Next,
|
||||
|
||||
${GMOCK_DIR}/configure # try --help for more info
|
||||
|
||||
Once you have successfully configured Google Mock, the build steps are
|
||||
standard for GNU-style OSS packages.
|
||||
|
||||
make # Standard makefile following GNU conventions
|
||||
make check # Builds and runs all tests - all should pass.
|
||||
|
||||
Note that when building your project against Google Mock, you are building
|
||||
against Google Test as well. There is no need to configure Google Test
|
||||
separately.
|
||||
|
||||
#### Contributing a Patch ####
|
||||
|
||||
We welcome patches.
|
||||
Please read the [Developer's Guide](docs/DevGuide.md)
|
||||
for how you can contribute. In particular, make sure you have signed
|
||||
the Contributor License Agreement, or we won't be able to accept the
|
||||
patch.
|
||||
|
||||
Happy testing!
|
||||
|
||||
[gtest_readme]: ../googletest/README.md "googletest"
|
||||
0
test/gmock-1.7.0/scripts/generator/cpp/__init__.py → test/gtest-1.8.0/googlemock/build-aux/.keep
Executable file → Normal file
0
test/gmock-1.7.0/scripts/generator/cpp/__init__.py → test/gtest-1.8.0/googlemock/build-aux/.keep
Executable file → Normal file
@@ -1,4 +1,4 @@
|
||||
m4_include(gtest/m4/acx_pthread.m4)
|
||||
m4_include(../googletest/m4/acx_pthread.m4)
|
||||
|
||||
AC_INIT([Google C++ Mocking Framework],
|
||||
[1.7.0],
|
||||
@@ -129,14 +129,14 @@ AS_IF([test "x${HAVE_BUILT_GTEST}" = "xyes"],
|
||||
GTEST_LDFLAGS=`${GTEST_CONFIG} --ldflags`
|
||||
GTEST_LIBS=`${GTEST_CONFIG} --libs`
|
||||
GTEST_VERSION=`${GTEST_CONFIG} --version`],
|
||||
[AC_CONFIG_SUBDIRS([gtest])
|
||||
[AC_CONFIG_SUBDIRS([../googletest])
|
||||
# GTEST_CONFIG needs to be executable both in a Makefile environmont and
|
||||
# in a shell script environment, so resolve an absolute path for it here.
|
||||
GTEST_CONFIG="`pwd -P`/gtest/scripts/gtest-config"
|
||||
GTEST_CPPFLAGS='-I$(top_srcdir)/gtest/include'
|
||||
GTEST_CONFIG="`pwd -P`/../googletest/scripts/gtest-config"
|
||||
GTEST_CPPFLAGS='-I$(top_srcdir)/../googletest/include'
|
||||
GTEST_CXXFLAGS='-g'
|
||||
GTEST_LDFLAGS=''
|
||||
GTEST_LIBS='$(top_builddir)/gtest/lib/libgtest.la'
|
||||
GTEST_LIBS='$(top_builddir)/../googletest/lib/libgtest.la'
|
||||
GTEST_VERSION="${GTEST_MIN_VERSION}"])
|
||||
|
||||
# TODO(chandlerc@google.com) Check the types, structures, and other compiler
|
||||
562
test/gtest-1.8.0/googlemock/docs/CheatSheet.md
Normal file
562
test/gtest-1.8.0/googlemock/docs/CheatSheet.md
Normal file
@@ -0,0 +1,562 @@
|
||||
|
||||
|
||||
# Defining a Mock Class #
|
||||
|
||||
## Mocking a Normal Class ##
|
||||
|
||||
Given
|
||||
```
|
||||
class Foo {
|
||||
...
|
||||
virtual ~Foo();
|
||||
virtual int GetSize() const = 0;
|
||||
virtual string Describe(const char* name) = 0;
|
||||
virtual string Describe(int type) = 0;
|
||||
virtual bool Process(Bar elem, int count) = 0;
|
||||
};
|
||||
```
|
||||
(note that `~Foo()` **must** be virtual) we can define its mock as
|
||||
```
|
||||
#include "gmock/gmock.h"
|
||||
|
||||
class MockFoo : public Foo {
|
||||
MOCK_CONST_METHOD0(GetSize, int());
|
||||
MOCK_METHOD1(Describe, string(const char* name));
|
||||
MOCK_METHOD1(Describe, string(int type));
|
||||
MOCK_METHOD2(Process, bool(Bar elem, int count));
|
||||
};
|
||||
```
|
||||
|
||||
To create a "nice" mock object which ignores all uninteresting calls,
|
||||
or a "strict" mock object, which treats them as failures:
|
||||
```
|
||||
NiceMock<MockFoo> nice_foo; // The type is a subclass of MockFoo.
|
||||
StrictMock<MockFoo> strict_foo; // The type is a subclass of MockFoo.
|
||||
```
|
||||
|
||||
## Mocking a Class Template ##
|
||||
|
||||
To mock
|
||||
```
|
||||
template <typename Elem>
|
||||
class StackInterface {
|
||||
public:
|
||||
...
|
||||
virtual ~StackInterface();
|
||||
virtual int GetSize() const = 0;
|
||||
virtual void Push(const Elem& x) = 0;
|
||||
};
|
||||
```
|
||||
(note that `~StackInterface()` **must** be virtual) just append `_T` to the `MOCK_*` macros:
|
||||
```
|
||||
template <typename Elem>
|
||||
class MockStack : public StackInterface<Elem> {
|
||||
public:
|
||||
...
|
||||
MOCK_CONST_METHOD0_T(GetSize, int());
|
||||
MOCK_METHOD1_T(Push, void(const Elem& x));
|
||||
};
|
||||
```
|
||||
|
||||
## Specifying Calling Conventions for Mock Functions ##
|
||||
|
||||
If your mock function doesn't use the default calling convention, you
|
||||
can specify it by appending `_WITH_CALLTYPE` to any of the macros
|
||||
described in the previous two sections and supplying the calling
|
||||
convention as the first argument to the macro. For example,
|
||||
```
|
||||
MOCK_METHOD_1_WITH_CALLTYPE(STDMETHODCALLTYPE, Foo, bool(int n));
|
||||
MOCK_CONST_METHOD2_WITH_CALLTYPE(STDMETHODCALLTYPE, Bar, int(double x, double y));
|
||||
```
|
||||
where `STDMETHODCALLTYPE` is defined by `<objbase.h>` on Windows.
|
||||
|
||||
# Using Mocks in Tests #
|
||||
|
||||
The typical flow is:
|
||||
1. Import the Google Mock names you need to use. All Google Mock names are in the `testing` namespace unless they are macros or otherwise noted.
|
||||
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](../../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:
|
||||
```
|
||||
using ::testing::Return; // #1
|
||||
|
||||
TEST(BarTest, DoesThis) {
|
||||
MockFoo foo; // #2
|
||||
|
||||
ON_CALL(foo, GetSize()) // #3
|
||||
.WillByDefault(Return(1));
|
||||
// ... other default actions ...
|
||||
|
||||
EXPECT_CALL(foo, Describe(5)) // #4
|
||||
.Times(3)
|
||||
.WillRepeatedly(Return("Category 5"));
|
||||
// ... other expectations ...
|
||||
|
||||
EXPECT_EQ("good", MyProductionFunction(&foo)); // #5
|
||||
} // #6
|
||||
```
|
||||
|
||||
# Setting Default Actions #
|
||||
|
||||
Google Mock has a **built-in default action** for any function that
|
||||
returns `void`, `bool`, a numeric value, or a pointer.
|
||||
|
||||
To customize the default action for functions with return type `T` globally:
|
||||
```
|
||||
using ::testing::DefaultValue;
|
||||
|
||||
// Sets the default value to be returned. T must be CopyConstructible.
|
||||
DefaultValue<T>::Set(value);
|
||||
// Sets a factory. Will be invoked on demand. T must be MoveConstructible.
|
||||
// T MakeT();
|
||||
DefaultValue<T>::SetFactory(&MakeT);
|
||||
// ... use the mocks ...
|
||||
// Resets the default value.
|
||||
DefaultValue<T>::Clear();
|
||||
```
|
||||
|
||||
To customize the default action for a particular method, use `ON_CALL()`:
|
||||
```
|
||||
ON_CALL(mock_object, method(matchers))
|
||||
.With(multi_argument_matcher) ?
|
||||
.WillByDefault(action);
|
||||
```
|
||||
|
||||
# Setting Expectations #
|
||||
|
||||
`EXPECT_CALL()` sets **expectations** on a mock method (How will it be
|
||||
called? What will it do?):
|
||||
```
|
||||
EXPECT_CALL(mock_object, method(matchers))
|
||||
.With(multi_argument_matcher) ?
|
||||
.Times(cardinality) ?
|
||||
.InSequence(sequences) *
|
||||
.After(expectations) *
|
||||
.WillOnce(action) *
|
||||
.WillRepeatedly(action) ?
|
||||
.RetiresOnSaturation(); ?
|
||||
```
|
||||
|
||||
If `Times()` is omitted, the cardinality is assumed to be:
|
||||
|
||||
* `Times(1)` when there is neither `WillOnce()` nor `WillRepeatedly()`;
|
||||
* `Times(n)` when there are `n WillOnce()`s but no `WillRepeatedly()`, where `n` >= 1; or
|
||||
* `Times(AtLeast(n))` when there are `n WillOnce()`s and a `WillRepeatedly()`, where `n` >= 0.
|
||||
|
||||
A method with no `EXPECT_CALL()` is free to be invoked _any number of times_, and the default action will be taken each time.
|
||||
|
||||
# Matchers #
|
||||
|
||||
A **matcher** matches a _single_ argument. You can use it inside
|
||||
`ON_CALL()` or `EXPECT_CALL()`, or use it to validate a value
|
||||
directly:
|
||||
|
||||
| `EXPECT_THAT(value, matcher)` | Asserts that `value` matches `matcher`. |
|
||||
|:------------------------------|:----------------------------------------|
|
||||
| `ASSERT_THAT(value, matcher)` | The same as `EXPECT_THAT(value, matcher)`, except that it generates a **fatal** failure. |
|
||||
|
||||
Built-in matchers (where `argument` is the function argument) are
|
||||
divided into several categories:
|
||||
|
||||
## Wildcard ##
|
||||
|`_`|`argument` can be any value of the correct type.|
|
||||
|:--|:-----------------------------------------------|
|
||||
|`A<type>()` or `An<type>()`|`argument` can be any value of type `type`. |
|
||||
|
||||
## Generic Comparison ##
|
||||
|
||||
|`Eq(value)` or `value`|`argument == value`|
|
||||
|:---------------------|:------------------|
|
||||
|`Ge(value)` |`argument >= value`|
|
||||
|`Gt(value)` |`argument > value` |
|
||||
|`Le(value)` |`argument <= value`|
|
||||
|`Lt(value)` |`argument < value` |
|
||||
|`Ne(value)` |`argument != value`|
|
||||
|`IsNull()` |`argument` is a `NULL` pointer (raw or smart).|
|
||||
|`NotNull()` |`argument` is a non-null pointer (raw or smart).|
|
||||
|`Ref(variable)` |`argument` is a reference to `variable`.|
|
||||
|`TypedEq<type>(value)`|`argument` has type `type` and is equal to `value`. You may need to use this instead of `Eq(value)` when the mock function is overloaded.|
|
||||
|
||||
Except `Ref()`, these matchers make a _copy_ of `value` in case it's
|
||||
modified or destructed later. If the compiler complains that `value`
|
||||
doesn't have a public copy constructor, try wrap it in `ByRef()`,
|
||||
e.g. `Eq(ByRef(non_copyable_value))`. If you do that, make sure
|
||||
`non_copyable_value` is not changed afterwards, or the meaning of your
|
||||
matcher will be changed.
|
||||
|
||||
## Floating-Point Matchers ##
|
||||
|
||||
|`DoubleEq(a_double)`|`argument` is a `double` value approximately equal to `a_double`, treating two NaNs as unequal.|
|
||||
|:-------------------|:----------------------------------------------------------------------------------------------|
|
||||
|`FloatEq(a_float)` |`argument` is a `float` value approximately equal to `a_float`, treating two NaNs as unequal. |
|
||||
|`NanSensitiveDoubleEq(a_double)`|`argument` is a `double` value approximately equal to `a_double`, treating two NaNs as equal. |
|
||||
|`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](../../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
|
||||
return false. The `NanSensitive*` version instead treats two NaNs as
|
||||
equal, which is often what a user wants.
|
||||
|
||||
|`DoubleNear(a_double, max_abs_error)`|`argument` is a `double` value close to `a_double` (absolute error <= `max_abs_error`), treating two NaNs as unequal.|
|
||||
|:------------------------------------|:--------------------------------------------------------------------------------------------------------------------|
|
||||
|`FloatNear(a_float, max_abs_error)` |`argument` is a `float` value close to `a_float` (absolute error <= `max_abs_error`), treating two NaNs as unequal. |
|
||||
|`NanSensitiveDoubleNear(a_double, max_abs_error)`|`argument` is a `double` value close to `a_double` (absolute error <= `max_abs_error`), treating two NaNs as equal. |
|
||||
|`NanSensitiveFloatNear(a_float, max_abs_error)`|`argument` is a `float` value close to `a_float` (absolute error <= `max_abs_error`), treating two NaNs as equal. |
|
||||
|
||||
## String Matchers ##
|
||||
|
||||
The `argument` can be either a C string or a C++ string object:
|
||||
|
||||
|`ContainsRegex(string)`|`argument` matches the given regular expression.|
|
||||
|:----------------------|:-----------------------------------------------|
|
||||
|`EndsWith(suffix)` |`argument` ends with string `suffix`. |
|
||||
|`HasSubstr(string)` |`argument` contains `string` as a sub-string. |
|
||||
|`MatchesRegex(string)` |`argument` matches the given regular expression with the match starting at the first character and ending at the last character.|
|
||||
|`StartsWith(prefix)` |`argument` starts with string `prefix`. |
|
||||
|`StrCaseEq(string)` |`argument` is equal to `string`, ignoring case. |
|
||||
|`StrCaseNe(string)` |`argument` is not equal to `string`, ignoring case.|
|
||||
|`StrEq(string)` |`argument` is equal to `string`. |
|
||||
|`StrNe(string)` |`argument` is not equal to `string`. |
|
||||
|
||||
`ContainsRegex()` and `MatchesRegex()` use the regular expression
|
||||
syntax defined
|
||||
[here](../../googletest/docs/AdvancedGuide.md#regular-expression-syntax).
|
||||
`StrCaseEq()`, `StrCaseNe()`, `StrEq()`, and `StrNe()` work for wide
|
||||
strings as well.
|
||||
|
||||
## Container Matchers ##
|
||||
|
||||
Most STL-style containers support `==`, so you can use
|
||||
`Eq(expected_container)` or simply `expected_container` to match a
|
||||
container exactly. If you want to write the elements in-line,
|
||||
match them more flexibly, or get more informative messages, you can use:
|
||||
|
||||
| `ContainerEq(container)` | The same as `Eq(container)` except that the failure message also includes which elements are in one container but not the other. |
|
||||
|:-------------------------|:---------------------------------------------------------------------------------------------------------------------------------|
|
||||
| `Contains(e)` | `argument` contains an element that matches `e`, which can be either a value or a matcher. |
|
||||
| `Each(e)` | `argument` is a container where _every_ element matches `e`, which can be either a value or a matcher. |
|
||||
| `ElementsAre(e0, e1, ..., en)` | `argument` has `n + 1` elements, where the i-th element matches `ei`, which can be a value or a matcher. 0 to 10 arguments are allowed. |
|
||||
| `ElementsAreArray({ e0, e1, ..., en })`, `ElementsAreArray(array)`, or `ElementsAreArray(array, count)` | The same as `ElementsAre()` except that the expected element values/matchers come from an initializer list, STL-style container, or C-style array. |
|
||||
| `IsEmpty()` | `argument` is an empty container (`container.empty()`). |
|
||||
| `Pointwise(m, container)` | `argument` contains the same number of elements as in `container`, and for all i, (the i-th element in `argument`, the i-th element in `container`) match `m`, which is a matcher on 2-tuples. E.g. `Pointwise(Le(), upper_bounds)` verifies that each element in `argument` doesn't exceed the corresponding element in `upper_bounds`. See more detail below. |
|
||||
| `SizeIs(m)` | `argument` is a container whose size matches `m`. E.g. `SizeIs(2)` or `SizeIs(Lt(2))`. |
|
||||
| `UnorderedElementsAre(e0, e1, ..., en)` | `argument` has `n + 1` elements, and under some permutation each element matches an `ei` (for a different `i`), which can be a value or a matcher. 0 to 10 arguments are allowed. |
|
||||
| `UnorderedElementsAreArray({ e0, e1, ..., en })`, `UnorderedElementsAreArray(array)`, or `UnorderedElementsAreArray(array, count)` | The same as `UnorderedElementsAre()` except that the expected element values/matchers come from an initializer list, STL-style container, or C-style array. |
|
||||
| `WhenSorted(m)` | When `argument` is sorted using the `<` operator, it matches container matcher `m`. E.g. `WhenSorted(UnorderedElementsAre(1, 2, 3))` verifies that `argument` contains elements `1`, `2`, and `3`, ignoring order. |
|
||||
| `WhenSortedBy(comparator, m)` | The same as `WhenSorted(m)`, except that the given comparator instead of `<` is used to sort `argument`. E.g. `WhenSortedBy(std::greater<int>(), ElementsAre(3, 2, 1))`. |
|
||||
|
||||
Notes:
|
||||
|
||||
* These matchers can also match:
|
||||
1. a native array passed by reference (e.g. in `Foo(const int (&a)[5])`), and
|
||||
1. an array passed as a pointer and a count (e.g. in `Bar(const T* buffer, int len)` -- see [Multi-argument Matchers](#Multiargument_Matchers.md)).
|
||||
* The array being matched may be multi-dimensional (i.e. its elements can be arrays).
|
||||
* `m` in `Pointwise(m, ...)` should be a matcher for `::testing::tuple<T, U>` where `T` and `U` are the element type of the actual container and the expected container, respectively. For example, to compare two `Foo` containers where `Foo` doesn't support `operator==` but has an `Equals()` method, one might write:
|
||||
|
||||
```
|
||||
using ::testing::get;
|
||||
MATCHER(FooEq, "") {
|
||||
return get<0>(arg).Equals(get<1>(arg));
|
||||
}
|
||||
...
|
||||
EXPECT_THAT(actual_foos, Pointwise(FooEq(), expected_foos));
|
||||
```
|
||||
|
||||
## Member Matchers ##
|
||||
|
||||
|`Field(&class::field, m)`|`argument.field` (or `argument->field` when `argument` is a plain pointer) matches matcher `m`, where `argument` is an object of type _class_.|
|
||||
|:------------------------|:---------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
|`Key(e)` |`argument.first` matches `e`, which can be either a value or a matcher. E.g. `Contains(Key(Le(5)))` can verify that a `map` contains a key `<= 5`.|
|
||||
|`Pair(m1, m2)` |`argument` is an `std::pair` whose `first` field matches `m1` and `second` field matches `m2`. |
|
||||
|`Property(&class::property, m)`|`argument.property()` (or `argument->property()` when `argument` is a plain pointer) matches matcher `m`, where `argument` is an object of type _class_.|
|
||||
|
||||
## Matching the Result of a Function or Functor ##
|
||||
|
||||
|`ResultOf(f, m)`|`f(argument)` matches matcher `m`, where `f` is a function or functor.|
|
||||
|:---------------|:---------------------------------------------------------------------|
|
||||
|
||||
## Pointer Matchers ##
|
||||
|
||||
|`Pointee(m)`|`argument` (either a smart pointer or a raw pointer) points to a value that matches matcher `m`.|
|
||||
|:-----------|:-----------------------------------------------------------------------------------------------|
|
||||
|`WhenDynamicCastTo<T>(m)`| when `argument` is passed through `dynamic_cast<T>()`, it matches matcher `m`. |
|
||||
|
||||
## Multiargument Matchers ##
|
||||
|
||||
Technically, all matchers match a _single_ value. A "multi-argument"
|
||||
matcher is just one that matches a _tuple_. The following matchers can
|
||||
be used to match a tuple `(x, y)`:
|
||||
|
||||
|`Eq()`|`x == y`|
|
||||
|:-----|:-------|
|
||||
|`Ge()`|`x >= y`|
|
||||
|`Gt()`|`x > y` |
|
||||
|`Le()`|`x <= y`|
|
||||
|`Lt()`|`x < y` |
|
||||
|`Ne()`|`x != y`|
|
||||
|
||||
You can use the following selectors to pick a subset of the arguments
|
||||
(or reorder them) to participate in the matching:
|
||||
|
||||
|`AllArgs(m)`|Equivalent to `m`. Useful as syntactic sugar in `.With(AllArgs(m))`.|
|
||||
|:-----------|:-------------------------------------------------------------------|
|
||||
|`Args<N1, N2, ..., Nk>(m)`|The tuple of the `k` selected (using 0-based indices) arguments matches `m`, e.g. `Args<1, 2>(Eq())`.|
|
||||
|
||||
## Composite Matchers ##
|
||||
|
||||
You can make a matcher from one or more other matchers:
|
||||
|
||||
|`AllOf(m1, m2, ..., mn)`|`argument` matches all of the matchers `m1` to `mn`.|
|
||||
|:-----------------------|:---------------------------------------------------|
|
||||
|`AnyOf(m1, m2, ..., mn)`|`argument` matches at least one of the matchers `m1` to `mn`.|
|
||||
|`Not(m)` |`argument` doesn't match matcher `m`. |
|
||||
|
||||
## Adapters for Matchers ##
|
||||
|
||||
|`MatcherCast<T>(m)`|casts 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 ##
|
||||
|
||||
|`Matches(m)(value)`|evaluates to `true` if `value` matches `m`. You can use `Matches(m)` alone as a unary functor.|
|
||||
|:------------------|:---------------------------------------------------------------------------------------------|
|
||||
|`ExplainMatchResult(m, value, result_listener)`|evaluates to `true` if `value` matches `m`, explaining the result to `result_listener`. |
|
||||
|`Value(value, m)` |evaluates to `true` if `value` matches `m`. |
|
||||
|
||||
## Defining Matchers ##
|
||||
|
||||
| `MATCHER(IsEven, "") { return (arg % 2) == 0; }` | Defines a matcher `IsEven()` to match an even number. |
|
||||
|:-------------------------------------------------|:------------------------------------------------------|
|
||||
| `MATCHER_P(IsDivisibleBy, n, "") { *result_listener << "where the remainder is " << (arg % n); return (arg % n) == 0; }` | Defines a macher `IsDivisibleBy(n)` to match a number divisible by `n`. |
|
||||
| `MATCHER_P2(IsBetween, a, b, std::string(negation ? "isn't" : "is") + " between " + PrintToString(a) + " and " + PrintToString(b)) { return a <= arg && arg <= b; }` | Defines a matcher `IsBetween(a, b)` to match a value in the range [`a`, `b`]. |
|
||||
|
||||
**Notes:**
|
||||
|
||||
1. The `MATCHER*` macros cannot be used inside a function or class.
|
||||
1. The matcher body must be _purely functional_ (i.e. it cannot have any side effect, and the result must not depend on anything other than the value being matched and the matcher parameters).
|
||||
1. You can use `PrintToString(x)` to convert a value `x` of any type to a string.
|
||||
|
||||
## Matchers as Test Assertions ##
|
||||
|
||||
|`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`. |
|
||||
|
||||
# Actions #
|
||||
|
||||
**Actions** specify what a mock function should do when invoked.
|
||||
|
||||
## Returning a Value ##
|
||||
|
||||
|`Return()`|Return from a `void` mock function.|
|
||||
|:---------|:----------------------------------|
|
||||
|`Return(value)`|Return `value`. If the type of `value` is different to the mock function's return type, `value` is converted to the latter type <i>at the time the expectation is set</i>, not when the action is executed.|
|
||||
|`ReturnArg<N>()`|Return the `N`-th (0-based) argument.|
|
||||
|`ReturnNew<T>(a1, ..., ak)`|Return `new T(a1, ..., ak)`; a different object is created each time.|
|
||||
|`ReturnNull()`|Return a null pointer. |
|
||||
|`ReturnPointee(ptr)`|Return the value pointed to by `ptr`.|
|
||||
|`ReturnRef(variable)`|Return a reference to `variable`. |
|
||||
|`ReturnRefOfCopy(value)`|Return a reference to a copy of `value`; the copy lives as long as the action.|
|
||||
|
||||
## Side Effects ##
|
||||
|
||||
|`Assign(&variable, value)`|Assign `value` to variable.|
|
||||
|:-------------------------|:--------------------------|
|
||||
| `DeleteArg<N>()` | Delete the `N`-th (0-based) argument, which must be a pointer. |
|
||||
| `SaveArg<N>(pointer)` | Save the `N`-th (0-based) argument to `*pointer`. |
|
||||
| `SaveArgPointee<N>(pointer)` | Save the value pointed to by the `N`-th (0-based) argument to `*pointer`. |
|
||||
| `SetArgReferee<N>(value)` | Assign value to the variable referenced by the `N`-th (0-based) argument. |
|
||||
|`SetArgPointee<N>(value)` |Assign `value` to the variable pointed by the `N`-th (0-based) argument.|
|
||||
|`SetArgumentPointee<N>(value)`|Same as `SetArgPointee<N>(value)`. Deprecated. Will be removed in v1.7.0.|
|
||||
|`SetArrayArgument<N>(first, last)`|Copies the elements in source range [`first`, `last`) to the array pointed to by the `N`-th (0-based) argument, which can be either a pointer or an iterator. The action does not take ownership of the elements in the source range.|
|
||||
|`SetErrnoAndReturn(error, value)`|Set `errno` to `error` and return `value`.|
|
||||
|`Throw(exception)` |Throws the given exception, which can be any copyable value. Available since v1.1.0.|
|
||||
|
||||
## Using a Function or a Functor as an Action ##
|
||||
|
||||
|`Invoke(f)`|Invoke `f` with the arguments passed to the mock function, where `f` can be a global/static function or a functor.|
|
||||
|:----------|:-----------------------------------------------------------------------------------------------------------------|
|
||||
|`Invoke(object_pointer, &class::method)`|Invoke the {method on the object with the arguments passed to the mock function. |
|
||||
|`InvokeWithoutArgs(f)`|Invoke `f`, which can be a global/static function or a functor. `f` must take no arguments. |
|
||||
|`InvokeWithoutArgs(object_pointer, &class::method)`|Invoke the method on the object, which takes no arguments. |
|
||||
|`InvokeArgument<N>(arg1, arg2, ..., argk)`|Invoke the mock function's `N`-th (0-based) argument, which must be a function or a functor, with the `k` arguments.|
|
||||
|
||||
The return value of the invoked function is used as the return value
|
||||
of the action.
|
||||
|
||||
When defining a function or functor to be used with `Invoke*()`, you can declare any unused parameters as `Unused`:
|
||||
```
|
||||
double Distance(Unused, double x, double y) { return sqrt(x*x + y*y); }
|
||||
...
|
||||
EXPECT_CALL(mock, Foo("Hi", _, _)).WillOnce(Invoke(Distance));
|
||||
```
|
||||
|
||||
In `InvokeArgument<N>(...)`, if an argument needs to be passed by reference, wrap it inside `ByRef()`. For example,
|
||||
```
|
||||
InvokeArgument<2>(5, string("Hi"), ByRef(foo))
|
||||
```
|
||||
calls the mock function's #2 argument, passing to it `5` and `string("Hi")` by value, and `foo` by reference.
|
||||
|
||||
## Default Action ##
|
||||
|
||||
|`DoDefault()`|Do the default action (specified by `ON_CALL()` or the built-in one).|
|
||||
|:------------|:--------------------------------------------------------------------|
|
||||
|
||||
**Note:** due to technical reasons, `DoDefault()` cannot be used inside a composite action - trying to do so will result in a run-time error.
|
||||
|
||||
## Composite Actions ##
|
||||
|
||||
|`DoAll(a1, a2, ..., an)`|Do all actions `a1` to `an` and return the result of `an` in each invocation. The first `n - 1` sub-actions must return void. |
|
||||
|:-----------------------|:-----------------------------------------------------------------------------------------------------------------------------|
|
||||
|`IgnoreResult(a)` |Perform action `a` and ignore its result. `a` must not return void. |
|
||||
|`WithArg<N>(a)` |Pass the `N`-th (0-based) argument of the mock function to action `a` and perform it. |
|
||||
|`WithArgs<N1, N2, ..., Nk>(a)`|Pass the selected (0-based) arguments of the mock function to action `a` and perform it. |
|
||||
|`WithoutArgs(a)` |Perform action `a` without any arguments. |
|
||||
|
||||
## Defining Actions ##
|
||||
|
||||
| `ACTION(Sum) { return arg0 + arg1; }` | Defines an action `Sum()` to return the sum of the mock function's argument #0 and #1. |
|
||||
|:--------------------------------------|:---------------------------------------------------------------------------------------|
|
||||
| `ACTION_P(Plus, n) { return arg0 + n; }` | Defines an action `Plus(n)` to return the sum of the mock function's argument #0 and `n`. |
|
||||
| `ACTION_Pk(Foo, p1, ..., pk) { statements; }` | Defines a parameterized action `Foo(p1, ..., pk)` to execute the given `statements`. |
|
||||
|
||||
The `ACTION*` macros cannot be used inside a function or class.
|
||||
|
||||
# Cardinalities #
|
||||
|
||||
These are used in `Times()` to specify how many times a mock function will be called:
|
||||
|
||||
|`AnyNumber()`|The function can be called any number of times.|
|
||||
|:------------|:----------------------------------------------|
|
||||
|`AtLeast(n)` |The call is expected at least `n` times. |
|
||||
|`AtMost(n)` |The call is expected at most `n` times. |
|
||||
|`Between(m, n)`|The call is expected between `m` and `n` (inclusive) times.|
|
||||
|`Exactly(n) or n`|The call is expected exactly `n` times. In particular, the call should never happen when `n` is 0.|
|
||||
|
||||
# Expectation Order #
|
||||
|
||||
By default, the expectations can be matched in _any_ order. If some
|
||||
or all expectations must be matched in a given order, there are two
|
||||
ways to specify it. They can be used either independently or
|
||||
together.
|
||||
|
||||
## The After Clause ##
|
||||
|
||||
```
|
||||
using ::testing::Expectation;
|
||||
...
|
||||
Expectation init_x = EXPECT_CALL(foo, InitX());
|
||||
Expectation init_y = EXPECT_CALL(foo, InitY());
|
||||
EXPECT_CALL(foo, Bar())
|
||||
.After(init_x, init_y);
|
||||
```
|
||||
says that `Bar()` can be called only after both `InitX()` and
|
||||
`InitY()` have been called.
|
||||
|
||||
If you don't know how many pre-requisites an expectation has when you
|
||||
write it, you can use an `ExpectationSet` to collect them:
|
||||
|
||||
```
|
||||
using ::testing::ExpectationSet;
|
||||
...
|
||||
ExpectationSet all_inits;
|
||||
for (int i = 0; i < element_count; i++) {
|
||||
all_inits += EXPECT_CALL(foo, InitElement(i));
|
||||
}
|
||||
EXPECT_CALL(foo, Bar())
|
||||
.After(all_inits);
|
||||
```
|
||||
says that `Bar()` can be called only after all elements have been
|
||||
initialized (but we don't care about which elements get initialized
|
||||
before the others).
|
||||
|
||||
Modifying an `ExpectationSet` after using it in an `.After()` doesn't
|
||||
affect the meaning of the `.After()`.
|
||||
|
||||
## Sequences ##
|
||||
|
||||
When you have a long chain of sequential expectations, it's easier to
|
||||
specify the order using **sequences**, which don't require you to given
|
||||
each expectation in the chain a different name. <i>All expected<br>
|
||||
calls</i> in the same sequence must occur in the order they are
|
||||
specified.
|
||||
|
||||
```
|
||||
using ::testing::Sequence;
|
||||
Sequence s1, s2;
|
||||
...
|
||||
EXPECT_CALL(foo, Reset())
|
||||
.InSequence(s1, s2)
|
||||
.WillOnce(Return(true));
|
||||
EXPECT_CALL(foo, GetSize())
|
||||
.InSequence(s1)
|
||||
.WillOnce(Return(1));
|
||||
EXPECT_CALL(foo, Describe(A<const char*>()))
|
||||
.InSequence(s2)
|
||||
.WillOnce(Return("dummy"));
|
||||
```
|
||||
says that `Reset()` must be called before _both_ `GetSize()` _and_
|
||||
`Describe()`, and the latter two can occur in any order.
|
||||
|
||||
To put many expectations in a sequence conveniently:
|
||||
```
|
||||
using ::testing::InSequence;
|
||||
{
|
||||
InSequence dummy;
|
||||
|
||||
EXPECT_CALL(...)...;
|
||||
EXPECT_CALL(...)...;
|
||||
...
|
||||
EXPECT_CALL(...)...;
|
||||
}
|
||||
```
|
||||
says that all expected calls in the scope of `dummy` must occur in
|
||||
strict order. The name `dummy` is irrelevant.)
|
||||
|
||||
# Verifying and Resetting a Mock #
|
||||
|
||||
Google Mock will verify the expectations on a mock object when it is destructed, or you can do it earlier:
|
||||
```
|
||||
using ::testing::Mock;
|
||||
...
|
||||
// Verifies and removes the expectations on mock_obj;
|
||||
// returns true iff successful.
|
||||
Mock::VerifyAndClearExpectations(&mock_obj);
|
||||
...
|
||||
// Verifies and removes the expectations on mock_obj;
|
||||
// also removes the default actions set by ON_CALL();
|
||||
// returns true iff successful.
|
||||
Mock::VerifyAndClear(&mock_obj);
|
||||
```
|
||||
|
||||
You can also tell Google Mock that a mock object can be leaked and doesn't
|
||||
need to be verified:
|
||||
```
|
||||
Mock::AllowLeak(&mock_obj);
|
||||
```
|
||||
|
||||
# Mock Classes #
|
||||
|
||||
Google Mock defines a convenient mock class template
|
||||
```
|
||||
class MockFunction<R(A1, ..., An)> {
|
||||
public:
|
||||
MOCK_METHODn(Call, R(A1, ..., An));
|
||||
};
|
||||
```
|
||||
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. |
|
||||
3675
test/gtest-1.8.0/googlemock/docs/CookBook.md
Normal file
3675
test/gtest-1.8.0/googlemock/docs/CookBook.md
Normal file
File diff suppressed because it is too large
Load Diff
280
test/gtest-1.8.0/googlemock/docs/DesignDoc.md
Normal file
280
test/gtest-1.8.0/googlemock/docs/DesignDoc.md
Normal file
@@ -0,0 +1,280 @@
|
||||
This page discusses the design of new Google Mock features.
|
||||
|
||||
|
||||
|
||||
# Macros for Defining Actions #
|
||||
|
||||
## Problem ##
|
||||
|
||||
Due to the lack of closures in C++, it currently requires some
|
||||
non-trivial effort to define a custom action in Google Mock. For
|
||||
example, suppose you want to "increment the value pointed to by the
|
||||
second argument of the mock function and return it", you could write:
|
||||
|
||||
```
|
||||
int IncrementArg1(Unused, int* p, Unused) {
|
||||
return ++(*p);
|
||||
}
|
||||
|
||||
... WillOnce(Invoke(IncrementArg1));
|
||||
```
|
||||
|
||||
There are several things unsatisfactory about this approach:
|
||||
|
||||
* Even though the action only cares about the second argument of the mock function, its definition needs to list other arguments as dummies. This is tedious.
|
||||
* The defined action is usable only in mock functions that takes exactly 3 arguments - an unnecessary restriction.
|
||||
* To use the action, one has to say `Invoke(IncrementArg1)`, which isn't as nice as `IncrementArg1()`.
|
||||
|
||||
The latter two problems can be overcome using `MakePolymorphicAction()`,
|
||||
but it requires much more boilerplate code:
|
||||
|
||||
```
|
||||
class IncrementArg1Action {
|
||||
public:
|
||||
template <typename Result, typename ArgumentTuple>
|
||||
Result Perform(const ArgumentTuple& args) const {
|
||||
return ++(*tr1::get<1>(args));
|
||||
}
|
||||
};
|
||||
|
||||
PolymorphicAction<IncrementArg1Action> IncrementArg1() {
|
||||
return MakePolymorphicAction(IncrementArg1Action());
|
||||
}
|
||||
|
||||
... WillOnce(IncrementArg1());
|
||||
```
|
||||
|
||||
Our goal is to allow defining custom actions with the least amount of
|
||||
boiler-plate C++ requires.
|
||||
|
||||
## Solution ##
|
||||
|
||||
We propose to introduce a new macro:
|
||||
```
|
||||
ACTION(name) { statements; }
|
||||
```
|
||||
|
||||
Using this in a namespace scope will define an action with the given
|
||||
name that executes the statements. Inside the statements, you can
|
||||
refer to the K-th (0-based) argument of the mock function as `argK`.
|
||||
For example:
|
||||
```
|
||||
ACTION(IncrementArg1) { return ++(*arg1); }
|
||||
```
|
||||
allows you to write
|
||||
```
|
||||
... WillOnce(IncrementArg1());
|
||||
```
|
||||
|
||||
Note that you don't need to specify the types of the mock function
|
||||
arguments, as brevity is a top design goal here. Rest assured that
|
||||
your code is still type-safe though: you'll get a compiler error if
|
||||
`*arg1` doesn't support the `++` operator, or if the type of
|
||||
`++(*arg1)` isn't compatible with the mock function's return type.
|
||||
|
||||
Another example:
|
||||
```
|
||||
ACTION(Foo) {
|
||||
(*arg2)(5);
|
||||
Blah();
|
||||
*arg1 = 0;
|
||||
return arg0;
|
||||
}
|
||||
```
|
||||
defines an action `Foo()` that invokes argument #2 (a function pointer)
|
||||
with 5, calls function `Blah()`, sets the value pointed to by argument
|
||||
#1 to 0, and returns argument #0.
|
||||
|
||||
For more convenience and flexibility, you can also use the following
|
||||
pre-defined symbols in the body of `ACTION`:
|
||||
|
||||
| `argK_type` | The type of the K-th (0-based) argument of the mock function |
|
||||
|:------------|:-------------------------------------------------------------|
|
||||
| `args` | All arguments of the mock function as a tuple |
|
||||
| `args_type` | The type of all arguments of the mock function as a tuple |
|
||||
| `return_type` | The return type of the mock function |
|
||||
| `function_type` | The type of the mock function |
|
||||
|
||||
For example, when using an `ACTION` as a stub action for mock function:
|
||||
```
|
||||
int DoSomething(bool flag, int* ptr);
|
||||
```
|
||||
we have:
|
||||
| **Pre-defined Symbol** | **Is Bound To** |
|
||||
|:-----------------------|:----------------|
|
||||
| `arg0` | the value of `flag` |
|
||||
| `arg0_type` | the type `bool` |
|
||||
| `arg1` | the value of `ptr` |
|
||||
| `arg1_type` | the type `int*` |
|
||||
| `args` | the tuple `(flag, ptr)` |
|
||||
| `args_type` | the type `std::tr1::tuple<bool, int*>` |
|
||||
| `return_type` | the type `int` |
|
||||
| `function_type` | the type `int(bool, int*)` |
|
||||
|
||||
## Parameterized actions ##
|
||||
|
||||
Sometimes you'll want to parameterize the action. For that we propose
|
||||
another macro
|
||||
```
|
||||
ACTION_P(name, param) { statements; }
|
||||
```
|
||||
|
||||
For example,
|
||||
```
|
||||
ACTION_P(Add, n) { return arg0 + n; }
|
||||
```
|
||||
will allow you to write
|
||||
```
|
||||
// Returns argument #0 + 5.
|
||||
... WillOnce(Add(5));
|
||||
```
|
||||
|
||||
For convenience, we use the term _arguments_ for the values used to
|
||||
invoke the mock function, and the term _parameters_ for the values
|
||||
used to instantiate an action.
|
||||
|
||||
Note that you don't need to provide the type of the parameter either.
|
||||
Suppose the parameter is named `param`, you can also use the
|
||||
Google-Mock-defined symbol `param_type` to refer to the type of the
|
||||
parameter as inferred by the compiler.
|
||||
|
||||
We will also provide `ACTION_P2`, `ACTION_P3`, and etc to support
|
||||
multi-parameter actions. For example,
|
||||
```
|
||||
ACTION_P2(ReturnDistanceTo, x, y) {
|
||||
double dx = arg0 - x;
|
||||
double dy = arg1 - y;
|
||||
return sqrt(dx*dx + dy*dy);
|
||||
}
|
||||
```
|
||||
lets you write
|
||||
```
|
||||
... WillOnce(ReturnDistanceTo(5.0, 26.5));
|
||||
```
|
||||
|
||||
You can view `ACTION` as a degenerated parameterized action where the
|
||||
number of parameters is 0.
|
||||
|
||||
## Advanced Usages ##
|
||||
|
||||
### Overloading Actions ###
|
||||
|
||||
You can easily define actions overloaded on the number of parameters:
|
||||
```
|
||||
ACTION_P(Plus, a) { ... }
|
||||
ACTION_P2(Plus, a, b) { ... }
|
||||
```
|
||||
|
||||
### Restricting the Type of an Argument or Parameter ###
|
||||
|
||||
For maximum brevity and reusability, the `ACTION*` macros don't let
|
||||
you specify the types of the mock function arguments and the action
|
||||
parameters. Instead, we let the compiler infer the types for us.
|
||||
|
||||
Sometimes, however, we may want to be more explicit about the types.
|
||||
There are several tricks to do that. For example:
|
||||
```
|
||||
ACTION(Foo) {
|
||||
// Makes sure arg0 can be converted to int.
|
||||
int n = arg0;
|
||||
... use n instead of arg0 here ...
|
||||
}
|
||||
|
||||
ACTION_P(Bar, param) {
|
||||
// Makes sure the type of arg1 is const char*.
|
||||
::testing::StaticAssertTypeEq<const char*, arg1_type>();
|
||||
|
||||
// Makes sure param can be converted to bool.
|
||||
bool flag = param;
|
||||
}
|
||||
```
|
||||
where `StaticAssertTypeEq` is a compile-time assertion we plan to add to
|
||||
Google Test (the name is chosen to match `static_assert` in C++0x).
|
||||
|
||||
### Using the ACTION Object's Type ###
|
||||
|
||||
If you are writing a function that returns an `ACTION` object, you'll
|
||||
need to know its type. The type depends on the macro used to define
|
||||
the action and the parameter types. The rule is relatively simple:
|
||||
| **Given Definition** | **Expression** | **Has Type** |
|
||||
|:---------------------|:---------------|:-------------|
|
||||
| `ACTION(Foo)` | `Foo()` | `FooAction` |
|
||||
| `ACTION_P(Bar, param)` | `Bar(int_value)` | `BarActionP<int>` |
|
||||
| `ACTION_P2(Baz, p1, p2)` | `Baz(bool_value, int_value)` | `BazActionP2<bool, int>` |
|
||||
| ... | ... | ... |
|
||||
|
||||
Note that we have to pick different suffixes (`Action`, `ActionP`,
|
||||
`ActionP2`, and etc) for actions with different numbers of parameters,
|
||||
or the action definitions cannot be overloaded on the number of
|
||||
parameters.
|
||||
|
||||
## When to Use ##
|
||||
|
||||
While the new macros are very convenient, please also consider other
|
||||
means of implementing actions (e.g. via `ActionInterface` or
|
||||
`MakePolymorphicAction()`), especially if you need to use the defined
|
||||
action a lot. While the other approaches require more work, they give
|
||||
you more control on the types of the mock function arguments and the
|
||||
action parameters, which in general leads to better compiler error
|
||||
messages that pay off in the long run. They also allow overloading
|
||||
actions based on parameter types, as opposed to just the number of
|
||||
parameters.
|
||||
|
||||
## Related Work ##
|
||||
|
||||
As you may have realized, the `ACTION*` macros resemble closures (also
|
||||
known as lambda expressions or anonymous functions). Indeed, both of
|
||||
them seek to lower the syntactic overhead for defining a function.
|
||||
|
||||
C++0x will support lambdas, but they are not part of C++ right now.
|
||||
Some non-standard libraries (most notably BLL or Boost Lambda Library)
|
||||
try to alleviate this problem. However, they are not a good choice
|
||||
for defining actions as:
|
||||
|
||||
* They are non-standard and not widely installed. Google Mock only depends on standard libraries and `tr1::tuple`, which is part of the new C++ standard and comes with gcc 4+. We want to keep it that way.
|
||||
* They are not trivial to learn.
|
||||
* They will become obsolete when C++0x's lambda feature is widely supported. We don't want to make our users use a dying library.
|
||||
* Since they are based on operators, they are rather ad hoc: you cannot use statements, and you cannot pass the lambda arguments to a function, for example.
|
||||
* They have subtle semantics that easily confuses new users. For example, in expression `_1++ + foo++`, `foo` will be incremented only once where the expression is evaluated, while `_1` will be incremented every time the unnamed function is invoked. This is far from intuitive.
|
||||
|
||||
`ACTION*` avoid all these problems.
|
||||
|
||||
## Future Improvements ##
|
||||
|
||||
There may be a need for composing `ACTION*` definitions (i.e. invoking
|
||||
another `ACTION` inside the definition of one `ACTION*`). We are not
|
||||
sure we want it yet, as one can get a similar effect by putting
|
||||
`ACTION` definitions in function templates and composing the function
|
||||
templates. We'll revisit this based on user feedback.
|
||||
|
||||
The reason we don't allow `ACTION*()` inside a function body is that
|
||||
the current C++ standard doesn't allow function-local types to be used
|
||||
to instantiate templates. The upcoming C++0x standard will lift this
|
||||
restriction. Once this feature is widely supported by compilers, we
|
||||
can revisit the implementation and add support for using `ACTION*()`
|
||||
inside a function.
|
||||
|
||||
C++0x will also support lambda expressions. When they become
|
||||
available, we may want to support using lambdas as actions.
|
||||
|
||||
# Macros for Defining Matchers #
|
||||
|
||||
Once the macros for defining actions are implemented, we plan to do
|
||||
the same for matchers:
|
||||
|
||||
```
|
||||
MATCHER(name) { statements; }
|
||||
```
|
||||
|
||||
where you can refer to the value being matched as `arg`. For example,
|
||||
given:
|
||||
|
||||
```
|
||||
MATCHER(IsPositive) { return arg > 0; }
|
||||
```
|
||||
|
||||
you can use `IsPositive()` as a matcher that matches a value iff it is
|
||||
greater than 0.
|
||||
|
||||
We will also add `MATCHER_P`, `MATCHER_P2`, and etc for parameterized
|
||||
matchers.
|
||||
132
test/gtest-1.8.0/googlemock/docs/DevGuide.md
Normal file
132
test/gtest-1.8.0/googlemock/docs/DevGuide.md
Normal file
@@ -0,0 +1,132 @@
|
||||
|
||||
|
||||
If you are interested in understanding the internals of Google Mock,
|
||||
building from source, or contributing ideas or modifications to the
|
||||
project, then this document is for you.
|
||||
|
||||
# Introduction #
|
||||
|
||||
First, let's give you some background of the project.
|
||||
|
||||
## Licensing ##
|
||||
|
||||
All Google Mock source and pre-built packages are provided under the [New BSD License](http://www.opensource.org/licenses/bsd-license.php).
|
||||
|
||||
## The Google Mock Community ##
|
||||
|
||||
The Google Mock community exists primarily through the [discussion group](http://groups.google.com/group/googlemock), 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.
|
||||
|
||||
### Please Be Friendly ###
|
||||
|
||||
Showing courtesy and respect to others is a vital part of the Google
|
||||
culture, and we strongly encourage everyone participating in Google
|
||||
Mock development to join us in accepting nothing less. Of course,
|
||||
being courteous is not the same as failing to constructively disagree
|
||||
with each other, but it does mean that we should be respectful of each
|
||||
other when enumerating the 42 technical reasons that a particular
|
||||
proposal may not be the best choice. There's never a reason to be
|
||||
antagonistic or dismissive toward anyone who is sincerely trying to
|
||||
contribute to a discussion.
|
||||
|
||||
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 Mock ###
|
||||
|
||||
As always, discuss Google Mock in the official [Google C++ Mocking Framework discussion group](http://groups.google.com/group/googlemock). 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 Mock,
|
||||
this is the section for you.
|
||||
|
||||
## Checking Out the Source from Subversion ##
|
||||
|
||||
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](../) 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](../README.md) file.
|
||||
|
||||
## Testing ##
|
||||
|
||||
A mocking 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/googlemock/source/browse/trunk/README) and
|
||||
verify that there are no failures.
|
||||
|
||||
# Contributing Code #
|
||||
|
||||
We are excited that Google Mock is now open source, and hope to get
|
||||
great patches from the community. Before you fire up your favorite IDE
|
||||
and begin hammering away at that new feature, though, please take the
|
||||
time to read this section and understand the process. While it seems
|
||||
rigorous, we want to keep a high standard of quality in the code
|
||||
base.
|
||||
|
||||
## Contributor License Agreements ##
|
||||
|
||||
You must sign a Contributor License Agreement (CLA) before we can
|
||||
accept any code. The CLA protects you and us.
|
||||
|
||||
* If you are an individual writing original source code and you're sure you own the intellectual property, then you'll need to sign an [individual CLA](http://code.google.com/legal/individual-cla-v1.0.html).
|
||||
* If you work for a company that wants to allow you to contribute your work to Google Mock, then you'll need to sign a [corporate CLA](http://code.google.com/legal/corporate-cla-v1.0.html).
|
||||
|
||||
Follow either of the two links above to access the appropriate CLA and
|
||||
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](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 ##
|
||||
|
||||
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 Mock issue tracker](http://code.google.com/p/googlemock/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. 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 Mock 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](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 ##
|
||||
|
||||
The current members of the Google Mock engineering team are the only
|
||||
committers at present. In the great tradition of eating one's own
|
||||
dogfood, we will be requiring each new Google Mock engineering team
|
||||
member to earn the right to become a committer by following the
|
||||
procedures in this document, writing consistently great code, and
|
||||
demonstrating repeatedly that he or she truly gets the zen of Google
|
||||
Mock.
|
||||
|
||||
# Release Process #
|
||||
|
||||
We follow the typical release process for Subversion-based projects:
|
||||
|
||||
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.
|
||||
1. An individual point release (the `Z` in `X.Y.Z`) is made by creating a tag from the branch.
|
||||
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/).
|
||||
12
test/gtest-1.8.0/googlemock/docs/Documentation.md
Normal file
12
test/gtest-1.8.0/googlemock/docs/Documentation.md
Normal file
@@ -0,0 +1,12 @@
|
||||
This page lists all documentation wiki pages for Google Mock **(the SVN trunk version)**
|
||||
- **if you use a released version of Google Mock, please read the documentation for that specific version instead.**
|
||||
|
||||
* [ForDummies](ForDummies.md) -- start here if you are new to Google Mock.
|
||||
* [CheatSheet](CheatSheet.md) -- a quick reference.
|
||||
* [CookBook](CookBook.md) -- recipes for doing various tasks using Google Mock.
|
||||
* [FrequentlyAskedQuestions](FrequentlyAskedQuestions.md) -- check here before asking a question on the mailing list.
|
||||
|
||||
To contribute code to Google Mock, read:
|
||||
|
||||
* [DevGuide](DevGuide.md) -- read this _before_ writing your first patch.
|
||||
* [Pump Manual](../googletest/docs/PumpManual.md) -- how we generate some of Google Mock's source files.
|
||||
439
test/gtest-1.8.0/googlemock/docs/ForDummies.md
Normal file
439
test/gtest-1.8.0/googlemock/docs/ForDummies.md
Normal file
@@ -0,0 +1,439 @@
|
||||
|
||||
|
||||
(**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).
|
||||
|
||||
**Note:** It is easy to confuse the term _fake objects_ with mock objects. Fakes and mocks actually mean very different things in the Test-Driven Development (TDD) community:
|
||||
|
||||
* **Fake** objects have working implementations, but usually take some shortcut (perhaps to make the operations less expensive), which makes them not suitable for production. An in-memory file system would be an example of a fake.
|
||||
* **Mocks** are objects pre-programmed with _expectations_, which form a specification of the calls they are expected to receive.
|
||||
|
||||
If all this seems too abstract for you, don't worry - the most important thing to remember is that a mock allows you to check the _interaction_ between itself and code that uses it. The difference between fakes and mocks will become much clearer once you start to use mocks.
|
||||
|
||||
**Google C++ Mocking Framework** (or **Google Mock** for short) is a library (sometimes we also call it a "framework" to make it sound cool) for creating mock classes and using them. It does to C++ what [jMock](http://www.jmock.org/) and [EasyMock](http://www.easymock.org/) do to Java.
|
||||
|
||||
Using Google Mock involves three basic steps:
|
||||
|
||||
1. Use some simple macros to describe the interface you want to mock, and they will expand to the implementation of your mock class;
|
||||
1. Create some mock objects and specify its expectations and behavior using an intuitive syntax;
|
||||
1. Exercise code that uses the mock objects. Google Mock will catch any violation of the expectations as soon as it arises.
|
||||
|
||||
# Why Google Mock? #
|
||||
While mock objects help you remove unnecessary dependencies in tests and make them fast and reliable, using mocks manually in C++ is _hard_:
|
||||
|
||||
* Someone has to implement the mocks. The job is usually tedious and error-prone. No wonder people go great distance to avoid it.
|
||||
* The quality of those manually written mocks is a bit, uh, unpredictable. You may see some really polished ones, but you may also see some that were hacked up in a hurry and have all sorts of ad hoc restrictions.
|
||||
* The knowledge you gained from using one mock doesn't transfer to the next.
|
||||
|
||||
In contrast, Java and Python programmers have some fine mock frameworks, which automate the creation of mocks. As a result, mocking is a proven effective technique and widely adopted practice in those communities. Having the right tool absolutely makes the difference.
|
||||
|
||||
Google Mock was built to help C++ programmers. It was inspired by [jMock](http://www.jmock.org/) and [EasyMock](http://www.easymock.org/), but designed with C++'s specifics in mind. It is your friend if any of the following problems is bothering you:
|
||||
|
||||
* You are stuck with a sub-optimal design and wish you had done more prototyping before it was too late, but prototyping in C++ is by no means "rapid".
|
||||
* Your tests are slow as they depend on too many libraries or use expensive resources (e.g. a database).
|
||||
* Your tests are brittle as some resources they use are unreliable (e.g. the network).
|
||||
* You want to test how your code handles a failure (e.g. a file checksum error), but it's not easy to cause one.
|
||||
* You need to make sure that your module interacts with other modules in the right way, but it's hard to observe the interaction; therefore you resort to observing the side effects at the end of the action, which is awkward at best.
|
||||
* You want to "mock out" your dependencies, except that they don't have mock implementations yet; and, frankly, you aren't thrilled by some of those hand-written mocks.
|
||||
|
||||
We encourage you to use Google Mock as:
|
||||
|
||||
* a _design_ tool, for it lets you experiment with your interface design early and often. More iterations lead to better designs!
|
||||
* 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.
|
||||
|
||||
# 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:
|
||||
|
||||
```
|
||||
class Turtle {
|
||||
...
|
||||
virtual ~Turtle() {}
|
||||
virtual void PenUp() = 0;
|
||||
virtual void PenDown() = 0;
|
||||
virtual void Forward(int distance) = 0;
|
||||
virtual void Turn(int degrees) = 0;
|
||||
virtual void GoTo(int x, int y) = 0;
|
||||
virtual int GetX() const = 0;
|
||||
virtual int GetY() const = 0;
|
||||
};
|
||||
```
|
||||
|
||||
(Note that the destructor of `Turtle` **must** be virtual, as is the case for **all** classes you intend to inherit from - otherwise the destructor of the derived class will not be called when you delete an object through a base pointer, and you'll get corrupted program states like memory leaks.)
|
||||
|
||||
You can control whether the turtle's movement will leave a trace using `PenUp()` and `PenDown()`, and control its movement using `Forward()`, `Turn()`, and `GoTo()`. Finally, `GetX()` and `GetY()` tell you the current position of the turtle.
|
||||
|
||||
Your program will normally use a real implementation of this interface. In tests, you can use a mock implementation instead. This allows you to easily check what drawing primitives your program is calling, with what arguments, and in which order. Tests written this way are much more robust (they won't break because your new machine does anti-aliasing differently), easier to read and maintain (the intent of a test is expressed in the code, not in some binary images), and run _much, much faster_.
|
||||
|
||||
# Writing the Mock Class #
|
||||
If you are lucky, the mocks you need to use have already been implemented by some nice people. If, however, you find yourself in the position to write a mock class, relax - Google Mock turns this task into a fun game! (Well, almost.)
|
||||
|
||||
## How to Define It ##
|
||||
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](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.
|
||||
|
||||
After the process, you should have something like:
|
||||
|
||||
```
|
||||
#include "gmock/gmock.h" // Brings in Google Mock.
|
||||
class MockTurtle : public Turtle {
|
||||
public:
|
||||
...
|
||||
MOCK_METHOD0(PenUp, void());
|
||||
MOCK_METHOD0(PenDown, void());
|
||||
MOCK_METHOD1(Forward, void(int distance));
|
||||
MOCK_METHOD1(Turn, void(int degrees));
|
||||
MOCK_METHOD2(GoTo, void(int x, int y));
|
||||
MOCK_CONST_METHOD0(GetX, int());
|
||||
MOCK_CONST_METHOD0(GetY, int());
|
||||
};
|
||||
```
|
||||
|
||||
You don't need to define these mock methods somewhere else - the `MOCK_METHOD*` macros will generate the definitions for you. It's that simple! Once you get the hang of it, you can pump out mock classes faster than your source-control system can handle your check-ins.
|
||||
|
||||
**Tip:** If even this is too much work for you, you'll find the
|
||||
`gmock_gen.py` tool in Google Mock's `scripts/generator/` directory (courtesy of the [cppclean](http://code.google.com/p/cppclean/) project) useful. This command-line
|
||||
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](../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?)
|
||||
|
||||
So, the rule of thumb is: if you need to mock `Foo` and it's owned by others, define the mock class in `Foo`'s package (better, in a `testing` sub-package such that you can clearly separate production code and testing utilities), and put it in a `mock_foo.h`. Then everyone can reference `mock_foo.h` from their tests. If `Foo` ever changes, there is only one copy of `MockFoo` to change, and only tests that depend on the changed methods need to be fixed.
|
||||
|
||||
Another way to do it: you can introduce a thin layer `FooAdaptor` on top of `Foo` and code to this new interface. Since you own `FooAdaptor`, you can absorb changes in `Foo` much more easily. While this is more work initially, carefully choosing the adaptor interface can make your code easier to write and more readable (a net win in the long run), as you can choose `FooAdaptor` to fit your specific domain much better than `Foo` does.
|
||||
|
||||
# Using Mocks in Tests #
|
||||
Once you have a mock class, using it is easy. The typical work flow is:
|
||||
|
||||
1. Import the Google Mock names from the `testing` namespace such that you can use them unqualified (You only have to do it once per file. Remember that namespaces are a good idea and good for your health.).
|
||||
1. Create some mock objects.
|
||||
1. Specify your expectations on them (How many times will a method be called? With what arguments? What should it do? etc.).
|
||||
1. Exercise some code that uses the mocks; optionally, check the result using Google Test assertions. If a mock method is called more than expected or with wrong arguments, you'll get an error immediately.
|
||||
1. When a mock is destructed, Google Mock will automatically check whether all expectations on it have been satisfied.
|
||||
|
||||
Here's an example:
|
||||
|
||||
```
|
||||
#include "path/to/mock-turtle.h"
|
||||
#include "gmock/gmock.h"
|
||||
#include "gtest/gtest.h"
|
||||
using ::testing::AtLeast; // #1
|
||||
|
||||
TEST(PainterTest, CanDrawSomething) {
|
||||
MockTurtle turtle; // #2
|
||||
EXPECT_CALL(turtle, PenDown()) // #3
|
||||
.Times(AtLeast(1));
|
||||
|
||||
Painter painter(&turtle); // #4
|
||||
|
||||
EXPECT_TRUE(painter.DrawCircle(0, 0, 10));
|
||||
} // #5
|
||||
|
||||
int main(int argc, char** argv) {
|
||||
// The following line must be executed to initialize Google Mock
|
||||
// (and Google Test) before running the tests.
|
||||
::testing::InitGoogleMock(&argc, argv);
|
||||
return RUN_ALL_TESTS();
|
||||
}
|
||||
```
|
||||
|
||||
As you might have guessed, this test checks that `PenDown()` is called at least once. If the `painter` object didn't call this method, your test will fail with a message like this:
|
||||
|
||||
```
|
||||
path/to/my_test.cc:119: Failure
|
||||
Actual function call count doesn't match this expectation:
|
||||
Actually: never called;
|
||||
Expected: called at least once.
|
||||
```
|
||||
|
||||
**Tip 1:** If you run the test from an Emacs buffer, you can hit `<Enter>` on the line number displayed in the error message to jump right to the failed expectation.
|
||||
|
||||
**Tip 2:** If your mock objects are never deleted, the final verification won't happen. Therefore it's a good idea to use a heap leak checker in your tests when you allocate mocks on the heap.
|
||||
|
||||
**Important note:** Google Mock requires expectations to be set **before** the mock functions are called, otherwise the behavior is **undefined**. In particular, you mustn't interleave `EXPECT_CALL()`s and calls to the mock functions.
|
||||
|
||||
This means `EXPECT_CALL()` should be read as expecting that a call will occur _in the future_, not that a call has occurred. Why does Google Mock work like that? Well, specifying the expectation beforehand allows Google Mock to report a violation as soon as it arises, when the context (stack trace, etc) is still available. This makes debugging much easier.
|
||||
|
||||
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://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) {
|
||||
// The following line causes Google Mock to throw an exception on failure,
|
||||
// which will be interpreted by your testing framework as a test failure.
|
||||
::testing::GTEST_FLAG(throw_on_failure) = true;
|
||||
::testing::InitGoogleMock(&argc, argv);
|
||||
... whatever your testing framework requires ...
|
||||
}
|
||||
```
|
||||
|
||||
This approach has a catch: it makes Google Mock throw an exception
|
||||
from a mock object's destructor sometimes. With some compilers, this
|
||||
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](../../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.
|
||||
|
||||
If this turns out to be too much work, we suggest that you stick with
|
||||
Google Test, which works with Google Mock seamlessly (in fact, it is
|
||||
technically part of Google Mock.). If there is a reason that you
|
||||
cannot use Google Test, please let us know.
|
||||
|
||||
# Setting Expectations #
|
||||
The key to using a mock object successfully is to set the _right expectations_ on it. If you set the expectations too strict, your test will fail as the result of unrelated changes. If you set them too loose, bugs can slip through. You want to do it just right such that your test can catch exactly the kind of bugs you intend it to catch. Google Mock provides the necessary means for you to do it "just right."
|
||||
|
||||
## General Syntax ##
|
||||
In Google Mock we use the `EXPECT_CALL()` macro to set an expectation on a mock method. The general syntax is:
|
||||
|
||||
```
|
||||
EXPECT_CALL(mock_object, method(matchers))
|
||||
.Times(cardinality)
|
||||
.WillOnce(action)
|
||||
.WillRepeatedly(action);
|
||||
```
|
||||
|
||||
The macro has two arguments: first the mock object, and then the method and its arguments. Note that the two are separated by a comma (`,`), not a period (`.`). (Why using a comma? The answer is that it was necessary for technical reasons.)
|
||||
|
||||
The macro can be followed by some optional _clauses_ that provide more information about the expectation. We'll discuss how each clause works in the coming sections.
|
||||
|
||||
This syntax is designed to make an expectation read like English. For example, you can probably guess that
|
||||
|
||||
```
|
||||
using ::testing::Return;...
|
||||
EXPECT_CALL(turtle, GetX())
|
||||
.Times(5)
|
||||
.WillOnce(Return(100))
|
||||
.WillOnce(Return(150))
|
||||
.WillRepeatedly(Return(200));
|
||||
```
|
||||
|
||||
says that the `turtle` object's `GetX()` method will be called five times, it will return 100 the first time, 150 the second time, and then 200 every time. Some people like to call this style of syntax a Domain-Specific Language (DSL).
|
||||
|
||||
**Note:** Why do we use a macro to do this? It serves two purposes: first it makes expectations easily identifiable (either by `grep` or by a human reader), and second it allows Google Mock to include the source file location of a failed expectation in messages, making debugging easier.
|
||||
|
||||
## Matchers: What Arguments Do We Expect? ##
|
||||
When a mock function takes arguments, we must specify what arguments we are expecting; for example:
|
||||
|
||||
```
|
||||
// Expects the turtle to move forward by 100 units.
|
||||
EXPECT_CALL(turtle, Forward(100));
|
||||
```
|
||||
|
||||
Sometimes you may not want to be too specific (Remember that talk about tests being too rigid? Over specification leads to brittle tests and obscures the intent of tests. Therefore we encourage you to specify only what's necessary - no more, no less.). If you care to check that `Forward()` will be called but aren't interested in its actual argument, write `_` as the argument, which means "anything goes":
|
||||
|
||||
```
|
||||
using ::testing::_;
|
||||
...
|
||||
// Expects the turtle to move forward.
|
||||
EXPECT_CALL(turtle, Forward(_));
|
||||
```
|
||||
|
||||
`_` is an instance of what we call **matchers**. A matcher is like a predicate and can test whether an argument is what we'd expect. You can use a matcher inside `EXPECT_CALL()` wherever a function argument is expected.
|
||||
|
||||
A list of built-in matchers can be found in the [CheatSheet](CheatSheet.md). For example, here's the `Ge` (greater than or equal) matcher:
|
||||
|
||||
```
|
||||
using ::testing::Ge;...
|
||||
EXPECT_CALL(turtle, Forward(Ge(100)));
|
||||
```
|
||||
|
||||
This checks that the turtle will be told to go forward by at least 100 units.
|
||||
|
||||
## Cardinalities: How Many Times Will It Be Called? ##
|
||||
The first clause we can specify following an `EXPECT_CALL()` is `Times()`. We call its argument a **cardinality** as it tells _how many times_ the call should occur. It allows us to repeat an expectation many times without actually writing it as many times. More importantly, a cardinality can be "fuzzy", just like a matcher can be. This allows a user to express the intent of a test exactly.
|
||||
|
||||
An interesting special case is when we say `Times(0)`. You may have guessed - it means that the function shouldn't be called with the given arguments at all, and Google Mock will report a Google Test failure whenever the function is (wrongfully) called.
|
||||
|
||||
We've seen `AtLeast(n)` as an example of fuzzy cardinalities earlier. For the list of built-in cardinalities you can use, see the [CheatSheet](CheatSheet.md).
|
||||
|
||||
The `Times()` clause can be omitted. **If you omit `Times()`, Google Mock will infer the cardinality for you.** The rules are easy to remember:
|
||||
|
||||
* If **neither** `WillOnce()` **nor** `WillRepeatedly()` is in the `EXPECT_CALL()`, the inferred cardinality is `Times(1)`.
|
||||
* If there are `n WillOnce()`'s but **no** `WillRepeatedly()`, where `n` >= 1, the cardinality is `Times(n)`.
|
||||
* If there are `n WillOnce()`'s and **one** `WillRepeatedly()`, where `n` >= 0, the cardinality is `Times(AtLeast(n))`.
|
||||
|
||||
**Quick quiz:** what do you think will happen if a function is expected to be called twice but actually called four times?
|
||||
|
||||
## Actions: What Should It Do? ##
|
||||
Remember that a mock object doesn't really have a working implementation? We as users have to tell it what to do when a method is invoked. This is easy in Google Mock.
|
||||
|
||||
First, if the return type of a mock function is a built-in type or a pointer, the function has a **default action** (a `void` function will just return, a `bool` function will return `false`, and other functions will return 0). In addition, in C++ 11 and above, a mock function whose return type is default-constructible (i.e. has a default constructor) has a default action of returning a default-constructed value. If you don't say anything, this behavior will be used.
|
||||
|
||||
Second, if a mock function doesn't have a default action, or the default action doesn't suit you, you can specify the action to be taken each time the expectation matches using a series of `WillOnce()` clauses followed by an optional `WillRepeatedly()`. For example,
|
||||
|
||||
```
|
||||
using ::testing::Return;...
|
||||
EXPECT_CALL(turtle, GetX())
|
||||
.WillOnce(Return(100))
|
||||
.WillOnce(Return(200))
|
||||
.WillOnce(Return(300));
|
||||
```
|
||||
|
||||
This says that `turtle.GetX()` will be called _exactly three times_ (Google Mock inferred this from how many `WillOnce()` clauses we've written, since we didn't explicitly write `Times()`), and will return 100, 200, and 300 respectively.
|
||||
|
||||
```
|
||||
using ::testing::Return;...
|
||||
EXPECT_CALL(turtle, GetY())
|
||||
.WillOnce(Return(100))
|
||||
.WillOnce(Return(200))
|
||||
.WillRepeatedly(Return(300));
|
||||
```
|
||||
|
||||
says that `turtle.GetY()` will be called _at least twice_ (Google Mock knows this as we've written two `WillOnce()` clauses and a `WillRepeatedly()` while having no explicit `Times()`), will return 100 the first time, 200 the second time, and 300 from the third time on.
|
||||
|
||||
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](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:
|
||||
|
||||
```
|
||||
int n = 100;
|
||||
EXPECT_CALL(turtle, GetX())
|
||||
.Times(4)
|
||||
.WillRepeatedly(Return(n++));
|
||||
```
|
||||
|
||||
Instead of returning 100, 101, 102, ..., consecutively, this mock function will always return 100 as `n++` is only evaluated once. Similarly, `Return(new Foo)` will create a new `Foo` object when the `EXPECT_CALL()` is executed, and will return the same pointer every time. If you want the side effect to happen every time, you need to define a custom action, which we'll teach in the [CookBook](CookBook.md).
|
||||
|
||||
Time for another quiz! What do you think the following means?
|
||||
|
||||
```
|
||||
using ::testing::Return;...
|
||||
EXPECT_CALL(turtle, GetY())
|
||||
.Times(4)
|
||||
.WillOnce(Return(100));
|
||||
```
|
||||
|
||||
Obviously `turtle.GetY()` is expected to be called four times. But if you think it will return 100 every time, think twice! Remember that one `WillOnce()` clause will be consumed each time the function is invoked and the default action will be taken afterwards. So the right answer is that `turtle.GetY()` will return 100 the first time, but **return 0 from the second time on**, as returning 0 is the default action for `int` functions.
|
||||
|
||||
## Using Multiple Expectations ##
|
||||
So far we've only shown examples where you have a single expectation. More realistically, you're going to specify expectations on multiple mock methods, which may be from multiple mock objects.
|
||||
|
||||
By default, when a mock method is invoked, Google Mock will search the expectations in the **reverse order** they are defined, and stop when an active expectation that matches the arguments is found (you can think of it as "newer rules override older ones."). If the matching expectation cannot take any more calls, you will get an upper-bound-violated failure. Here's an example:
|
||||
|
||||
```
|
||||
using ::testing::_;...
|
||||
EXPECT_CALL(turtle, Forward(_)); // #1
|
||||
EXPECT_CALL(turtle, Forward(10)) // #2
|
||||
.Times(2);
|
||||
```
|
||||
|
||||
If `Forward(10)` is called three times in a row, the third time it will be an error, as the last matching expectation (#2) has been saturated. If, however, the third `Forward(10)` call is replaced by `Forward(20)`, then it would be OK, as now #1 will be the matching expectation.
|
||||
|
||||
**Side note:** Why does Google Mock search for a match in the _reverse_ order of the expectations? The reason is that this allows a user to set up the default expectations in a mock object's constructor or the test fixture's set-up phase and then customize the mock by writing more specific expectations in the test body. So, if you have two expectations on the same method, you want to put the one with more specific matchers **after** the other, or the more specific rule would be shadowed by the more general one that comes after it.
|
||||
|
||||
## Ordered vs Unordered Calls ##
|
||||
By default, an expectation can match a call even though an earlier expectation hasn't been satisfied. In other words, the calls don't have to occur in the order the expectations are specified.
|
||||
|
||||
Sometimes, you may want all the expected calls to occur in a strict order. To say this in Google Mock is easy:
|
||||
|
||||
```
|
||||
using ::testing::InSequence;...
|
||||
TEST(FooTest, DrawsLineSegment) {
|
||||
...
|
||||
{
|
||||
InSequence dummy;
|
||||
|
||||
EXPECT_CALL(turtle, PenDown());
|
||||
EXPECT_CALL(turtle, Forward(100));
|
||||
EXPECT_CALL(turtle, PenUp());
|
||||
}
|
||||
Foo();
|
||||
}
|
||||
```
|
||||
|
||||
By creating an object of type `InSequence`, all expectations in its scope are put into a _sequence_ and have to occur _sequentially_. Since we are just relying on the constructor and destructor of this object to do the actual work, its name is really irrelevant.
|
||||
|
||||
In this example, we test that `Foo()` calls the three expected functions in the order as written. If a call is made out-of-order, it will be an error.
|
||||
|
||||
(What if you care about the relative order of some of the calls, but not all of them? Can you specify an arbitrary partial order? The answer is ... yes! If you are impatient, the details can be found in the [CookBook](CookBook#Expecting_Partially_Ordered_Calls.md).)
|
||||
|
||||
## All Expectations Are Sticky (Unless Said Otherwise) ##
|
||||
Now let's do a quick quiz to see how well you can use this mock stuff already. How would you test that the turtle is asked to go to the origin _exactly twice_ (you want to ignore any other instructions it receives)?
|
||||
|
||||
After you've come up with your answer, take a look at ours and compare notes (solve it yourself first - don't cheat!):
|
||||
|
||||
```
|
||||
using ::testing::_;...
|
||||
EXPECT_CALL(turtle, GoTo(_, _)) // #1
|
||||
.Times(AnyNumber());
|
||||
EXPECT_CALL(turtle, GoTo(0, 0)) // #2
|
||||
.Times(2);
|
||||
```
|
||||
|
||||
Suppose `turtle.GoTo(0, 0)` is called three times. In the third time, Google Mock will see that the arguments match expectation #2 (remember that we always pick the last matching expectation). Now, since we said that there should be only two such calls, Google Mock will report an error immediately. This is basically what we've told you in the "Using Multiple Expectations" section above.
|
||||
|
||||
This example shows that **expectations in Google Mock are "sticky" by default**, in the sense that they remain active even after we have reached their invocation upper bounds. This is an important rule to remember, as it affects the meaning of the spec, and is **different** to how it's done in many other mocking frameworks (Why'd we do that? Because we think our rule makes the common cases easier to express and understand.).
|
||||
|
||||
Simple? Let's see if you've really understood it: what does the following code say?
|
||||
|
||||
```
|
||||
using ::testing::Return;
|
||||
...
|
||||
for (int i = n; i > 0; i--) {
|
||||
EXPECT_CALL(turtle, GetX())
|
||||
.WillOnce(Return(10*i));
|
||||
}
|
||||
```
|
||||
|
||||
If you think it says that `turtle.GetX()` will be called `n` times and will return 10, 20, 30, ..., consecutively, think twice! The problem is that, as we said, expectations are sticky. So, the second time `turtle.GetX()` is called, the last (latest) `EXPECT_CALL()` statement will match, and will immediately lead to an "upper bound exceeded" error - this piece of code is not very useful!
|
||||
|
||||
One correct way of saying that `turtle.GetX()` will return 10, 20, 30, ..., is to explicitly say that the expectations are _not_ sticky. In other words, they should _retire_ as soon as they are saturated:
|
||||
|
||||
```
|
||||
using ::testing::Return;
|
||||
...
|
||||
for (int i = n; i > 0; i--) {
|
||||
EXPECT_CALL(turtle, GetX())
|
||||
.WillOnce(Return(10*i))
|
||||
.RetiresOnSaturation();
|
||||
}
|
||||
```
|
||||
|
||||
And, there's a better way to do it: in this case, we expect the calls to occur in a specific order, and we line up the actions to match the order. Since the order is important here, we should make it explicit using a sequence:
|
||||
|
||||
```
|
||||
using ::testing::InSequence;
|
||||
using ::testing::Return;
|
||||
...
|
||||
{
|
||||
InSequence s;
|
||||
|
||||
for (int i = 1; i <= n; i++) {
|
||||
EXPECT_CALL(turtle, GetX())
|
||||
.WillOnce(Return(10*i))
|
||||
.RetiresOnSaturation();
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
By the way, the other situation where an expectation may _not_ be sticky is when it's in a sequence - as soon as another expectation that comes after it in the sequence has been used, it automatically retires (and will never be used to match any call).
|
||||
|
||||
## Uninteresting Calls ##
|
||||
A mock object may have many methods, and not all of them are that interesting. For example, in some tests we may not care about how many times `GetX()` and `GetY()` get called.
|
||||
|
||||
In Google Mock, if you are not interested in a method, just don't say anything about it. If a call to this method occurs, you'll see a warning in the test output, but it won't be a failure.
|
||||
|
||||
# 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.
|
||||
628
test/gtest-1.8.0/googlemock/docs/FrequentlyAskedQuestions.md
Normal file
628
test/gtest-1.8.0/googlemock/docs/FrequentlyAskedQuestions.md
Normal file
@@ -0,0 +1,628 @@
|
||||
|
||||
|
||||
Please send your questions to the
|
||||
[googlemock](http://groups.google.com/group/googlemock) discussion
|
||||
group. If you need help with compiler errors, make sure you have
|
||||
tried [Google Mock Doctor](#How_am_I_supposed_to_make_sense_of_these_horrible_template_error.md) first.
|
||||
|
||||
## 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](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? ##
|
||||
|
||||
After version 1.4.0 of Google Mock was released, we had an idea on how
|
||||
to make it easier to write matchers that can generate informative
|
||||
messages efficiently. We experimented with this idea and liked what
|
||||
we saw. Therefore we decided to implement it.
|
||||
|
||||
Unfortunately, this means that if you have defined your own matchers
|
||||
by implementing `MatcherInterface` or using `MakePolymorphicMatcher()`,
|
||||
your definitions will no longer compile. Matchers defined using the
|
||||
`MATCHER*` family of macros are not affected.
|
||||
|
||||
Sorry for the hassle if your matchers are affected. We believe it's
|
||||
in everyone's long-term interest to make this change sooner than
|
||||
later. Fortunately, it's usually not hard to migrate an existing
|
||||
matcher to the new API. Here's what you need to do:
|
||||
|
||||
If you wrote your matcher like this:
|
||||
```
|
||||
// Old matcher definition that doesn't work with the latest
|
||||
// Google Mock.
|
||||
using ::testing::MatcherInterface;
|
||||
...
|
||||
class MyWonderfulMatcher : public MatcherInterface<MyType> {
|
||||
public:
|
||||
...
|
||||
virtual bool Matches(MyType value) const {
|
||||
// Returns true if value matches.
|
||||
return value.GetFoo() > 5;
|
||||
}
|
||||
...
|
||||
};
|
||||
```
|
||||
|
||||
you'll need to change it to:
|
||||
```
|
||||
// New matcher definition that works with the latest Google Mock.
|
||||
using ::testing::MatcherInterface;
|
||||
using ::testing::MatchResultListener;
|
||||
...
|
||||
class MyWonderfulMatcher : public MatcherInterface<MyType> {
|
||||
public:
|
||||
...
|
||||
virtual bool MatchAndExplain(MyType value,
|
||||
MatchResultListener* listener) const {
|
||||
// Returns true if value matches.
|
||||
return value.GetFoo() > 5;
|
||||
}
|
||||
...
|
||||
};
|
||||
```
|
||||
(i.e. rename `Matches()` to `MatchAndExplain()` and give it a second
|
||||
argument of type `MatchResultListener*`.)
|
||||
|
||||
If you were also using `ExplainMatchResultTo()` to improve the matcher
|
||||
message:
|
||||
```
|
||||
// Old matcher definition that doesn't work with the lastest
|
||||
// Google Mock.
|
||||
using ::testing::MatcherInterface;
|
||||
...
|
||||
class MyWonderfulMatcher : public MatcherInterface<MyType> {
|
||||
public:
|
||||
...
|
||||
virtual bool Matches(MyType value) const {
|
||||
// Returns true if value matches.
|
||||
return value.GetFoo() > 5;
|
||||
}
|
||||
|
||||
virtual void ExplainMatchResultTo(MyType value,
|
||||
::std::ostream* os) const {
|
||||
// Prints some helpful information to os to help
|
||||
// a user understand why value matches (or doesn't match).
|
||||
*os << "the Foo property is " << value.GetFoo();
|
||||
}
|
||||
...
|
||||
};
|
||||
```
|
||||
|
||||
you should move the logic of `ExplainMatchResultTo()` into
|
||||
`MatchAndExplain()`, using the `MatchResultListener` argument where
|
||||
the `::std::ostream` was used:
|
||||
```
|
||||
// New matcher definition that works with the latest Google Mock.
|
||||
using ::testing::MatcherInterface;
|
||||
using ::testing::MatchResultListener;
|
||||
...
|
||||
class MyWonderfulMatcher : public MatcherInterface<MyType> {
|
||||
public:
|
||||
...
|
||||
virtual bool MatchAndExplain(MyType value,
|
||||
MatchResultListener* listener) const {
|
||||
// Returns true if value matches.
|
||||
*listener << "the Foo property is " << value.GetFoo();
|
||||
return value.GetFoo() > 5;
|
||||
}
|
||||
...
|
||||
};
|
||||
```
|
||||
|
||||
If your matcher is defined using `MakePolymorphicMatcher()`:
|
||||
```
|
||||
// Old matcher definition that doesn't work with the latest
|
||||
// Google Mock.
|
||||
using ::testing::MakePolymorphicMatcher;
|
||||
...
|
||||
class MyGreatMatcher {
|
||||
public:
|
||||
...
|
||||
bool Matches(MyType value) const {
|
||||
// Returns true if value matches.
|
||||
return value.GetBar() < 42;
|
||||
}
|
||||
...
|
||||
};
|
||||
... MakePolymorphicMatcher(MyGreatMatcher()) ...
|
||||
```
|
||||
|
||||
you should rename the `Matches()` method to `MatchAndExplain()` and
|
||||
add a `MatchResultListener*` argument (the same as what you need to do
|
||||
for matchers defined by implementing `MatcherInterface`):
|
||||
```
|
||||
// New matcher definition that works with the latest Google Mock.
|
||||
using ::testing::MakePolymorphicMatcher;
|
||||
using ::testing::MatchResultListener;
|
||||
...
|
||||
class MyGreatMatcher {
|
||||
public:
|
||||
...
|
||||
bool MatchAndExplain(MyType value,
|
||||
MatchResultListener* listener) const {
|
||||
// Returns true if value matches.
|
||||
return value.GetBar() < 42;
|
||||
}
|
||||
...
|
||||
};
|
||||
... MakePolymorphicMatcher(MyGreatMatcher()) ...
|
||||
```
|
||||
|
||||
If your polymorphic matcher uses `ExplainMatchResultTo()` for better
|
||||
failure messages:
|
||||
```
|
||||
// Old matcher definition that doesn't work with the latest
|
||||
// Google Mock.
|
||||
using ::testing::MakePolymorphicMatcher;
|
||||
...
|
||||
class MyGreatMatcher {
|
||||
public:
|
||||
...
|
||||
bool Matches(MyType value) const {
|
||||
// Returns true if value matches.
|
||||
return value.GetBar() < 42;
|
||||
}
|
||||
...
|
||||
};
|
||||
void ExplainMatchResultTo(const MyGreatMatcher& matcher,
|
||||
MyType value,
|
||||
::std::ostream* os) {
|
||||
// Prints some helpful information to os to help
|
||||
// a user understand why value matches (or doesn't match).
|
||||
*os << "the Bar property is " << value.GetBar();
|
||||
}
|
||||
... MakePolymorphicMatcher(MyGreatMatcher()) ...
|
||||
```
|
||||
|
||||
you'll need to move the logic inside `ExplainMatchResultTo()` to
|
||||
`MatchAndExplain()`:
|
||||
```
|
||||
// New matcher definition that works with the latest Google Mock.
|
||||
using ::testing::MakePolymorphicMatcher;
|
||||
using ::testing::MatchResultListener;
|
||||
...
|
||||
class MyGreatMatcher {
|
||||
public:
|
||||
...
|
||||
bool MatchAndExplain(MyType value,
|
||||
MatchResultListener* listener) const {
|
||||
// Returns true if value matches.
|
||||
*listener << "the Bar property is " << value.GetBar();
|
||||
return value.GetBar() < 42;
|
||||
}
|
||||
...
|
||||
};
|
||||
... MakePolymorphicMatcher(MyGreatMatcher()) ...
|
||||
```
|
||||
|
||||
For more information, you can read these
|
||||
[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.
|
||||
|
||||
## When using Google Mock, do I have to use Google Test as the testing framework? I have my favorite testing framework and don't want to switch. ##
|
||||
|
||||
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](ForDummies.md#using-google-mock-with-any-testing-framework) is how.
|
||||
|
||||
## How am I supposed to make sense of these horrible template errors? ##
|
||||
|
||||
If you are confused by the compiler errors gcc threw at you,
|
||||
try consulting the _Google Mock Doctor_ tool first. What it does is to
|
||||
scan stdin for gcc error messages, and spit out diagnoses on the
|
||||
problems (we call them diseases) your code has.
|
||||
|
||||
To "install", run command:
|
||||
```
|
||||
alias gmd='<path to googlemock>/scripts/gmock_doctor.py'
|
||||
```
|
||||
|
||||
To use it, do:
|
||||
```
|
||||
<your-favorite-build-command> <your-test> 2>&1 | gmd
|
||||
```
|
||||
|
||||
For example:
|
||||
```
|
||||
make my_test 2>&1 | gmd
|
||||
```
|
||||
|
||||
Or you can run `gmd` and copy-n-paste gcc's error messages to it.
|
||||
|
||||
## Can I mock a variadic function? ##
|
||||
|
||||
You cannot mock a variadic function (i.e. a function taking ellipsis
|
||||
(`...`) arguments) directly in Google Mock.
|
||||
|
||||
The problem is that in general, there is _no way_ for a mock object to
|
||||
know how many arguments are passed to the variadic method, and what
|
||||
the arguments' types are. Only the _author of the base class_ knows
|
||||
the protocol, and we cannot look into his head.
|
||||
|
||||
Therefore, to mock such a function, the _user_ must teach the mock
|
||||
object how to figure out the number of arguments and their types. One
|
||||
way to do it is to provide overloaded versions of the function.
|
||||
|
||||
Ellipsis arguments are inherited from C and not really a C++ feature.
|
||||
They are unsafe to use and don't work with arguments that have
|
||||
constructors or destructors. Therefore we recommend to avoid them in
|
||||
C++ as much as possible.
|
||||
|
||||
## MSVC gives me warning C4301 or C4373 when I define a mock method with a const parameter. Why? ##
|
||||
|
||||
If you compile this using Microsoft Visual C++ 2005 SP1:
|
||||
```
|
||||
class Foo {
|
||||
...
|
||||
virtual void Bar(const int i) = 0;
|
||||
};
|
||||
|
||||
class MockFoo : public Foo {
|
||||
...
|
||||
MOCK_METHOD1(Bar, void(const int i));
|
||||
};
|
||||
```
|
||||
You may get the following warning:
|
||||
```
|
||||
warning C4301: 'MockFoo::Bar': overriding virtual function only differs from 'Foo::Bar' by const/volatile qualifier
|
||||
```
|
||||
|
||||
This is a MSVC bug. The same code compiles fine with gcc ,for
|
||||
example. If you use Visual C++ 2008 SP1, you would get the warning:
|
||||
```
|
||||
warning C4373: 'MockFoo::Bar': virtual function overrides 'Foo::Bar', previous versions of the compiler did not override when parameters only differed by const/volatile qualifiers
|
||||
```
|
||||
|
||||
In C++, if you _declare_ a function with a `const` parameter, the
|
||||
`const` modifier is _ignored_. Therefore, the `Foo` base class above
|
||||
is equivalent to:
|
||||
```
|
||||
class Foo {
|
||||
...
|
||||
virtual void Bar(int i) = 0; // int or const int? Makes no difference.
|
||||
};
|
||||
```
|
||||
|
||||
In fact, you can _declare_ Bar() with an `int` parameter, and _define_
|
||||
it with a `const int` parameter. The compiler will still match them
|
||||
up.
|
||||
|
||||
Since making a parameter `const` is meaningless in the method
|
||||
_declaration_, we recommend to remove it in both `Foo` and `MockFoo`.
|
||||
That should workaround the VC bug.
|
||||
|
||||
Note that we are talking about the _top-level_ `const` modifier here.
|
||||
If the function parameter is passed by pointer or reference, declaring
|
||||
the _pointee_ or _referee_ as `const` is still meaningful. For
|
||||
example, the following two declarations are _not_ equivalent:
|
||||
```
|
||||
void Bar(int* p); // Neither p nor *p is const.
|
||||
void Bar(const int* p); // p is not const, but *p is.
|
||||
```
|
||||
|
||||
## I have a huge mock class, and Microsoft Visual C++ runs out of memory when compiling it. What can I do? ##
|
||||
|
||||
We've noticed that when the `/clr` compiler flag is used, Visual C++
|
||||
uses 5~6 times as much memory when compiling a mock class. We suggest
|
||||
to avoid `/clr` when compiling native C++ mocks.
|
||||
|
||||
## I can't figure out why Google Mock thinks my expectations are not satisfied. What should I do? ##
|
||||
|
||||
You might want to run your test with
|
||||
`--gmock_verbose=info`. This flag lets Google Mock print a trace
|
||||
of every mock function call it receives. By studying the trace,
|
||||
you'll gain insights on why the expectations you set are not met.
|
||||
|
||||
## How can I assert that a function is NEVER called? ##
|
||||
|
||||
```
|
||||
EXPECT_CALL(foo, Bar(_))
|
||||
.Times(0);
|
||||
```
|
||||
|
||||
## I have a failed test where Google Mock tells me TWICE that a particular expectation is not satisfied. Isn't this redundant? ##
|
||||
|
||||
When Google Mock detects a failure, it prints relevant information
|
||||
(the mock function arguments, the state of relevant expectations, and
|
||||
etc) to help the user debug. If another failure is detected, Google
|
||||
Mock will do the same, including printing the state of relevant
|
||||
expectations.
|
||||
|
||||
Sometimes an expectation's state didn't change between two failures,
|
||||
and you'll see the same description of the state twice. They are
|
||||
however _not_ redundant, as they refer to _different points in time_.
|
||||
The fact they are the same _is_ interesting information.
|
||||
|
||||
## I get a heap check failure when using a mock object, but using a real object is fine. What can be wrong? ##
|
||||
|
||||
Does the class (hopefully a pure interface) you are mocking have a
|
||||
virtual destructor?
|
||||
|
||||
Whenever you derive from a base class, make sure its destructor is
|
||||
virtual. Otherwise Bad Things will happen. Consider the following
|
||||
code:
|
||||
|
||||
```
|
||||
class Base {
|
||||
public:
|
||||
// Not virtual, but should be.
|
||||
~Base() { ... }
|
||||
...
|
||||
};
|
||||
|
||||
class Derived : public Base {
|
||||
public:
|
||||
...
|
||||
private:
|
||||
std::string value_;
|
||||
};
|
||||
|
||||
...
|
||||
Base* p = new Derived;
|
||||
...
|
||||
delete p; // Surprise! ~Base() will be called, but ~Derived() will not
|
||||
// - value_ is leaked.
|
||||
```
|
||||
|
||||
By changing `~Base()` to virtual, `~Derived()` will be correctly
|
||||
called when `delete p` is executed, and the heap checker
|
||||
will be happy.
|
||||
|
||||
## The "newer expectations override older ones" rule makes writing expectations awkward. Why does Google Mock do that? ##
|
||||
|
||||
When people complain about this, often they are referring to code like:
|
||||
|
||||
```
|
||||
// foo.Bar() should be called twice, return 1 the first time, and return
|
||||
// 2 the second time. However, I have to write the expectations in the
|
||||
// reverse order. This sucks big time!!!
|
||||
EXPECT_CALL(foo, Bar())
|
||||
.WillOnce(Return(2))
|
||||
.RetiresOnSaturation();
|
||||
EXPECT_CALL(foo, Bar())
|
||||
.WillOnce(Return(1))
|
||||
.RetiresOnSaturation();
|
||||
```
|
||||
|
||||
The problem is that they didn't pick the **best** way to express the test's
|
||||
intent.
|
||||
|
||||
By default, expectations don't have to be matched in _any_ particular
|
||||
order. If you want them to match in a certain order, you need to be
|
||||
explicit. This is Google Mock's (and jMock's) fundamental philosophy: it's
|
||||
easy to accidentally over-specify your tests, and we want to make it
|
||||
harder to do so.
|
||||
|
||||
There are two better ways to write the test spec. You could either
|
||||
put the expectations in sequence:
|
||||
|
||||
```
|
||||
// foo.Bar() should be called twice, return 1 the first time, and return
|
||||
// 2 the second time. Using a sequence, we can write the expectations
|
||||
// in their natural order.
|
||||
{
|
||||
InSequence s;
|
||||
EXPECT_CALL(foo, Bar())
|
||||
.WillOnce(Return(1))
|
||||
.RetiresOnSaturation();
|
||||
EXPECT_CALL(foo, Bar())
|
||||
.WillOnce(Return(2))
|
||||
.RetiresOnSaturation();
|
||||
}
|
||||
```
|
||||
|
||||
or you can put the sequence of actions in the same expectation:
|
||||
|
||||
```
|
||||
// foo.Bar() should be called twice, return 1 the first time, and return
|
||||
// 2 the second time.
|
||||
EXPECT_CALL(foo, Bar())
|
||||
.WillOnce(Return(1))
|
||||
.WillOnce(Return(2))
|
||||
.RetiresOnSaturation();
|
||||
```
|
||||
|
||||
Back to the original questions: why does Google Mock search the
|
||||
expectations (and `ON_CALL`s) from back to front? Because this
|
||||
allows a user to set up a mock's behavior for the common case early
|
||||
(e.g. in the mock's constructor or the test fixture's set-up phase)
|
||||
and customize it with more specific rules later. If Google Mock
|
||||
searches from front to back, this very useful pattern won't be
|
||||
possible.
|
||||
|
||||
## Google Mock prints a warning when a function without EXPECT\_CALL is called, even if I have set its behavior using ON\_CALL. Would it be reasonable not to show the warning in this case? ##
|
||||
|
||||
When choosing between being neat and being safe, we lean toward the
|
||||
latter. So the answer is that we think it's better to show the
|
||||
warning.
|
||||
|
||||
Often people write `ON_CALL`s in the mock object's
|
||||
constructor or `SetUp()`, as the default behavior rarely changes from
|
||||
test to test. Then in the test body they set the expectations, which
|
||||
are often different for each test. Having an `ON_CALL` in the set-up
|
||||
part of a test doesn't mean that the calls are expected. If there's
|
||||
no `EXPECT_CALL` and the method is called, it's possibly an error. If
|
||||
we quietly let the call go through without notifying the user, bugs
|
||||
may creep in unnoticed.
|
||||
|
||||
If, however, you are sure that the calls are OK, you can write
|
||||
|
||||
```
|
||||
EXPECT_CALL(foo, Bar(_))
|
||||
.WillRepeatedly(...);
|
||||
```
|
||||
|
||||
instead of
|
||||
|
||||
```
|
||||
ON_CALL(foo, Bar(_))
|
||||
.WillByDefault(...);
|
||||
```
|
||||
|
||||
This tells Google Mock that you do expect the calls and no warning should be
|
||||
printed.
|
||||
|
||||
Also, you can control the verbosity using the `--gmock_verbose` flag.
|
||||
If you find the output too noisy when debugging, just choose a less
|
||||
verbose level.
|
||||
|
||||
## How can I delete the mock function's argument in an action? ##
|
||||
|
||||
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()](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()](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? ##
|
||||
|
||||
What?! I think it's beautiful. :-)
|
||||
|
||||
While which syntax looks more natural is a subjective matter to some
|
||||
extent, Google Mock's syntax was chosen for several practical advantages it
|
||||
has.
|
||||
|
||||
Try to mock a function that takes a map as an argument:
|
||||
```
|
||||
virtual int GetSize(const map<int, std::string>& m);
|
||||
```
|
||||
|
||||
Using the proposed syntax, it would be:
|
||||
```
|
||||
MOCK_METHOD1(GetSize, int, const map<int, std::string>& m);
|
||||
```
|
||||
|
||||
Guess what? You'll get a compiler error as the compiler thinks that
|
||||
`const map<int, std::string>& m` are **two**, not one, arguments. To work
|
||||
around this you can use `typedef` to give the map type a name, but
|
||||
that gets in the way of your work. Google Mock's syntax avoids this
|
||||
problem as the function's argument types are protected inside a pair
|
||||
of parentheses:
|
||||
```
|
||||
// This compiles fine.
|
||||
MOCK_METHOD1(GetSize, int(const map<int, std::string>& m));
|
||||
```
|
||||
|
||||
You still need a `typedef` if the return type contains an unprotected
|
||||
comma, but that's much rarer.
|
||||
|
||||
Other advantages include:
|
||||
1. `MOCK_METHOD1(Foo, int, bool)` can leave a reader wonder whether the method returns `int` or `bool`, while there won't be such confusion using Google Mock's syntax.
|
||||
1. The way Google Mock describes a function type is nothing new, although many people may not be familiar with it. The same syntax was used in C, and the `function` library in `tr1` uses this syntax extensively. Since `tr1` will become a part of the new version of STL, we feel very comfortable to be consistent with it.
|
||||
1. The function type syntax is also used in other parts of Google Mock's API (e.g. the action interface) in order to make the implementation tractable. A user needs to learn it anyway in order to utilize Google Mock's more advanced features. We'd as well stick to the same syntax in `MOCK_METHOD*`!
|
||||
|
||||
## My code calls a static/global function. Can I mock it? ##
|
||||
|
||||
You can, but you need to make some changes.
|
||||
|
||||
In general, if you find yourself needing to mock a static function,
|
||||
it's a sign that your modules are too tightly coupled (and less
|
||||
flexible, less reusable, less testable, etc). You are probably better
|
||||
off defining a small interface and call the function through that
|
||||
interface, which then can be easily mocked. It's a bit of work
|
||||
initially, but usually pays for itself quickly.
|
||||
|
||||
This Google Testing Blog
|
||||
[post](http://googletesting.blogspot.com/2008/06/defeat-static-cling.html)
|
||||
says it excellently. Check it out.
|
||||
|
||||
## My mock object needs to do complex stuff. It's a lot of pain to specify the actions. Google Mock sucks! ##
|
||||
|
||||
I know it's not a question, but you get an answer for free any way. :-)
|
||||
|
||||
With Google Mock, you can create mocks in C++ easily. And people might be
|
||||
tempted to use them everywhere. Sometimes they work great, and
|
||||
sometimes you may find them, well, a pain to use. So, what's wrong in
|
||||
the latter case?
|
||||
|
||||
When you write a test without using mocks, you exercise the code and
|
||||
assert that it returns the correct value or that the system is in an
|
||||
expected state. This is sometimes called "state-based testing".
|
||||
|
||||
Mocks are great for what some call "interaction-based" testing:
|
||||
instead of checking the system state at the very end, mock objects
|
||||
verify that they are invoked the right way and report an error as soon
|
||||
as it arises, giving you a handle on the precise context in which the
|
||||
error was triggered. This is often more effective and economical to
|
||||
do than state-based testing.
|
||||
|
||||
If you are doing state-based testing and using a test double just to
|
||||
simulate the real object, you are probably better off using a fake.
|
||||
Using a mock in this case causes pain, as it's not a strong point for
|
||||
mocks to perform complex actions. If you experience this and think
|
||||
that mocks suck, you are just not using the right tool for your
|
||||
problem. Or, you might be trying to solve the wrong problem. :-)
|
||||
|
||||
## I got a warning "Uninteresting function call encountered - default action taken.." Should I panic? ##
|
||||
|
||||
By all means, NO! It's just an FYI.
|
||||
|
||||
What it means is that you have a mock function, you haven't set any
|
||||
expectations on it (by Google Mock's rule this means that you are not
|
||||
interested in calls to this function and therefore it can be called
|
||||
any number of times), and it is called. That's OK - you didn't say
|
||||
it's not OK to call the function!
|
||||
|
||||
What if you actually meant to disallow this function to be called, but
|
||||
forgot to write `EXPECT_CALL(foo, Bar()).Times(0)`? While
|
||||
one can argue that it's the user's fault, Google Mock tries to be nice and
|
||||
prints you a note.
|
||||
|
||||
So, when you see the message and believe that there shouldn't be any
|
||||
uninteresting calls, you should investigate what's going on. To make
|
||||
your life easier, Google Mock prints the function name and arguments
|
||||
when an uninteresting call is encountered.
|
||||
|
||||
## I want to define a custom action. Should I use Invoke() or implement the action interface? ##
|
||||
|
||||
Either way is fine - you want to choose the one that's more convenient
|
||||
for your circumstance.
|
||||
|
||||
Usually, if your action is for a particular function type, defining it
|
||||
using `Invoke()` should be easier; if your action can be used in
|
||||
functions of different types (e.g. if you are defining
|
||||
`Return(value)`), `MakePolymorphicAction()` is
|
||||
easiest. Sometimes you want precise control on what types of
|
||||
functions the action can be used in, and implementing
|
||||
`ActionInterface` is the way to go here. See the implementation of
|
||||
`Return()` in `include/gmock/gmock-actions.h` for an example.
|
||||
|
||||
## I'm using the set-argument-pointee action, and the compiler complains about "conflicting return type specified". What does it mean? ##
|
||||
|
||||
You got this error as Google Mock has no idea what value it should return
|
||||
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](CookBook.md#mocking_side_effects) for more details and an example.
|
||||
|
||||
|
||||
## My question is not 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 [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](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.
|
||||
|
||||
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 Mock you use (Google Mock 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.
|
||||
19
test/gtest-1.8.0/googlemock/docs/KnownIssues.md
Normal file
19
test/gtest-1.8.0/googlemock/docs/KnownIssues.md
Normal file
@@ -0,0 +1,19 @@
|
||||
As any non-trivial software system, Google Mock has some known limitations and problems. We are working on improving it, and welcome your help! The follow is a list of issues we know about.
|
||||
|
||||
|
||||
|
||||
## README contains outdated information on Google Mock's compatibility with other testing frameworks ##
|
||||
|
||||
The `README` file in release 1.1.0 still says that Google Mock only works with Google Test. Actually, you can configure Google Mock to work with any testing framework you choose.
|
||||
|
||||
## Tests failing on machines using Power PC CPUs (e.g. some Macs) ##
|
||||
|
||||
`gmock_output_test` and `gmock-printers_test` are known to fail with Power PC CPUs. This is due to portability issues with these tests, and is not an indication of problems in Google Mock itself. You can safely ignore them.
|
||||
|
||||
## Failed to resolve libgtest.so.0 in tests when built against installed Google Test ##
|
||||
|
||||
This only applies if you manually built and installed Google Test, and then built a Google Mock against it (either explicitly, or because gtest-config was in your path post-install). In this situation, Libtool has a known issue with certain systems' ldconfig setup:
|
||||
|
||||
http://article.gmane.org/gmane.comp.sysutils.automake.general/9025
|
||||
|
||||
This requires a manual run of "sudo ldconfig" after the "sudo make install" for Google Test before any binaries which link against it can be executed. This isn't a bug in our install, but we should at least have documented it or hacked a work-around into our install. We should have one of these solutions in our next release.
|
||||
525
test/gtest-1.8.0/googlemock/docs/v1_5/CheatSheet.md
Normal file
525
test/gtest-1.8.0/googlemock/docs/v1_5/CheatSheet.md
Normal file
@@ -0,0 +1,525 @@
|
||||
|
||||
|
||||
# Defining a Mock Class #
|
||||
|
||||
## Mocking a Normal Class ##
|
||||
|
||||
Given
|
||||
```
|
||||
class Foo {
|
||||
...
|
||||
virtual ~Foo();
|
||||
virtual int GetSize() const = 0;
|
||||
virtual string Describe(const char* name) = 0;
|
||||
virtual string Describe(int type) = 0;
|
||||
virtual bool Process(Bar elem, int count) = 0;
|
||||
};
|
||||
```
|
||||
(note that `~Foo()` **must** be virtual) we can define its mock as
|
||||
```
|
||||
#include <gmock/gmock.h>
|
||||
|
||||
class MockFoo : public Foo {
|
||||
MOCK_CONST_METHOD0(GetSize, int());
|
||||
MOCK_METHOD1(Describe, string(const char* name));
|
||||
MOCK_METHOD1(Describe, string(int type));
|
||||
MOCK_METHOD2(Process, bool(Bar elem, int count));
|
||||
};
|
||||
```
|
||||
|
||||
To create a "nice" mock object which ignores all uninteresting calls,
|
||||
or a "strict" mock object, which treats them as failures:
|
||||
```
|
||||
NiceMock<MockFoo> nice_foo; // The type is a subclass of MockFoo.
|
||||
StrictMock<MockFoo> strict_foo; // The type is a subclass of MockFoo.
|
||||
```
|
||||
|
||||
## Mocking a Class Template ##
|
||||
|
||||
To mock
|
||||
```
|
||||
template <typename Elem>
|
||||
class StackInterface {
|
||||
public:
|
||||
...
|
||||
virtual ~StackInterface();
|
||||
virtual int GetSize() const = 0;
|
||||
virtual void Push(const Elem& x) = 0;
|
||||
};
|
||||
```
|
||||
(note that `~StackInterface()` **must** be virtual) just append `_T` to the `MOCK_*` macros:
|
||||
```
|
||||
template <typename Elem>
|
||||
class MockStack : public StackInterface<Elem> {
|
||||
public:
|
||||
...
|
||||
MOCK_CONST_METHOD0_T(GetSize, int());
|
||||
MOCK_METHOD1_T(Push, void(const Elem& x));
|
||||
};
|
||||
```
|
||||
|
||||
## Specifying Calling Conventions for Mock Functions ##
|
||||
|
||||
If your mock function doesn't use the default calling convention, you
|
||||
can specify it by appending `_WITH_CALLTYPE` to any of the macros
|
||||
described in the previous two sections and supplying the calling
|
||||
convention as the first argument to the macro. For example,
|
||||
```
|
||||
MOCK_METHOD_1_WITH_CALLTYPE(STDMETHODCALLTYPE, Foo, bool(int n));
|
||||
MOCK_CONST_METHOD2_WITH_CALLTYPE(STDMETHODCALLTYPE, Bar, int(double x, double y));
|
||||
```
|
||||
where `STDMETHODCALLTYPE` is defined by `<objbase.h>` on Windows.
|
||||
|
||||
# Using Mocks in Tests #
|
||||
|
||||
The typical flow is:
|
||||
1. Import the Google Mock names you need to use. All Google Mock names are in the `testing` namespace unless they are macros or otherwise noted.
|
||||
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. When a mock objects is destructed, Google Mock automatically verifies that all expectations on it have been satisfied.
|
||||
|
||||
Here is an example:
|
||||
```
|
||||
using ::testing::Return; // #1
|
||||
|
||||
TEST(BarTest, DoesThis) {
|
||||
MockFoo foo; // #2
|
||||
|
||||
ON_CALL(foo, GetSize()) // #3
|
||||
.WillByDefault(Return(1));
|
||||
// ... other default actions ...
|
||||
|
||||
EXPECT_CALL(foo, Describe(5)) // #4
|
||||
.Times(3)
|
||||
.WillRepeatedly(Return("Category 5"));
|
||||
// ... other expectations ...
|
||||
|
||||
EXPECT_EQ("good", MyProductionFunction(&foo)); // #5
|
||||
} // #6
|
||||
```
|
||||
|
||||
# Setting Default Actions #
|
||||
|
||||
Google Mock has a **built-in default action** for any function that
|
||||
returns `void`, `bool`, a numeric value, or a pointer.
|
||||
|
||||
To customize the default action for functions with return type `T` globally:
|
||||
```
|
||||
using ::testing::DefaultValue;
|
||||
|
||||
DefaultValue<T>::Set(value); // Sets the default value to be returned.
|
||||
// ... use the mocks ...
|
||||
DefaultValue<T>::Clear(); // Resets the default value.
|
||||
```
|
||||
|
||||
To customize the default action for a particular method, use `ON_CALL()`:
|
||||
```
|
||||
ON_CALL(mock_object, method(matchers))
|
||||
.With(multi_argument_matcher) ?
|
||||
.WillByDefault(action);
|
||||
```
|
||||
|
||||
# Setting Expectations #
|
||||
|
||||
`EXPECT_CALL()` sets **expectations** on a mock method (How will it be
|
||||
called? What will it do?):
|
||||
```
|
||||
EXPECT_CALL(mock_object, method(matchers))
|
||||
.With(multi_argument_matcher) ?
|
||||
.Times(cardinality) ?
|
||||
.InSequence(sequences) *
|
||||
.After(expectations) *
|
||||
.WillOnce(action) *
|
||||
.WillRepeatedly(action) ?
|
||||
.RetiresOnSaturation(); ?
|
||||
```
|
||||
|
||||
If `Times()` is omitted, the cardinality is assumed to be:
|
||||
|
||||
* `Times(1)` when there is neither `WillOnce()` nor `WillRepeatedly()`;
|
||||
* `Times(n)` when there are `n WillOnce()`s but no `WillRepeatedly()`, where `n` >= 1; or
|
||||
* `Times(AtLeast(n))` when there are `n WillOnce()`s and a `WillRepeatedly()`, where `n` >= 0.
|
||||
|
||||
A method with no `EXPECT_CALL()` is free to be invoked _any number of times_, and the default action will be taken each time.
|
||||
|
||||
# Matchers #
|
||||
|
||||
A **matcher** matches a _single_ argument. You can use it inside
|
||||
`ON_CALL()` or `EXPECT_CALL()`, or use it to validate a value
|
||||
directly:
|
||||
|
||||
| `EXPECT_THAT(value, matcher)` | Asserts that `value` matches `matcher`. |
|
||||
|:------------------------------|:----------------------------------------|
|
||||
| `ASSERT_THAT(value, matcher)` | The same as `EXPECT_THAT(value, matcher)`, except that it generates a **fatal** failure. |
|
||||
|
||||
Built-in matchers (where `argument` is the function argument) are
|
||||
divided into several categories:
|
||||
|
||||
## Wildcard ##
|
||||
|`_`|`argument` can be any value of the correct type.|
|
||||
|:--|:-----------------------------------------------|
|
||||
|`A<type>()` or `An<type>()`|`argument` can be any value of type `type`. |
|
||||
|
||||
## Generic Comparison ##
|
||||
|
||||
|`Eq(value)` or `value`|`argument == value`|
|
||||
|:---------------------|:------------------|
|
||||
|`Ge(value)` |`argument >= value`|
|
||||
|`Gt(value)` |`argument > value` |
|
||||
|`Le(value)` |`argument <= value`|
|
||||
|`Lt(value)` |`argument < value` |
|
||||
|`Ne(value)` |`argument != value`|
|
||||
|`IsNull()` |`argument` is a `NULL` pointer (raw or smart).|
|
||||
|`NotNull()` |`argument` is a non-null pointer (raw or smart).|
|
||||
|`Ref(variable)` |`argument` is a reference to `variable`.|
|
||||
|`TypedEq<type>(value)`|`argument` has type `type` and is equal to `value`. You may need to use this instead of `Eq(value)` when the mock function is overloaded.|
|
||||
|
||||
Except `Ref()`, these matchers make a _copy_ of `value` in case it's
|
||||
modified or destructed later. If the compiler complains that `value`
|
||||
doesn't have a public copy constructor, try wrap it in `ByRef()`,
|
||||
e.g. `Eq(ByRef(non_copyable_value))`. If you do that, make sure
|
||||
`non_copyable_value` is not changed afterwards, or the meaning of your
|
||||
matcher will be changed.
|
||||
|
||||
## Floating-Point Matchers ##
|
||||
|
||||
|`DoubleEq(a_double)`|`argument` is a `double` value approximately equal to `a_double`, treating two NaNs as unequal.|
|
||||
|:-------------------|:----------------------------------------------------------------------------------------------|
|
||||
|`FloatEq(a_float)` |`argument` is a `float` value approximately equal to `a_float`, treating two NaNs as unequal. |
|
||||
|`NanSensitiveDoubleEq(a_double)`|`argument` is a `double` value approximately equal to `a_double`, treating two NaNs as equal. |
|
||||
|`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
|
||||
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
|
||||
return false. The `NanSensitive*` version instead treats two NaNs as
|
||||
equal, which is often what a user wants.
|
||||
|
||||
## String Matchers ##
|
||||
|
||||
The `argument` can be either a C string or a C++ string object:
|
||||
|
||||
|`ContainsRegex(string)`|`argument` matches the given regular expression.|
|
||||
|:----------------------|:-----------------------------------------------|
|
||||
|`EndsWith(suffix)` |`argument` ends with string `suffix`. |
|
||||
|`HasSubstr(string)` |`argument` contains `string` as a sub-string. |
|
||||
|`MatchesRegex(string)` |`argument` matches the given regular expression with the match starting at the first character and ending at the last character.|
|
||||
|`StartsWith(prefix)` |`argument` starts with string `prefix`. |
|
||||
|`StrCaseEq(string)` |`argument` is equal to `string`, ignoring case. |
|
||||
|`StrCaseNe(string)` |`argument` is not equal to `string`, ignoring case.|
|
||||
|`StrEq(string)` |`argument` is equal to `string`. |
|
||||
|`StrNe(string)` |`argument` is not equal to `string`. |
|
||||
|
||||
`StrCaseEq()`, `StrCaseNe()`, `StrEq()`, and `StrNe()` work for wide
|
||||
strings as well.
|
||||
|
||||
## Container Matchers ##
|
||||
|
||||
Most STL-style containers support `==`, so you can use
|
||||
`Eq(expected_container)` or simply `expected_container` to match a
|
||||
container exactly. If you want to write the elements in-line,
|
||||
match them more flexibly, or get more informative messages, you can use:
|
||||
|
||||
| `Contains(e)` | `argument` contains an element that matches `e`, which can be either a value or a matcher. |
|
||||
|:--------------|:-------------------------------------------------------------------------------------------|
|
||||
|`ElementsAre(e0, e1, ..., en)`|`argument` has `n + 1` elements, where the i-th element matches `ei`, which can be a value or a matcher. 0 to 10 arguments are allowed.|
|
||||
|`ElementsAreArray(array)` or `ElementsAreArray(array, count)`|The same as `ElementsAre()` except that the expected element values/matchers come from a C-style array.|
|
||||
| `ContainerEq(container)` | The same as `Eq(container)` except that the failure message also includes which elements are in one container but not the other. |
|
||||
|
||||
These matchers can also match:
|
||||
|
||||
1. a native array passed by reference (e.g. in `Foo(const int (&a)[5])`), and
|
||||
1. an array passed as a pointer and a count (e.g. in `Bar(const T* buffer, int len)` -- see [Multi-argument Matchers](#Multiargument_Matchers.md)).
|
||||
|
||||
where the array may be multi-dimensional (i.e. its elements can be arrays).
|
||||
|
||||
## Member Matchers ##
|
||||
|
||||
|`Field(&class::field, m)`|`argument.field` (or `argument->field` when `argument` is a plain pointer) matches matcher `m`, where `argument` is an object of type _class_.|
|
||||
|:------------------------|:---------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
|`Key(e)` |`argument.first` matches `e`, which can be either a value or a matcher. E.g. `Contains(Key(Le(5)))` can verify that a `map` contains a key `<= 5`.|
|
||||
|`Pair(m1, m2)` |`argument` is an `std::pair` whose `first` field matches `m1` and `second` field matches `m2`. |
|
||||
|`Property(&class::property, m)`|`argument.property()` (or `argument->property()` when `argument` is a plain pointer) matches matcher `m`, where `argument` is an object of type _class_.|
|
||||
|
||||
## Matching the Result of a Function or Functor ##
|
||||
|
||||
|`ResultOf(f, m)`|`f(argument)` matches matcher `m`, where `f` is a function or functor.|
|
||||
|:---------------|:---------------------------------------------------------------------|
|
||||
|
||||
## Pointer Matchers ##
|
||||
|
||||
|`Pointee(m)`|`argument` (either a smart pointer or a raw pointer) points to a value that matches matcher `m`.|
|
||||
|:-----------|:-----------------------------------------------------------------------------------------------|
|
||||
|
||||
## Multiargument Matchers ##
|
||||
|
||||
These are matchers on tuple types. They can be used in
|
||||
`.With()`. The following can be used on functions with <i>two<br>
|
||||
arguments</i> `x` and `y`:
|
||||
|
||||
|`Eq()`|`x == y`|
|
||||
|:-----|:-------|
|
||||
|`Ge()`|`x >= y`|
|
||||
|`Gt()`|`x > y` |
|
||||
|`Le()`|`x <= y`|
|
||||
|`Lt()`|`x < y` |
|
||||
|`Ne()`|`x != y`|
|
||||
|
||||
You can use the following selectors to pick a subset of the arguments
|
||||
(or reorder them) to participate in the matching:
|
||||
|
||||
|`AllArgs(m)`|Equivalent to `m`. Useful as syntactic sugar in `.With(AllArgs(m))`.|
|
||||
|:-----------|:-------------------------------------------------------------------|
|
||||
|`Args<N1, N2, ..., Nk>(m)`|The `k` selected (using 0-based indices) arguments match `m`, e.g. `Args<1, 2>(Contains(5))`.|
|
||||
|
||||
## Composite Matchers ##
|
||||
|
||||
You can make a matcher from one or more other matchers:
|
||||
|
||||
|`AllOf(m1, m2, ..., mn)`|`argument` matches all of the matchers `m1` to `mn`.|
|
||||
|:-----------------------|:---------------------------------------------------|
|
||||
|`AnyOf(m1, m2, ..., mn)`|`argument` matches at least one of the matchers `m1` to `mn`.|
|
||||
|`Not(m)` |`argument` doesn't match matcher `m`. |
|
||||
|
||||
## Adapters for Matchers ##
|
||||
|
||||
|`MatcherCast<T>(m)`|casts matcher `m` to type `Matcher<T>`.|
|
||||
|:------------------|:--------------------------------------|
|
||||
|`SafeMatcherCast<T>(m)`| [safely casts](V1_5_CookBook#Casting_Matchers.md) 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 ##
|
||||
|
||||
|`Matches(m)`|a unary functor that returns `true` if the argument matches `m`.|
|
||||
|:-----------|:---------------------------------------------------------------|
|
||||
|`ExplainMatchResult(m, value, result_listener)`|returns `true` if `value` matches `m`, explaining the result to `result_listener`.|
|
||||
|`Value(x, m)`|returns `true` if the value of `x` matches `m`. |
|
||||
|
||||
## Defining Matchers ##
|
||||
|
||||
| `MATCHER(IsEven, "") { return (arg % 2) == 0; }` | Defines a matcher `IsEven()` to match an even number. |
|
||||
|:-------------------------------------------------|:------------------------------------------------------|
|
||||
| `MATCHER_P(IsDivisibleBy, n, "") { *result_listener << "where the remainder is " << (arg % n); return (arg % n) == 0; }` | Defines a macher `IsDivisibleBy(n)` to match a number divisible by `n`. |
|
||||
| `MATCHER_P2(IsBetween, a, b, "is between %(a)s and %(b)s") { return a <= arg && arg <= b; }` | Defines a matcher `IsBetween(a, b)` to match a value in the range [`a`, `b`]. |
|
||||
|
||||
**Notes:**
|
||||
|
||||
1. The `MATCHER*` macros cannot be used inside a function or class.
|
||||
1. The matcher body must be _purely functional_ (i.e. it cannot have any side effect, and the result must not depend on anything other than the value being matched and the matcher parameters).
|
||||
1. You can use `PrintToString(x)` to convert a value `x` of any type to a string.
|
||||
|
||||
## Matchers as Test Assertions ##
|
||||
|
||||
|`ASSERT_THAT(expression, m)`|Generates a [fatal failure](http://code.google.com/p/googletest/wiki/GoogleTestPrimer#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`. |
|
||||
|
||||
# Actions #
|
||||
|
||||
**Actions** specify what a mock function should do when invoked.
|
||||
|
||||
## Returning a Value ##
|
||||
|
||||
|`Return()`|Return from a `void` mock function.|
|
||||
|:---------|:----------------------------------|
|
||||
|`Return(value)`|Return `value`. |
|
||||
|`ReturnArg<N>()`|Return the `N`-th (0-based) argument.|
|
||||
|`ReturnNew<T>(a1, ..., ak)`|Return `new T(a1, ..., ak)`; a different object is created each time.|
|
||||
|`ReturnNull()`|Return a null pointer. |
|
||||
|`ReturnRef(variable)`|Return a reference to `variable`. |
|
||||
|
||||
## Side Effects ##
|
||||
|
||||
|`Assign(&variable, value)`|Assign `value` to variable.|
|
||||
|:-------------------------|:--------------------------|
|
||||
| `DeleteArg<N>()` | Delete the `N`-th (0-based) argument, which must be a pointer. |
|
||||
| `SaveArg<N>(pointer)` | Save the `N`-th (0-based) argument to `*pointer`. |
|
||||
| `SetArgReferee<N>(value)` | Assign value to the variable referenced by the `N`-th (0-based) argument. |
|
||||
|`SetArgumentPointee<N>(value)`|Assign `value` to the variable pointed by the `N`-th (0-based) argument.|
|
||||
|`SetArrayArgument<N>(first, last)`|Copies the elements in source range [`first`, `last`) to the array pointed to by the `N`-th (0-based) argument, which can be either a pointer or an iterator. The action does not take ownership of the elements in the source range.|
|
||||
|`SetErrnoAndReturn(error, value)`|Set `errno` to `error` and return `value`.|
|
||||
|`Throw(exception)` |Throws the given exception, which can be any copyable value. Available since v1.1.0.|
|
||||
|
||||
## Using a Function or a Functor as an Action ##
|
||||
|
||||
|`Invoke(f)`|Invoke `f` with the arguments passed to the mock function, where `f` can be a global/static function or a functor.|
|
||||
|:----------|:-----------------------------------------------------------------------------------------------------------------|
|
||||
|`Invoke(object_pointer, &class::method)`|Invoke the {method on the object with the arguments passed to the mock function. |
|
||||
|`InvokeWithoutArgs(f)`|Invoke `f`, which can be a global/static function or a functor. `f` must take no arguments. |
|
||||
|`InvokeWithoutArgs(object_pointer, &class::method)`|Invoke the method on the object, which takes no arguments. |
|
||||
|`InvokeArgument<N>(arg1, arg2, ..., argk)`|Invoke the mock function's `N`-th (0-based) argument, which must be a function or a functor, with the `k` arguments.|
|
||||
|
||||
The return value of the invoked function is used as the return value
|
||||
of the action.
|
||||
|
||||
When defining a function or functor to be used with `Invoke*()`, you can declare any unused parameters as `Unused`:
|
||||
```
|
||||
double Distance(Unused, double x, double y) { return sqrt(x*x + y*y); }
|
||||
...
|
||||
EXPECT_CALL(mock, Foo("Hi", _, _)).WillOnce(Invoke(Distance));
|
||||
```
|
||||
|
||||
In `InvokeArgument<N>(...)`, if an argument needs to be passed by reference, wrap it inside `ByRef()`. For example,
|
||||
```
|
||||
InvokeArgument<2>(5, string("Hi"), ByRef(foo))
|
||||
```
|
||||
calls the mock function's #2 argument, passing to it `5` and `string("Hi")` by value, and `foo` by reference.
|
||||
|
||||
## Default Action ##
|
||||
|
||||
|`DoDefault()`|Do the default action (specified by `ON_CALL()` or the built-in one).|
|
||||
|:------------|:--------------------------------------------------------------------|
|
||||
|
||||
**Note:** due to technical reasons, `DoDefault()` cannot be used inside a composite action - trying to do so will result in a run-time error.
|
||||
|
||||
## Composite Actions ##
|
||||
|
||||
|`DoAll(a1, a2, ..., an)`|Do all actions `a1` to `an` and return the result of `an` in each invocation. The first `n - 1` sub-actions must return void. |
|
||||
|:-----------------------|:-----------------------------------------------------------------------------------------------------------------------------|
|
||||
|`IgnoreResult(a)` |Perform action `a` and ignore its result. `a` must not return void. |
|
||||
|`WithArg<N>(a)` |Pass the `N`-th (0-based) argument of the mock function to action `a` and perform it. |
|
||||
|`WithArgs<N1, N2, ..., Nk>(a)`|Pass the selected (0-based) arguments of the mock function to action `a` and perform it. |
|
||||
|`WithoutArgs(a)` |Perform action `a` without any arguments. |
|
||||
|
||||
## Defining Actions ##
|
||||
|
||||
| `ACTION(Sum) { return arg0 + arg1; }` | Defines an action `Sum()` to return the sum of the mock function's argument #0 and #1. |
|
||||
|:--------------------------------------|:---------------------------------------------------------------------------------------|
|
||||
| `ACTION_P(Plus, n) { return arg0 + n; }` | Defines an action `Plus(n)` to return the sum of the mock function's argument #0 and `n`. |
|
||||
| `ACTION_Pk(Foo, p1, ..., pk) { statements; }` | Defines a parameterized action `Foo(p1, ..., pk)` to execute the given `statements`. |
|
||||
|
||||
The `ACTION*` macros cannot be used inside a function or class.
|
||||
|
||||
# Cardinalities #
|
||||
|
||||
These are used in `Times()` to specify how many times a mock function will be called:
|
||||
|
||||
|`AnyNumber()`|The function can be called any number of times.|
|
||||
|:------------|:----------------------------------------------|
|
||||
|`AtLeast(n)` |The call is expected at least `n` times. |
|
||||
|`AtMost(n)` |The call is expected at most `n` times. |
|
||||
|`Between(m, n)`|The call is expected between `m` and `n` (inclusive) times.|
|
||||
|`Exactly(n) or n`|The call is expected exactly `n` times. In particular, the call should never happen when `n` is 0.|
|
||||
|
||||
# Expectation Order #
|
||||
|
||||
By default, the expectations can be matched in _any_ order. If some
|
||||
or all expectations must be matched in a given order, there are two
|
||||
ways to specify it. They can be used either independently or
|
||||
together.
|
||||
|
||||
## The After Clause ##
|
||||
|
||||
```
|
||||
using ::testing::Expectation;
|
||||
...
|
||||
Expectation init_x = EXPECT_CALL(foo, InitX());
|
||||
Expectation init_y = EXPECT_CALL(foo, InitY());
|
||||
EXPECT_CALL(foo, Bar())
|
||||
.After(init_x, init_y);
|
||||
```
|
||||
says that `Bar()` can be called only after both `InitX()` and
|
||||
`InitY()` have been called.
|
||||
|
||||
If you don't know how many pre-requisites an expectation has when you
|
||||
write it, you can use an `ExpectationSet` to collect them:
|
||||
|
||||
```
|
||||
using ::testing::ExpectationSet;
|
||||
...
|
||||
ExpectationSet all_inits;
|
||||
for (int i = 0; i < element_count; i++) {
|
||||
all_inits += EXPECT_CALL(foo, InitElement(i));
|
||||
}
|
||||
EXPECT_CALL(foo, Bar())
|
||||
.After(all_inits);
|
||||
```
|
||||
says that `Bar()` can be called only after all elements have been
|
||||
initialized (but we don't care about which elements get initialized
|
||||
before the others).
|
||||
|
||||
Modifying an `ExpectationSet` after using it in an `.After()` doesn't
|
||||
affect the meaning of the `.After()`.
|
||||
|
||||
## Sequences ##
|
||||
|
||||
When you have a long chain of sequential expectations, it's easier to
|
||||
specify the order using **sequences**, which don't require you to given
|
||||
each expectation in the chain a different name. <i>All expected<br>
|
||||
calls</i> in the same sequence must occur in the order they are
|
||||
specified.
|
||||
|
||||
```
|
||||
using ::testing::Sequence;
|
||||
Sequence s1, s2;
|
||||
...
|
||||
EXPECT_CALL(foo, Reset())
|
||||
.InSequence(s1, s2)
|
||||
.WillOnce(Return(true));
|
||||
EXPECT_CALL(foo, GetSize())
|
||||
.InSequence(s1)
|
||||
.WillOnce(Return(1));
|
||||
EXPECT_CALL(foo, Describe(A<const char*>()))
|
||||
.InSequence(s2)
|
||||
.WillOnce(Return("dummy"));
|
||||
```
|
||||
says that `Reset()` must be called before _both_ `GetSize()` _and_
|
||||
`Describe()`, and the latter two can occur in any order.
|
||||
|
||||
To put many expectations in a sequence conveniently:
|
||||
```
|
||||
using ::testing::InSequence;
|
||||
{
|
||||
InSequence dummy;
|
||||
|
||||
EXPECT_CALL(...)...;
|
||||
EXPECT_CALL(...)...;
|
||||
...
|
||||
EXPECT_CALL(...)...;
|
||||
}
|
||||
```
|
||||
says that all expected calls in the scope of `dummy` must occur in
|
||||
strict order. The name `dummy` is irrelevant.)
|
||||
|
||||
# Verifying and Resetting a Mock #
|
||||
|
||||
Google Mock will verify the expectations on a mock object when it is destructed, or you can do it earlier:
|
||||
```
|
||||
using ::testing::Mock;
|
||||
...
|
||||
// Verifies and removes the expectations on mock_obj;
|
||||
// returns true iff successful.
|
||||
Mock::VerifyAndClearExpectations(&mock_obj);
|
||||
...
|
||||
// Verifies and removes the expectations on mock_obj;
|
||||
// also removes the default actions set by ON_CALL();
|
||||
// returns true iff successful.
|
||||
Mock::VerifyAndClear(&mock_obj);
|
||||
```
|
||||
|
||||
You can also tell Google Mock that a mock object can be leaked and doesn't
|
||||
need to be verified:
|
||||
```
|
||||
Mock::AllowLeak(&mock_obj);
|
||||
```
|
||||
|
||||
# Mock Classes #
|
||||
|
||||
Google Mock defines a convenient mock class template
|
||||
```
|
||||
class MockFunction<R(A1, ..., An)> {
|
||||
public:
|
||||
MOCK_METHODn(Call, R(A1, ..., An));
|
||||
};
|
||||
```
|
||||
See this [recipe](V1_5_CookBook#Using_Check_Points.md) 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. |
|
||||
3250
test/gtest-1.8.0/googlemock/docs/v1_5/CookBook.md
Normal file
3250
test/gtest-1.8.0/googlemock/docs/v1_5/CookBook.md
Normal file
File diff suppressed because it is too large
Load Diff
11
test/gtest-1.8.0/googlemock/docs/v1_5/Documentation.md
Normal file
11
test/gtest-1.8.0/googlemock/docs/v1_5/Documentation.md
Normal file
@@ -0,0 +1,11 @@
|
||||
This page lists all documentation wiki pages for Google Mock **version 1.5.0** -- **if you use a different version of Google Mock, please read the documentation for that specific version instead.**
|
||||
|
||||
* [ForDummies](V1_5_ForDummies.md) -- start here if you are new to Google Mock.
|
||||
* [CheatSheet](V1_5_CheatSheet.md) -- a quick reference.
|
||||
* [CookBook](V1_5_CookBook.md) -- recipes for doing various tasks using Google Mock.
|
||||
* [FrequentlyAskedQuestions](V1_5_FrequentlyAskedQuestions.md) -- check here before asking a question on the mailing list.
|
||||
|
||||
To contribute code to Google Mock, read:
|
||||
|
||||
* DevGuide -- 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.
|
||||
439
test/gtest-1.8.0/googlemock/docs/v1_5/ForDummies.md
Normal file
439
test/gtest-1.8.0/googlemock/docs/v1_5/ForDummies.md
Normal file
@@ -0,0 +1,439 @@
|
||||
|
||||
|
||||
(**Note:** If you get compiler errors that you don't understand, be sure to consult [Google Mock Doctor](V1_5_FrequentlyAskedQuestions#How_am_I_supposed_to_make_sense_of_these_horrible_template_error.md).)
|
||||
|
||||
# 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).
|
||||
|
||||
**Note:** It is easy to confuse the term _fake objects_ with mock objects. Fakes and mocks actually mean very different things in the Test-Driven Development (TDD) community:
|
||||
|
||||
* **Fake** objects have working implementations, but usually take some shortcut (perhaps to make the operations less expensive), which makes them not suitable for production. An in-memory file system would be an example of a fake.
|
||||
* **Mocks** are objects pre-programmed with _expectations_, which form a specification of the calls they are expected to receive.
|
||||
|
||||
If all this seems too abstract for you, don't worry - the most important thing to remember is that a mock allows you to check the _interaction_ between itself and code that uses it. The difference between fakes and mocks will become much clearer once you start to use mocks.
|
||||
|
||||
**Google C++ Mocking Framework** (or **Google Mock** for short) is a library (sometimes we also call it a "framework" to make it sound cool) for creating mock classes and using them. It does to C++ what [jMock](http://www.jmock.org/) and [EasyMock](http://www.easymock.org/) do to Java.
|
||||
|
||||
Using Google Mock involves three basic steps:
|
||||
|
||||
1. Use some simple macros to describe the interface you want to mock, and they will expand to the implementation of your mock class;
|
||||
1. Create some mock objects and specify its expectations and behavior using an intuitive syntax;
|
||||
1. Exercise code that uses the mock objects. Google Mock will catch any violation of the expectations as soon as it arises.
|
||||
|
||||
# Why Google Mock? #
|
||||
While mock objects help you remove unnecessary dependencies in tests and make them fast and reliable, using mocks manually in C++ is _hard_:
|
||||
|
||||
* Someone has to implement the mocks. The job is usually tedious and error-prone. No wonder people go great distance to avoid it.
|
||||
* The quality of those manually written mocks is a bit, uh, unpredictable. You may see some really polished ones, but you may also see some that were hacked up in a hurry and have all sorts of ad hoc restrictions.
|
||||
* The knowledge you gained from using one mock doesn't transfer to the next.
|
||||
|
||||
In contrast, Java and Python programmers have some fine mock frameworks, which automate the creation of mocks. As a result, mocking is a proven effective technique and widely adopted practice in those communities. Having the right tool absolutely makes the difference.
|
||||
|
||||
Google Mock was built to help C++ programmers. It was inspired by [jMock](http://www.jmock.org/) and [EasyMock](http://www.easymock.org/), but designed with C++'s specifics in mind. It is your friend if any of the following problems is bothering you:
|
||||
|
||||
* You are stuck with a sub-optimal design and wish you had done more prototyping before it was too late, but prototyping in C++ is by no means "rapid".
|
||||
* Your tests are slow as they depend on too many libraries or use expensive resources (e.g. a database).
|
||||
* Your tests are brittle as some resources they use are unreliable (e.g. the network).
|
||||
* You want to test how your code handles a failure (e.g. a file checksum error), but it's not easy to cause one.
|
||||
* You need to make sure that your module interacts with other modules in the right way, but it's hard to observe the interaction; therefore you resort to observing the side effects at the end of the action, which is awkward at best.
|
||||
* You want to "mock out" your dependencies, except that they don't have mock implementations yet; and, frankly, you aren't thrilled by some of those hand-written mocks.
|
||||
|
||||
We encourage you to use Google Mock as:
|
||||
|
||||
* a _design_ tool, for it lets you experiment with your interface design early and often. More iterations lead to better designs!
|
||||
* 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.
|
||||
|
||||
# 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:
|
||||
|
||||
```
|
||||
class Turtle {
|
||||
...
|
||||
virtual ~Turtle() {}
|
||||
virtual void PenUp() = 0;
|
||||
virtual void PenDown() = 0;
|
||||
virtual void Forward(int distance) = 0;
|
||||
virtual void Turn(int degrees) = 0;
|
||||
virtual void GoTo(int x, int y) = 0;
|
||||
virtual int GetX() const = 0;
|
||||
virtual int GetY() const = 0;
|
||||
};
|
||||
```
|
||||
|
||||
(Note that the destructor of `Turtle` **must** be virtual, as is the case for **all** classes you intend to inherit from - otherwise the destructor of the derived class will not be called when you delete an object through a base pointer, and you'll get corrupted program states like memory leaks.)
|
||||
|
||||
You can control whether the turtle's movement will leave a trace using `PenUp()` and `PenDown()`, and control its movement using `Forward()`, `Turn()`, and `GoTo()`. Finally, `GetX()` and `GetY()` tell you the current position of the turtle.
|
||||
|
||||
Your program will normally use a real implementation of this interface. In tests, you can use a mock implementation instead. This allows you to easily check what drawing primitives your program is calling, with what arguments, and in which order. Tests written this way are much more robust (they won't break because your new machine does anti-aliasing differently), easier to read and maintain (the intent of a test is expressed in the code, not in some binary images), and run _much, much faster_.
|
||||
|
||||
# Writing the Mock Class #
|
||||
If you are lucky, the mocks you need to use have already been implemented by some nice people. If, however, you find yourself in the position to write a mock class, relax - Google Mock turns this task into a fun game! (Well, almost.)
|
||||
|
||||
## How to Define It ##
|
||||
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`. 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.
|
||||
|
||||
After the process, you should have something like:
|
||||
|
||||
```
|
||||
#include <gmock/gmock.h> // Brings in Google Mock.
|
||||
class MockTurtle : public Turtle {
|
||||
public:
|
||||
...
|
||||
MOCK_METHOD0(PenUp, void());
|
||||
MOCK_METHOD0(PenDown, void());
|
||||
MOCK_METHOD1(Forward, void(int distance));
|
||||
MOCK_METHOD1(Turn, void(int degrees));
|
||||
MOCK_METHOD2(GoTo, void(int x, int y));
|
||||
MOCK_CONST_METHOD0(GetX, int());
|
||||
MOCK_CONST_METHOD0(GetY, int());
|
||||
};
|
||||
```
|
||||
|
||||
You don't need to define these mock methods somewhere else - the `MOCK_METHOD*` macros will generate the definitions for you. It's that simple! Once you get the hang of it, you can pump out mock classes faster than your source-control system can handle your check-ins.
|
||||
|
||||
**Tip:** If even this is too much work for you, you'll find the
|
||||
`gmock_gen.py` tool in Google Mock's `scripts/generator/` directory (courtesy of the [cppclean](http://code.google.com/p/cppclean/) project) useful. This command-line
|
||||
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).
|
||||
|
||||
## 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?)
|
||||
|
||||
So, the rule of thumb is: if you need to mock `Foo` and it's owned by others, define the mock class in `Foo`'s package (better, in a `testing` sub-package such that you can clearly separate production code and testing utilities), and put it in a `mock_foo.h`. Then everyone can reference `mock_foo.h` from their tests. If `Foo` ever changes, there is only one copy of `MockFoo` to change, and only tests that depend on the changed methods need to be fixed.
|
||||
|
||||
Another way to do it: you can introduce a thin layer `FooAdaptor` on top of `Foo` and code to this new interface. Since you own `FooAdaptor`, you can absorb changes in `Foo` much more easily. While this is more work initially, carefully choosing the adaptor interface can make your code easier to write and more readable (a net win in the long run), as you can choose `FooAdaptor` to fit your specific domain much better than `Foo` does.
|
||||
|
||||
# Using Mocks in Tests #
|
||||
Once you have a mock class, using it is easy. The typical work flow is:
|
||||
|
||||
1. Import the Google Mock names from the `testing` namespace such that you can use them unqualified (You only have to do it once per file. Remember that namespaces are a good idea and good for your health.).
|
||||
1. Create some mock objects.
|
||||
1. Specify your expectations on them (How many times will a method be called? With what arguments? What should it do? etc.).
|
||||
1. Exercise some code that uses the mocks; optionally, check the result using Google Test assertions. If a mock method is called more than expected or with wrong arguments, you'll get an error immediately.
|
||||
1. When a mock is destructed, Google Mock will automatically check whether all expectations on it have been satisfied.
|
||||
|
||||
Here's an example:
|
||||
|
||||
```
|
||||
#include "path/to/mock-turtle.h"
|
||||
#include <gmock/gmock.h>
|
||||
#include <gtest/gtest.h>
|
||||
using ::testing::AtLeast; // #1
|
||||
|
||||
TEST(PainterTest, CanDrawSomething) {
|
||||
MockTurtle turtle; // #2
|
||||
EXPECT_CALL(turtle, PenDown()) // #3
|
||||
.Times(AtLeast(1));
|
||||
|
||||
Painter painter(&turtle); // #4
|
||||
|
||||
EXPECT_TRUE(painter.DrawCircle(0, 0, 10));
|
||||
} // #5
|
||||
|
||||
int main(int argc, char** argv) {
|
||||
// The following line must be executed to initialize Google Mock
|
||||
// (and Google Test) before running the tests.
|
||||
::testing::InitGoogleMock(&argc, argv);
|
||||
return RUN_ALL_TESTS();
|
||||
}
|
||||
```
|
||||
|
||||
As you might have guessed, this test checks that `PenDown()` is called at least once. If the `painter` object didn't call this method, your test will fail with a message like this:
|
||||
|
||||
```
|
||||
path/to/my_test.cc:119: Failure
|
||||
Actual function call count doesn't match this expectation:
|
||||
Actually: never called;
|
||||
Expected: called at least once.
|
||||
```
|
||||
|
||||
**Tip 1:** If you run the test from an Emacs buffer, you can hit `<Enter>` on the line number displayed in the error message to jump right to the failed expectation.
|
||||
|
||||
**Tip 2:** If your mock objects are never deleted, the final verification won't happen. Therefore it's a good idea to use a heap leak checker in your tests when you allocate mocks on the heap.
|
||||
|
||||
**Important note:** Google Mock requires expectations to be set **before** the mock functions are called, otherwise the behavior is **undefined**. In particular, you mustn't interleave `EXPECT_CALL()`s and calls to the mock functions.
|
||||
|
||||
This means `EXPECT_CALL()` should be read as expecting that a call will occur _in the future_, not that a call has occurred. Why does Google Mock work like that? Well, specifying the expectation beforehand allows Google Mock to report a violation as soon as it arises, when the context (stack trace, etc) is still available. This makes debugging much easier.
|
||||
|
||||
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
|
||||
[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) {
|
||||
// The following line causes Google Mock to throw an exception on failure,
|
||||
// which will be interpreted by your testing framework as a test failure.
|
||||
::testing::GTEST_FLAG(throw_on_failure) = true;
|
||||
::testing::InitGoogleMock(&argc, argv);
|
||||
... whatever your testing framework requires ...
|
||||
}
|
||||
```
|
||||
|
||||
This approach has a catch: it makes Google Mock throw an exception
|
||||
from a mock object's destructor sometimes. With some compilers, this
|
||||
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/GoogleTestAdvancedGuide#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.
|
||||
|
||||
If this turns out to be too much work, we suggest that you stick with
|
||||
Google Test, which works with Google Mock seamlessly (in fact, it is
|
||||
technically part of Google Mock.). If there is a reason that you
|
||||
cannot use Google Test, please let us know.
|
||||
|
||||
# Setting Expectations #
|
||||
The key to using a mock object successfully is to set the _right expectations_ on it. If you set the expectations too strict, your test will fail as the result of unrelated changes. If you set them too loose, bugs can slip through. You want to do it just right such that your test can catch exactly the kind of bugs you intend it to catch. Google Mock provides the necessary means for you to do it "just right."
|
||||
|
||||
## General Syntax ##
|
||||
In Google Mock we use the `EXPECT_CALL()` macro to set an expectation on a mock method. The general syntax is:
|
||||
|
||||
```
|
||||
EXPECT_CALL(mock_object, method(matchers))
|
||||
.Times(cardinality)
|
||||
.WillOnce(action)
|
||||
.WillRepeatedly(action);
|
||||
```
|
||||
|
||||
The macro has two arguments: first the mock object, and then the method and its arguments. Note that the two are separated by a comma (`,`), not a period (`.`). (Why using a comma? The answer is that it was necessary for technical reasons.)
|
||||
|
||||
The macro can be followed by some optional _clauses_ that provide more information about the expectation. We'll discuss how each clause works in the coming sections.
|
||||
|
||||
This syntax is designed to make an expectation read like English. For example, you can probably guess that
|
||||
|
||||
```
|
||||
using ::testing::Return;...
|
||||
EXPECT_CALL(turtle, GetX())
|
||||
.Times(5)
|
||||
.WillOnce(Return(100))
|
||||
.WillOnce(Return(150))
|
||||
.WillRepeatedly(Return(200));
|
||||
```
|
||||
|
||||
says that the `turtle` object's `GetX()` method will be called five times, it will return 100 the first time, 150 the second time, and then 200 every time. Some people like to call this style of syntax a Domain-Specific Language (DSL).
|
||||
|
||||
**Note:** Why do we use a macro to do this? It serves two purposes: first it makes expectations easily identifiable (either by `grep` or by a human reader), and second it allows Google Mock to include the source file location of a failed expectation in messages, making debugging easier.
|
||||
|
||||
## Matchers: What Arguments Do We Expect? ##
|
||||
When a mock function takes arguments, we must specify what arguments we are expecting; for example:
|
||||
|
||||
```
|
||||
// Expects the turtle to move forward by 100 units.
|
||||
EXPECT_CALL(turtle, Forward(100));
|
||||
```
|
||||
|
||||
Sometimes you may not want to be too specific (Remember that talk about tests being too rigid? Over specification leads to brittle tests and obscures the intent of tests. Therefore we encourage you to specify only what's necessary - no more, no less.). If you care to check that `Forward()` will be called but aren't interested in its actual argument, write `_` as the argument, which means "anything goes":
|
||||
|
||||
```
|
||||
using ::testing::_;
|
||||
...
|
||||
// Expects the turtle to move forward.
|
||||
EXPECT_CALL(turtle, Forward(_));
|
||||
```
|
||||
|
||||
`_` is an instance of what we call **matchers**. A matcher is like a predicate and can test whether an argument is what we'd expect. You can use a matcher inside `EXPECT_CALL()` wherever a function argument is expected.
|
||||
|
||||
A list of built-in matchers can be found in the [CheatSheet](V1_5_CheatSheet.md). For example, here's the `Ge` (greater than or equal) matcher:
|
||||
|
||||
```
|
||||
using ::testing::Ge;...
|
||||
EXPECT_CALL(turtle, Forward(Ge(100)));
|
||||
```
|
||||
|
||||
This checks that the turtle will be told to go forward by at least 100 units.
|
||||
|
||||
## Cardinalities: How Many Times Will It Be Called? ##
|
||||
The first clause we can specify following an `EXPECT_CALL()` is `Times()`. We call its argument a **cardinality** as it tells _how many times_ the call should occur. It allows us to repeat an expectation many times without actually writing it as many times. More importantly, a cardinality can be "fuzzy", just like a matcher can be. This allows a user to express the intent of a test exactly.
|
||||
|
||||
An interesting special case is when we say `Times(0)`. You may have guessed - it means that the function shouldn't be called with the given arguments at all, and Google Mock will report a Google Test failure whenever the function is (wrongfully) called.
|
||||
|
||||
We've seen `AtLeast(n)` as an example of fuzzy cardinalities earlier. For the list of built-in cardinalities you can use, see the [CheatSheet](V1_5_CheatSheet.md).
|
||||
|
||||
The `Times()` clause can be omitted. **If you omit `Times()`, Google Mock will infer the cardinality for you.** The rules are easy to remember:
|
||||
|
||||
* If **neither** `WillOnce()` **nor** `WillRepeatedly()` is in the `EXPECT_CALL()`, the inferred cardinality is `Times(1)`.
|
||||
* If there are `n WillOnce()`'s but **no** `WillRepeatedly()`, where `n` >= 1, the cardinality is `Times(n)`.
|
||||
* If there are `n WillOnce()`'s and **one** `WillRepeatedly()`, where `n` >= 0, the cardinality is `Times(AtLeast(n))`.
|
||||
|
||||
**Quick quiz:** what do you think will happen if a function is expected to be called twice but actually called four times?
|
||||
|
||||
## Actions: What Should It Do? ##
|
||||
Remember that a mock object doesn't really have a working implementation? We as users have to tell it what to do when a method is invoked. This is easy in Google Mock.
|
||||
|
||||
First, if the return type of a mock function is a built-in type or a pointer, the function has a **default action** (a `void` function will just return, a `bool` function will return `false`, and other functions will return 0). If you don't say anything, this behavior will be used.
|
||||
|
||||
Second, if a mock function doesn't have a default action, or the default action doesn't suit you, you can specify the action to be taken each time the expectation matches using a series of `WillOnce()` clauses followed by an optional `WillRepeatedly()`. For example,
|
||||
|
||||
```
|
||||
using ::testing::Return;...
|
||||
EXPECT_CALL(turtle, GetX())
|
||||
.WillOnce(Return(100))
|
||||
.WillOnce(Return(200))
|
||||
.WillOnce(Return(300));
|
||||
```
|
||||
|
||||
This says that `turtle.GetX()` will be called _exactly three times_ (Google Mock inferred this from how many `WillOnce()` clauses we've written, since we didn't explicitly write `Times()`), and will return 100, 200, and 300 respectively.
|
||||
|
||||
```
|
||||
using ::testing::Return;...
|
||||
EXPECT_CALL(turtle, GetY())
|
||||
.WillOnce(Return(100))
|
||||
.WillOnce(Return(200))
|
||||
.WillRepeatedly(Return(300));
|
||||
```
|
||||
|
||||
says that `turtle.GetY()` will be called _at least twice_ (Google Mock knows this as we've written two `WillOnce()` clauses and a `WillRepeatedly()` while having no explicit `Times()`), will return 100 the first time, 200 the second time, and 300 from the third time on.
|
||||
|
||||
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](V1_5_CheatSheet#Actions.md).
|
||||
|
||||
**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:
|
||||
|
||||
```
|
||||
int n = 100;
|
||||
EXPECT_CALL(turtle, GetX())
|
||||
.Times(4)
|
||||
.WillOnce(Return(n++));
|
||||
```
|
||||
|
||||
Instead of returning 100, 101, 102, ..., consecutively, this mock function will always return 100 as `n++` is only evaluated once. Similarly, `Return(new Foo)` will create a new `Foo` object when the `EXPECT_CALL()` is executed, and will return the same pointer every time. If you want the side effect to happen every time, you need to define a custom action, which we'll teach in the [CookBook](V1_5_CookBook.md).
|
||||
|
||||
Time for another quiz! What do you think the following means?
|
||||
|
||||
```
|
||||
using ::testing::Return;...
|
||||
EXPECT_CALL(turtle, GetY())
|
||||
.Times(4)
|
||||
.WillOnce(Return(100));
|
||||
```
|
||||
|
||||
Obviously `turtle.GetY()` is expected to be called four times. But if you think it will return 100 every time, think twice! Remember that one `WillOnce()` clause will be consumed each time the function is invoked and the default action will be taken afterwards. So the right answer is that `turtle.GetY()` will return 100 the first time, but **return 0 from the second time on**, as returning 0 is the default action for `int` functions.
|
||||
|
||||
## Using Multiple Expectations ##
|
||||
So far we've only shown examples where you have a single expectation. More realistically, you're going to specify expectations on multiple mock methods, which may be from multiple mock objects.
|
||||
|
||||
By default, when a mock method is invoked, Google Mock will search the expectations in the **reverse order** they are defined, and stop when an active expectation that matches the arguments is found (you can think of it as "newer rules override older ones."). If the matching expectation cannot take any more calls, you will get an upper-bound-violated failure. Here's an example:
|
||||
|
||||
```
|
||||
using ::testing::_;...
|
||||
EXPECT_CALL(turtle, Forward(_)); // #1
|
||||
EXPECT_CALL(turtle, Forward(10)) // #2
|
||||
.Times(2);
|
||||
```
|
||||
|
||||
If `Forward(10)` is called three times in a row, the third time it will be an error, as the last matching expectation (#2) has been saturated. If, however, the third `Forward(10)` call is replaced by `Forward(20)`, then it would be OK, as now #1 will be the matching expectation.
|
||||
|
||||
**Side note:** Why does Google Mock search for a match in the _reverse_ order of the expectations? The reason is that this allows a user to set up the default expectations in a mock object's constructor or the test fixture's set-up phase and then customize the mock by writing more specific expectations in the test body. So, if you have two expectations on the same method, you want to put the one with more specific matchers **after** the other, or the more specific rule would be shadowed by the more general one that comes after it.
|
||||
|
||||
## Ordered vs Unordered Calls ##
|
||||
By default, an expectation can match a call even though an earlier expectation hasn't been satisfied. In other words, the calls don't have to occur in the order the expectations are specified.
|
||||
|
||||
Sometimes, you may want all the expected calls to occur in a strict order. To say this in Google Mock is easy:
|
||||
|
||||
```
|
||||
using ::testing::InSequence;...
|
||||
TEST(FooTest, DrawsLineSegment) {
|
||||
...
|
||||
{
|
||||
InSequence dummy;
|
||||
|
||||
EXPECT_CALL(turtle, PenDown());
|
||||
EXPECT_CALL(turtle, Forward(100));
|
||||
EXPECT_CALL(turtle, PenUp());
|
||||
}
|
||||
Foo();
|
||||
}
|
||||
```
|
||||
|
||||
By creating an object of type `InSequence`, all expectations in its scope are put into a _sequence_ and have to occur _sequentially_. Since we are just relying on the constructor and destructor of this object to do the actual work, its name is really irrelevant.
|
||||
|
||||
In this example, we test that `Foo()` calls the three expected functions in the order as written. If a call is made out-of-order, it will be an error.
|
||||
|
||||
(What if you care about the relative order of some of the calls, but not all of them? Can you specify an arbitrary partial order? The answer is ... yes! If you are impatient, the details can be found in the [CookBook](V1_5_CookBook.md).)
|
||||
|
||||
## All Expectations Are Sticky (Unless Said Otherwise) ##
|
||||
Now let's do a quick quiz to see how well you can use this mock stuff already. How would you test that the turtle is asked to go to the origin _exactly twice_ (you want to ignore any other instructions it receives)?
|
||||
|
||||
After you've come up with your answer, take a look at ours and compare notes (solve it yourself first - don't cheat!):
|
||||
|
||||
```
|
||||
using ::testing::_;...
|
||||
EXPECT_CALL(turtle, GoTo(_, _)) // #1
|
||||
.Times(AnyNumber());
|
||||
EXPECT_CALL(turtle, GoTo(0, 0)) // #2
|
||||
.Times(2);
|
||||
```
|
||||
|
||||
Suppose `turtle.GoTo(0, 0)` is called three times. In the third time, Google Mock will see that the arguments match expectation #2 (remember that we always pick the last matching expectation). Now, since we said that there should be only two such calls, Google Mock will report an error immediately. This is basically what we've told you in the "Using Multiple Expectations" section above.
|
||||
|
||||
This example shows that **expectations in Google Mock are "sticky" by default**, in the sense that they remain active even after we have reached their invocation upper bounds. This is an important rule to remember, as it affects the meaning of the spec, and is **different** to how it's done in many other mocking frameworks (Why'd we do that? Because we think our rule makes the common cases easier to express and understand.).
|
||||
|
||||
Simple? Let's see if you've really understood it: what does the following code say?
|
||||
|
||||
```
|
||||
using ::testing::Return;
|
||||
...
|
||||
for (int i = n; i > 0; i--) {
|
||||
EXPECT_CALL(turtle, GetX())
|
||||
.WillOnce(Return(10*i));
|
||||
}
|
||||
```
|
||||
|
||||
If you think it says that `turtle.GetX()` will be called `n` times and will return 10, 20, 30, ..., consecutively, think twice! The problem is that, as we said, expectations are sticky. So, the second time `turtle.GetX()` is called, the last (latest) `EXPECT_CALL()` statement will match, and will immediately lead to an "upper bound exceeded" error - this piece of code is not very useful!
|
||||
|
||||
One correct way of saying that `turtle.GetX()` will return 10, 20, 30, ..., is to explicitly say that the expectations are _not_ sticky. In other words, they should _retire_ as soon as they are saturated:
|
||||
|
||||
```
|
||||
using ::testing::Return;
|
||||
...
|
||||
for (int i = n; i > 0; i--) {
|
||||
EXPECT_CALL(turtle, GetX())
|
||||
.WillOnce(Return(10*i))
|
||||
.RetiresOnSaturation();
|
||||
}
|
||||
```
|
||||
|
||||
And, there's a better way to do it: in this case, we expect the calls to occur in a specific order, and we line up the actions to match the order. Since the order is important here, we should make it explicit using a sequence:
|
||||
|
||||
```
|
||||
using ::testing::InSequence;
|
||||
using ::testing::Return;
|
||||
...
|
||||
{
|
||||
InSequence s;
|
||||
|
||||
for (int i = 1; i <= n; i++) {
|
||||
EXPECT_CALL(turtle, GetX())
|
||||
.WillOnce(Return(10*i))
|
||||
.RetiresOnSaturation();
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
By the way, the other situation where an expectation may _not_ be sticky is when it's in a sequence - as soon as another expectation that comes after it in the sequence has been used, it automatically retires (and will never be used to match any call).
|
||||
|
||||
## Uninteresting Calls ##
|
||||
A mock object may have many methods, and not all of them are that interesting. For example, in some tests we may not care about how many times `GetX()` and `GetY()` get called.
|
||||
|
||||
In Google Mock, if you are not interested in a method, just don't say anything about it. If a call to this method occurs, you'll see a warning in the test output, but it won't be a failure.
|
||||
|
||||
# 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](V1_5_CookBook.md). You can learn many advanced features of Google Mock there -- and advance your level of enjoyment and testing bliss.
|
||||
@@ -0,0 +1,624 @@
|
||||
|
||||
|
||||
Please send your questions to the
|
||||
[googlemock](http://groups.google.com/group/googlemock) discussion
|
||||
group. If you need help with compiler errors, make sure you have
|
||||
tried [Google Mock Doctor](#How_am_I_supposed_to_make_sense_of_these_horrible_template_error.md) first.
|
||||
|
||||
## I wrote some matchers. After I upgraded to a new version of Google Mock, they no longer compile. What's going on? ##
|
||||
|
||||
After version 1.4.0 of Google Mock was released, we had an idea on how
|
||||
to make it easier to write matchers that can generate informative
|
||||
messages efficiently. We experimented with this idea and liked what
|
||||
we saw. Therefore we decided to implement it.
|
||||
|
||||
Unfortunately, this means that if you have defined your own matchers
|
||||
by implementing `MatcherInterface` or using `MakePolymorphicMatcher()`,
|
||||
your definitions will no longer compile. Matchers defined using the
|
||||
`MATCHER*` family of macros are not affected.
|
||||
|
||||
Sorry for the hassle if your matchers are affected. We believe it's
|
||||
in everyone's long-term interest to make this change sooner than
|
||||
later. Fortunately, it's usually not hard to migrate an existing
|
||||
matcher to the new API. Here's what you need to do:
|
||||
|
||||
If you wrote your matcher like this:
|
||||
```
|
||||
// Old matcher definition that doesn't work with the latest
|
||||
// Google Mock.
|
||||
using ::testing::MatcherInterface;
|
||||
...
|
||||
class MyWonderfulMatcher : public MatcherInterface<MyType> {
|
||||
public:
|
||||
...
|
||||
virtual bool Matches(MyType value) const {
|
||||
// Returns true if value matches.
|
||||
return value.GetFoo() > 5;
|
||||
}
|
||||
...
|
||||
};
|
||||
```
|
||||
|
||||
you'll need to change it to:
|
||||
```
|
||||
// New matcher definition that works with the latest Google Mock.
|
||||
using ::testing::MatcherInterface;
|
||||
using ::testing::MatchResultListener;
|
||||
...
|
||||
class MyWonderfulMatcher : public MatcherInterface<MyType> {
|
||||
public:
|
||||
...
|
||||
virtual bool MatchAndExplain(MyType value,
|
||||
MatchResultListener* listener) const {
|
||||
// Returns true if value matches.
|
||||
return value.GetFoo() > 5;
|
||||
}
|
||||
...
|
||||
};
|
||||
```
|
||||
(i.e. rename `Matches()` to `MatchAndExplain()` and give it a second
|
||||
argument of type `MatchResultListener*`.)
|
||||
|
||||
If you were also using `ExplainMatchResultTo()` to improve the matcher
|
||||
message:
|
||||
```
|
||||
// Old matcher definition that doesn't work with the lastest
|
||||
// Google Mock.
|
||||
using ::testing::MatcherInterface;
|
||||
...
|
||||
class MyWonderfulMatcher : public MatcherInterface<MyType> {
|
||||
public:
|
||||
...
|
||||
virtual bool Matches(MyType value) const {
|
||||
// Returns true if value matches.
|
||||
return value.GetFoo() > 5;
|
||||
}
|
||||
|
||||
virtual void ExplainMatchResultTo(MyType value,
|
||||
::std::ostream* os) const {
|
||||
// Prints some helpful information to os to help
|
||||
// a user understand why value matches (or doesn't match).
|
||||
*os << "the Foo property is " << value.GetFoo();
|
||||
}
|
||||
...
|
||||
};
|
||||
```
|
||||
|
||||
you should move the logic of `ExplainMatchResultTo()` into
|
||||
`MatchAndExplain()`, using the `MatchResultListener` argument where
|
||||
the `::std::ostream` was used:
|
||||
```
|
||||
// New matcher definition that works with the latest Google Mock.
|
||||
using ::testing::MatcherInterface;
|
||||
using ::testing::MatchResultListener;
|
||||
...
|
||||
class MyWonderfulMatcher : public MatcherInterface<MyType> {
|
||||
public:
|
||||
...
|
||||
virtual bool MatchAndExplain(MyType value,
|
||||
MatchResultListener* listener) const {
|
||||
// Returns true if value matches.
|
||||
*listener << "the Foo property is " << value.GetFoo();
|
||||
return value.GetFoo() > 5;
|
||||
}
|
||||
...
|
||||
};
|
||||
```
|
||||
|
||||
If your matcher is defined using `MakePolymorphicMatcher()`:
|
||||
```
|
||||
// Old matcher definition that doesn't work with the latest
|
||||
// Google Mock.
|
||||
using ::testing::MakePolymorphicMatcher;
|
||||
...
|
||||
class MyGreatMatcher {
|
||||
public:
|
||||
...
|
||||
bool Matches(MyType value) const {
|
||||
// Returns true if value matches.
|
||||
return value.GetBar() < 42;
|
||||
}
|
||||
...
|
||||
};
|
||||
... MakePolymorphicMatcher(MyGreatMatcher()) ...
|
||||
```
|
||||
|
||||
you should rename the `Matches()` method to `MatchAndExplain()` and
|
||||
add a `MatchResultListener*` argument (the same as what you need to do
|
||||
for matchers defined by implementing `MatcherInterface`):
|
||||
```
|
||||
// New matcher definition that works with the latest Google Mock.
|
||||
using ::testing::MakePolymorphicMatcher;
|
||||
using ::testing::MatchResultListener;
|
||||
...
|
||||
class MyGreatMatcher {
|
||||
public:
|
||||
...
|
||||
bool MatchAndExplain(MyType value,
|
||||
MatchResultListener* listener) const {
|
||||
// Returns true if value matches.
|
||||
return value.GetBar() < 42;
|
||||
}
|
||||
...
|
||||
};
|
||||
... MakePolymorphicMatcher(MyGreatMatcher()) ...
|
||||
```
|
||||
|
||||
If your polymorphic matcher uses `ExplainMatchResultTo()` for better
|
||||
failure messages:
|
||||
```
|
||||
// Old matcher definition that doesn't work with the latest
|
||||
// Google Mock.
|
||||
using ::testing::MakePolymorphicMatcher;
|
||||
...
|
||||
class MyGreatMatcher {
|
||||
public:
|
||||
...
|
||||
bool Matches(MyType value) const {
|
||||
// Returns true if value matches.
|
||||
return value.GetBar() < 42;
|
||||
}
|
||||
...
|
||||
};
|
||||
void ExplainMatchResultTo(const MyGreatMatcher& matcher,
|
||||
MyType value,
|
||||
::std::ostream* os) {
|
||||
// Prints some helpful information to os to help
|
||||
// a user understand why value matches (or doesn't match).
|
||||
*os << "the Bar property is " << value.GetBar();
|
||||
}
|
||||
... MakePolymorphicMatcher(MyGreatMatcher()) ...
|
||||
```
|
||||
|
||||
you'll need to move the logic inside `ExplainMatchResultTo()` to
|
||||
`MatchAndExplain()`:
|
||||
```
|
||||
// New matcher definition that works with the latest Google Mock.
|
||||
using ::testing::MakePolymorphicMatcher;
|
||||
using ::testing::MatchResultListener;
|
||||
...
|
||||
class MyGreatMatcher {
|
||||
public:
|
||||
...
|
||||
bool MatchAndExplain(MyType value,
|
||||
MatchResultListener* listener) const {
|
||||
// Returns true if value matches.
|
||||
*listener << "the Bar property is " << value.GetBar();
|
||||
return value.GetBar() < 42;
|
||||
}
|
||||
...
|
||||
};
|
||||
... MakePolymorphicMatcher(MyGreatMatcher()) ...
|
||||
```
|
||||
|
||||
For more information, you can read these
|
||||
[two](V1_5_CookBook#Writing_New_Monomorphic_Matchers.md)
|
||||
[recipes](V1_5_CookBook#Writing_New_Polymorphic_Matchers.md)
|
||||
from the cookbook. As always, you
|
||||
are welcome to post questions on `googlemock@googlegroups.com` if you
|
||||
need any help.
|
||||
|
||||
## When using Google Mock, do I have to use Google Test as the testing framework? I have my favorite testing framework and don't want to switch. ##
|
||||
|
||||
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](V1_5_ForDummies#Using_Google_Mock_with_Any_Testing_Framework.md) is how.
|
||||
|
||||
## How am I supposed to make sense of these horrible template errors? ##
|
||||
|
||||
If you are confused by the compiler errors gcc threw at you,
|
||||
try consulting the _Google Mock Doctor_ tool first. What it does is to
|
||||
scan stdin for gcc error messages, and spit out diagnoses on the
|
||||
problems (we call them diseases) your code has.
|
||||
|
||||
To "install", run command:
|
||||
```
|
||||
alias gmd='<path to googlemock>/scripts/gmock_doctor.py'
|
||||
```
|
||||
|
||||
To use it, do:
|
||||
```
|
||||
<your-favorite-build-command> <your-test> 2>&1 | gmd
|
||||
```
|
||||
|
||||
For example:
|
||||
```
|
||||
make my_test 2>&1 | gmd
|
||||
```
|
||||
|
||||
Or you can run `gmd` and copy-n-paste gcc's error messages to it.
|
||||
|
||||
## Can I mock a variadic function? ##
|
||||
|
||||
You cannot mock a variadic function (i.e. a function taking ellipsis
|
||||
(`...`) arguments) directly in Google Mock.
|
||||
|
||||
The problem is that in general, there is _no way_ for a mock object to
|
||||
know how many arguments are passed to the variadic method, and what
|
||||
the arguments' types are. Only the _author of the base class_ knows
|
||||
the protocol, and we cannot look into his head.
|
||||
|
||||
Therefore, to mock such a function, the _user_ must teach the mock
|
||||
object how to figure out the number of arguments and their types. One
|
||||
way to do it is to provide overloaded versions of the function.
|
||||
|
||||
Ellipsis arguments are inherited from C and not really a C++ feature.
|
||||
They are unsafe to use and don't work with arguments that have
|
||||
constructors or destructors. Therefore we recommend to avoid them in
|
||||
C++ as much as possible.
|
||||
|
||||
## MSVC gives me warning C4301 or C4373 when I define a mock method with a const parameter. Why? ##
|
||||
|
||||
If you compile this using Microsoft Visual C++ 2005 SP1:
|
||||
```
|
||||
class Foo {
|
||||
...
|
||||
virtual void Bar(const int i) = 0;
|
||||
};
|
||||
|
||||
class MockFoo : public Foo {
|
||||
...
|
||||
MOCK_METHOD1(Bar, void(const int i));
|
||||
};
|
||||
```
|
||||
You may get the following warning:
|
||||
```
|
||||
warning C4301: 'MockFoo::Bar': overriding virtual function only differs from 'Foo::Bar' by const/volatile qualifier
|
||||
```
|
||||
|
||||
This is a MSVC bug. The same code compiles fine with gcc ,for
|
||||
example. If you use Visual C++ 2008 SP1, you would get the warning:
|
||||
```
|
||||
warning C4373: 'MockFoo::Bar': virtual function overrides 'Foo::Bar', previous versions of the compiler did not override when parameters only differed by const/volatile qualifiers
|
||||
```
|
||||
|
||||
In C++, if you _declare_ a function with a `const` parameter, the
|
||||
`const` modifier is _ignored_. Therefore, the `Foo` base class above
|
||||
is equivalent to:
|
||||
```
|
||||
class Foo {
|
||||
...
|
||||
virtual void Bar(int i) = 0; // int or const int? Makes no difference.
|
||||
};
|
||||
```
|
||||
|
||||
In fact, you can _declare_ Bar() with an `int` parameter, and _define_
|
||||
it with a `const int` parameter. The compiler will still match them
|
||||
up.
|
||||
|
||||
Since making a parameter `const` is meaningless in the method
|
||||
_declaration_, we recommend to remove it in both `Foo` and `MockFoo`.
|
||||
That should workaround the VC bug.
|
||||
|
||||
Note that we are talking about the _top-level_ `const` modifier here.
|
||||
If the function parameter is passed by pointer or reference, declaring
|
||||
the _pointee_ or _referee_ as `const` is still meaningful. For
|
||||
example, the following two declarations are _not_ equivalent:
|
||||
```
|
||||
void Bar(int* p); // Neither p nor *p is const.
|
||||
void Bar(const int* p); // p is not const, but *p is.
|
||||
```
|
||||
|
||||
## I have a huge mock class, and Microsoft Visual C++ runs out of memory when compiling it. What can I do? ##
|
||||
|
||||
We've noticed that when the `/clr` compiler flag is used, Visual C++
|
||||
uses 5~6 times as much memory when compiling a mock class. We suggest
|
||||
to avoid `/clr` when compiling native C++ mocks.
|
||||
|
||||
## I can't figure out why Google Mock thinks my expectations are not satisfied. What should I do? ##
|
||||
|
||||
You might want to run your test with
|
||||
`--gmock_verbose=info`. This flag lets Google Mock print a trace
|
||||
of every mock function call it receives. By studying the trace,
|
||||
you'll gain insights on why the expectations you set are not met.
|
||||
|
||||
## How can I assert that a function is NEVER called? ##
|
||||
|
||||
```
|
||||
EXPECT_CALL(foo, Bar(_))
|
||||
.Times(0);
|
||||
```
|
||||
|
||||
## I have a failed test where Google Mock tells me TWICE that a particular expectation is not satisfied. Isn't this redundant? ##
|
||||
|
||||
When Google Mock detects a failure, it prints relevant information
|
||||
(the mock function arguments, the state of relevant expectations, and
|
||||
etc) to help the user debug. If another failure is detected, Google
|
||||
Mock will do the same, including printing the state of relevant
|
||||
expectations.
|
||||
|
||||
Sometimes an expectation's state didn't change between two failures,
|
||||
and you'll see the same description of the state twice. They are
|
||||
however _not_ redundant, as they refer to _different points in time_.
|
||||
The fact they are the same _is_ interesting information.
|
||||
|
||||
## I get a heap check failure when using a mock object, but using a real object is fine. What can be wrong? ##
|
||||
|
||||
Does the class (hopefully a pure interface) you are mocking have a
|
||||
virtual destructor?
|
||||
|
||||
Whenever you derive from a base class, make sure its destructor is
|
||||
virtual. Otherwise Bad Things will happen. Consider the following
|
||||
code:
|
||||
|
||||
```
|
||||
class Base {
|
||||
public:
|
||||
// Not virtual, but should be.
|
||||
~Base() { ... }
|
||||
...
|
||||
};
|
||||
|
||||
class Derived : public Base {
|
||||
public:
|
||||
...
|
||||
private:
|
||||
std::string value_;
|
||||
};
|
||||
|
||||
...
|
||||
Base* p = new Derived;
|
||||
...
|
||||
delete p; // Surprise! ~Base() will be called, but ~Derived() will not
|
||||
// - value_ is leaked.
|
||||
```
|
||||
|
||||
By changing `~Base()` to virtual, `~Derived()` will be correctly
|
||||
called when `delete p` is executed, and the heap checker
|
||||
will be happy.
|
||||
|
||||
## The "newer expectations override older ones" rule makes writing expectations awkward. Why does Google Mock do that? ##
|
||||
|
||||
When people complain about this, often they are referring to code like:
|
||||
|
||||
```
|
||||
// foo.Bar() should be called twice, return 1 the first time, and return
|
||||
// 2 the second time. However, I have to write the expectations in the
|
||||
// reverse order. This sucks big time!!!
|
||||
EXPECT_CALL(foo, Bar())
|
||||
.WillOnce(Return(2))
|
||||
.RetiresOnSaturation();
|
||||
EXPECT_CALL(foo, Bar())
|
||||
.WillOnce(Return(1))
|
||||
.RetiresOnSaturation();
|
||||
```
|
||||
|
||||
The problem is that they didn't pick the **best** way to express the test's
|
||||
intent.
|
||||
|
||||
By default, expectations don't have to be matched in _any_ particular
|
||||
order. If you want them to match in a certain order, you need to be
|
||||
explicit. This is Google Mock's (and jMock's) fundamental philosophy: it's
|
||||
easy to accidentally over-specify your tests, and we want to make it
|
||||
harder to do so.
|
||||
|
||||
There are two better ways to write the test spec. You could either
|
||||
put the expectations in sequence:
|
||||
|
||||
```
|
||||
// foo.Bar() should be called twice, return 1 the first time, and return
|
||||
// 2 the second time. Using a sequence, we can write the expectations
|
||||
// in their natural order.
|
||||
{
|
||||
InSequence s;
|
||||
EXPECT_CALL(foo, Bar())
|
||||
.WillOnce(Return(1))
|
||||
.RetiresOnSaturation();
|
||||
EXPECT_CALL(foo, Bar())
|
||||
.WillOnce(Return(2))
|
||||
.RetiresOnSaturation();
|
||||
}
|
||||
```
|
||||
|
||||
or you can put the sequence of actions in the same expectation:
|
||||
|
||||
```
|
||||
// foo.Bar() should be called twice, return 1 the first time, and return
|
||||
// 2 the second time.
|
||||
EXPECT_CALL(foo, Bar())
|
||||
.WillOnce(Return(1))
|
||||
.WillOnce(Return(2))
|
||||
.RetiresOnSaturation();
|
||||
```
|
||||
|
||||
Back to the original questions: why does Google Mock search the
|
||||
expectations (and `ON_CALL`s) from back to front? Because this
|
||||
allows a user to set up a mock's behavior for the common case early
|
||||
(e.g. in the mock's constructor or the test fixture's set-up phase)
|
||||
and customize it with more specific rules later. If Google Mock
|
||||
searches from front to back, this very useful pattern won't be
|
||||
possible.
|
||||
|
||||
## Google Mock prints a warning when a function without EXPECT\_CALL is called, even if I have set its behavior using ON\_CALL. Would it be reasonable not to show the warning in this case? ##
|
||||
|
||||
When choosing between being neat and being safe, we lean toward the
|
||||
latter. So the answer is that we think it's better to show the
|
||||
warning.
|
||||
|
||||
Often people write `ON_CALL`s in the mock object's
|
||||
constructor or `SetUp()`, as the default behavior rarely changes from
|
||||
test to test. Then in the test body they set the expectations, which
|
||||
are often different for each test. Having an `ON_CALL` in the set-up
|
||||
part of a test doesn't mean that the calls are expected. If there's
|
||||
no `EXPECT_CALL` and the method is called, it's possibly an error. If
|
||||
we quietly let the call go through without notifying the user, bugs
|
||||
may creep in unnoticed.
|
||||
|
||||
If, however, you are sure that the calls are OK, you can write
|
||||
|
||||
```
|
||||
EXPECT_CALL(foo, Bar(_))
|
||||
.WillRepeatedly(...);
|
||||
```
|
||||
|
||||
instead of
|
||||
|
||||
```
|
||||
ON_CALL(foo, Bar(_))
|
||||
.WillByDefault(...);
|
||||
```
|
||||
|
||||
This tells Google Mock that you do expect the calls and no warning should be
|
||||
printed.
|
||||
|
||||
Also, you can control the verbosity using the `--gmock_verbose` flag.
|
||||
If you find the output too noisy when debugging, just choose a less
|
||||
verbose level.
|
||||
|
||||
## How can I delete the mock function's argument in an action? ##
|
||||
|
||||
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()](V1_5_CookBook#Writing_New_Actions.md) or
|
||||
[MakePolymorphicAction()](V1_5_CookBook#Writing_New_Polymorphic_Actions.md),
|
||||
or you can write a stub function and invoke it using
|
||||
[Invoke()](V1_5_CookBook#Using_Functions_Methods_Functors.md).
|
||||
|
||||
## MOCK\_METHODn()'s second argument looks funny. Why don't you use the MOCK\_METHODn(Method, return\_type, arg\_1, ..., arg\_n) syntax? ##
|
||||
|
||||
What?! I think it's beautiful. :-)
|
||||
|
||||
While which syntax looks more natural is a subjective matter to some
|
||||
extent, Google Mock's syntax was chosen for several practical advantages it
|
||||
has.
|
||||
|
||||
Try to mock a function that takes a map as an argument:
|
||||
```
|
||||
virtual int GetSize(const map<int, std::string>& m);
|
||||
```
|
||||
|
||||
Using the proposed syntax, it would be:
|
||||
```
|
||||
MOCK_METHOD1(GetSize, int, const map<int, std::string>& m);
|
||||
```
|
||||
|
||||
Guess what? You'll get a compiler error as the compiler thinks that
|
||||
`const map<int, std::string>& m` are **two**, not one, arguments. To work
|
||||
around this you can use `typedef` to give the map type a name, but
|
||||
that gets in the way of your work. Google Mock's syntax avoids this
|
||||
problem as the function's argument types are protected inside a pair
|
||||
of parentheses:
|
||||
```
|
||||
// This compiles fine.
|
||||
MOCK_METHOD1(GetSize, int(const map<int, std::string>& m));
|
||||
```
|
||||
|
||||
You still need a `typedef` if the return type contains an unprotected
|
||||
comma, but that's much rarer.
|
||||
|
||||
Other advantages include:
|
||||
1. `MOCK_METHOD1(Foo, int, bool)` can leave a reader wonder whether the method returns `int` or `bool`, while there won't be such confusion using Google Mock's syntax.
|
||||
1. The way Google Mock describes a function type is nothing new, although many people may not be familiar with it. The same syntax was used in C, and the `function` library in `tr1` uses this syntax extensively. Since `tr1` will become a part of the new version of STL, we feel very comfortable to be consistent with it.
|
||||
1. The function type syntax is also used in other parts of Google Mock's API (e.g. the action interface) in order to make the implementation tractable. A user needs to learn it anyway in order to utilize Google Mock's more advanced features. We'd as well stick to the same syntax in `MOCK_METHOD*`!
|
||||
|
||||
## My code calls a static/global function. Can I mock it? ##
|
||||
|
||||
You can, but you need to make some changes.
|
||||
|
||||
In general, if you find yourself needing to mock a static function,
|
||||
it's a sign that your modules are too tightly coupled (and less
|
||||
flexible, less reusable, less testable, etc). You are probably better
|
||||
off defining a small interface and call the function through that
|
||||
interface, which then can be easily mocked. It's a bit of work
|
||||
initially, but usually pays for itself quickly.
|
||||
|
||||
This Google Testing Blog
|
||||
[post](http://googletesting.blogspot.com/2008/06/defeat-static-cling.html)
|
||||
says it excellently. Check it out.
|
||||
|
||||
## My mock object needs to do complex stuff. It's a lot of pain to specify the actions. Google Mock sucks! ##
|
||||
|
||||
I know it's not a question, but you get an answer for free any way. :-)
|
||||
|
||||
With Google Mock, you can create mocks in C++ easily. And people might be
|
||||
tempted to use them everywhere. Sometimes they work great, and
|
||||
sometimes you may find them, well, a pain to use. So, what's wrong in
|
||||
the latter case?
|
||||
|
||||
When you write a test without using mocks, you exercise the code and
|
||||
assert that it returns the correct value or that the system is in an
|
||||
expected state. This is sometimes called "state-based testing".
|
||||
|
||||
Mocks are great for what some call "interaction-based" testing:
|
||||
instead of checking the system state at the very end, mock objects
|
||||
verify that they are invoked the right way and report an error as soon
|
||||
as it arises, giving you a handle on the precise context in which the
|
||||
error was triggered. This is often more effective and economical to
|
||||
do than state-based testing.
|
||||
|
||||
If you are doing state-based testing and using a test double just to
|
||||
simulate the real object, you are probably better off using a fake.
|
||||
Using a mock in this case causes pain, as it's not a strong point for
|
||||
mocks to perform complex actions. If you experience this and think
|
||||
that mocks suck, you are just not using the right tool for your
|
||||
problem. Or, you might be trying to solve the wrong problem. :-)
|
||||
|
||||
## I got a warning "Uninteresting function call encountered - default action taken.." Should I panic? ##
|
||||
|
||||
By all means, NO! It's just an FYI.
|
||||
|
||||
What it means is that you have a mock function, you haven't set any
|
||||
expectations on it (by Google Mock's rule this means that you are not
|
||||
interested in calls to this function and therefore it can be called
|
||||
any number of times), and it is called. That's OK - you didn't say
|
||||
it's not OK to call the function!
|
||||
|
||||
What if you actually meant to disallow this function to be called, but
|
||||
forgot to write `EXPECT_CALL(foo, Bar()).Times(0)`? While
|
||||
one can argue that it's the user's fault, Google Mock tries to be nice and
|
||||
prints you a note.
|
||||
|
||||
So, when you see the message and believe that there shouldn't be any
|
||||
uninteresting calls, you should investigate what's going on. To make
|
||||
your life easier, Google Mock prints the function name and arguments
|
||||
when an uninteresting call is encountered.
|
||||
|
||||
## I want to define a custom action. Should I use Invoke() or implement the action interface? ##
|
||||
|
||||
Either way is fine - you want to choose the one that's more convenient
|
||||
for your circumstance.
|
||||
|
||||
Usually, if your action is for a particular function type, defining it
|
||||
using `Invoke()` should be easier; if your action can be used in
|
||||
functions of different types (e.g. if you are defining
|
||||
`Return(value)`), `MakePolymorphicAction()` is
|
||||
easiest. Sometimes you want precise control on what types of
|
||||
functions the action can be used in, and implementing
|
||||
`ActionInterface` is the way to go here. See the implementation of
|
||||
`Return()` in `include/gmock/gmock-actions.h` for an example.
|
||||
|
||||
## I'm using the set-argument-pointee action, and the compiler complains about "conflicting return type specified". What does it mean? ##
|
||||
|
||||
You got this error as Google Mock has no idea what value it should return
|
||||
when the mock method is called. `SetArgumentPointee()` says what the
|
||||
side effect is, but doesn't say what the return value should be. You
|
||||
need `DoAll()` to chain a `SetArgumentPointee()` with a `Return()`.
|
||||
|
||||
See this [recipe](V1_5_CookBook#Mocking_Side_Effects.md) for more details and an example.
|
||||
|
||||
|
||||
## My question is not 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/googlemock/w/list),
|
||||
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_
|
||||
a good way to get your answer, as it is monitored infrequently by a
|
||||
very small number of people.
|
||||
|
||||
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 Mock you use (Google Mock 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.
|
||||
534
test/gtest-1.8.0/googlemock/docs/v1_6/CheatSheet.md
Normal file
534
test/gtest-1.8.0/googlemock/docs/v1_6/CheatSheet.md
Normal file
@@ -0,0 +1,534 @@
|
||||
|
||||
|
||||
# Defining a Mock Class #
|
||||
|
||||
## Mocking a Normal Class ##
|
||||
|
||||
Given
|
||||
```
|
||||
class Foo {
|
||||
...
|
||||
virtual ~Foo();
|
||||
virtual int GetSize() const = 0;
|
||||
virtual string Describe(const char* name) = 0;
|
||||
virtual string Describe(int type) = 0;
|
||||
virtual bool Process(Bar elem, int count) = 0;
|
||||
};
|
||||
```
|
||||
(note that `~Foo()` **must** be virtual) we can define its mock as
|
||||
```
|
||||
#include "gmock/gmock.h"
|
||||
|
||||
class MockFoo : public Foo {
|
||||
MOCK_CONST_METHOD0(GetSize, int());
|
||||
MOCK_METHOD1(Describe, string(const char* name));
|
||||
MOCK_METHOD1(Describe, string(int type));
|
||||
MOCK_METHOD2(Process, bool(Bar elem, int count));
|
||||
};
|
||||
```
|
||||
|
||||
To create a "nice" mock object which ignores all uninteresting calls,
|
||||
or a "strict" mock object, which treats them as failures:
|
||||
```
|
||||
NiceMock<MockFoo> nice_foo; // The type is a subclass of MockFoo.
|
||||
StrictMock<MockFoo> strict_foo; // The type is a subclass of MockFoo.
|
||||
```
|
||||
|
||||
## Mocking a Class Template ##
|
||||
|
||||
To mock
|
||||
```
|
||||
template <typename Elem>
|
||||
class StackInterface {
|
||||
public:
|
||||
...
|
||||
virtual ~StackInterface();
|
||||
virtual int GetSize() const = 0;
|
||||
virtual void Push(const Elem& x) = 0;
|
||||
};
|
||||
```
|
||||
(note that `~StackInterface()` **must** be virtual) just append `_T` to the `MOCK_*` macros:
|
||||
```
|
||||
template <typename Elem>
|
||||
class MockStack : public StackInterface<Elem> {
|
||||
public:
|
||||
...
|
||||
MOCK_CONST_METHOD0_T(GetSize, int());
|
||||
MOCK_METHOD1_T(Push, void(const Elem& x));
|
||||
};
|
||||
```
|
||||
|
||||
## Specifying Calling Conventions for Mock Functions ##
|
||||
|
||||
If your mock function doesn't use the default calling convention, you
|
||||
can specify it by appending `_WITH_CALLTYPE` to any of the macros
|
||||
described in the previous two sections and supplying the calling
|
||||
convention as the first argument to the macro. For example,
|
||||
```
|
||||
MOCK_METHOD_1_WITH_CALLTYPE(STDMETHODCALLTYPE, Foo, bool(int n));
|
||||
MOCK_CONST_METHOD2_WITH_CALLTYPE(STDMETHODCALLTYPE, Bar, int(double x, double y));
|
||||
```
|
||||
where `STDMETHODCALLTYPE` is defined by `<objbase.h>` on Windows.
|
||||
|
||||
# Using Mocks in Tests #
|
||||
|
||||
The typical flow is:
|
||||
1. Import the Google Mock names you need to use. All Google Mock names are in the `testing` namespace unless they are macros or otherwise noted.
|
||||
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. When a mock objects is destructed, Google Mock automatically verifies that all expectations on it have been satisfied.
|
||||
|
||||
Here is an example:
|
||||
```
|
||||
using ::testing::Return; // #1
|
||||
|
||||
TEST(BarTest, DoesThis) {
|
||||
MockFoo foo; // #2
|
||||
|
||||
ON_CALL(foo, GetSize()) // #3
|
||||
.WillByDefault(Return(1));
|
||||
// ... other default actions ...
|
||||
|
||||
EXPECT_CALL(foo, Describe(5)) // #4
|
||||
.Times(3)
|
||||
.WillRepeatedly(Return("Category 5"));
|
||||
// ... other expectations ...
|
||||
|
||||
EXPECT_EQ("good", MyProductionFunction(&foo)); // #5
|
||||
} // #6
|
||||
```
|
||||
|
||||
# Setting Default Actions #
|
||||
|
||||
Google Mock has a **built-in default action** for any function that
|
||||
returns `void`, `bool`, a numeric value, or a pointer.
|
||||
|
||||
To customize the default action for functions with return type `T` globally:
|
||||
```
|
||||
using ::testing::DefaultValue;
|
||||
|
||||
DefaultValue<T>::Set(value); // Sets the default value to be returned.
|
||||
// ... use the mocks ...
|
||||
DefaultValue<T>::Clear(); // Resets the default value.
|
||||
```
|
||||
|
||||
To customize the default action for a particular method, use `ON_CALL()`:
|
||||
```
|
||||
ON_CALL(mock_object, method(matchers))
|
||||
.With(multi_argument_matcher) ?
|
||||
.WillByDefault(action);
|
||||
```
|
||||
|
||||
# Setting Expectations #
|
||||
|
||||
`EXPECT_CALL()` sets **expectations** on a mock method (How will it be
|
||||
called? What will it do?):
|
||||
```
|
||||
EXPECT_CALL(mock_object, method(matchers))
|
||||
.With(multi_argument_matcher) ?
|
||||
.Times(cardinality) ?
|
||||
.InSequence(sequences) *
|
||||
.After(expectations) *
|
||||
.WillOnce(action) *
|
||||
.WillRepeatedly(action) ?
|
||||
.RetiresOnSaturation(); ?
|
||||
```
|
||||
|
||||
If `Times()` is omitted, the cardinality is assumed to be:
|
||||
|
||||
* `Times(1)` when there is neither `WillOnce()` nor `WillRepeatedly()`;
|
||||
* `Times(n)` when there are `n WillOnce()`s but no `WillRepeatedly()`, where `n` >= 1; or
|
||||
* `Times(AtLeast(n))` when there are `n WillOnce()`s and a `WillRepeatedly()`, where `n` >= 0.
|
||||
|
||||
A method with no `EXPECT_CALL()` is free to be invoked _any number of times_, and the default action will be taken each time.
|
||||
|
||||
# Matchers #
|
||||
|
||||
A **matcher** matches a _single_ argument. You can use it inside
|
||||
`ON_CALL()` or `EXPECT_CALL()`, or use it to validate a value
|
||||
directly:
|
||||
|
||||
| `EXPECT_THAT(value, matcher)` | Asserts that `value` matches `matcher`. |
|
||||
|:------------------------------|:----------------------------------------|
|
||||
| `ASSERT_THAT(value, matcher)` | The same as `EXPECT_THAT(value, matcher)`, except that it generates a **fatal** failure. |
|
||||
|
||||
Built-in matchers (where `argument` is the function argument) are
|
||||
divided into several categories:
|
||||
|
||||
## Wildcard ##
|
||||
|`_`|`argument` can be any value of the correct type.|
|
||||
|:--|:-----------------------------------------------|
|
||||
|`A<type>()` or `An<type>()`|`argument` can be any value of type `type`. |
|
||||
|
||||
## Generic Comparison ##
|
||||
|
||||
|`Eq(value)` or `value`|`argument == value`|
|
||||
|:---------------------|:------------------|
|
||||
|`Ge(value)` |`argument >= value`|
|
||||
|`Gt(value)` |`argument > value` |
|
||||
|`Le(value)` |`argument <= value`|
|
||||
|`Lt(value)` |`argument < value` |
|
||||
|`Ne(value)` |`argument != value`|
|
||||
|`IsNull()` |`argument` is a `NULL` pointer (raw or smart).|
|
||||
|`NotNull()` |`argument` is a non-null pointer (raw or smart).|
|
||||
|`Ref(variable)` |`argument` is a reference to `variable`.|
|
||||
|`TypedEq<type>(value)`|`argument` has type `type` and is equal to `value`. You may need to use this instead of `Eq(value)` when the mock function is overloaded.|
|
||||
|
||||
Except `Ref()`, these matchers make a _copy_ of `value` in case it's
|
||||
modified or destructed later. If the compiler complains that `value`
|
||||
doesn't have a public copy constructor, try wrap it in `ByRef()`,
|
||||
e.g. `Eq(ByRef(non_copyable_value))`. If you do that, make sure
|
||||
`non_copyable_value` is not changed afterwards, or the meaning of your
|
||||
matcher will be changed.
|
||||
|
||||
## Floating-Point Matchers ##
|
||||
|
||||
|`DoubleEq(a_double)`|`argument` is a `double` value approximately equal to `a_double`, treating two NaNs as unequal.|
|
||||
|:-------------------|:----------------------------------------------------------------------------------------------|
|
||||
|`FloatEq(a_float)` |`argument` is a `float` value approximately equal to `a_float`, treating two NaNs as unequal. |
|
||||
|`NanSensitiveDoubleEq(a_double)`|`argument` is a `double` value approximately equal to `a_double`, treating two NaNs as equal. |
|
||||
|`NanSensitiveFloatEq(a_float)`|`argument` is a `float` value approximately equal to `a_float`, treating two NaNs as equal. |
|
||||
|
||||
These matchers use ULP-based comparison (the same as used in
|
||||
[Google Test](http://code.google.com/p/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
|
||||
return false. The `NanSensitive*` version instead treats two NaNs as
|
||||
equal, which is often what a user wants.
|
||||
|
||||
## String Matchers ##
|
||||
|
||||
The `argument` can be either a C string or a C++ string object:
|
||||
|
||||
|`ContainsRegex(string)`|`argument` matches the given regular expression.|
|
||||
|:----------------------|:-----------------------------------------------|
|
||||
|`EndsWith(suffix)` |`argument` ends with string `suffix`. |
|
||||
|`HasSubstr(string)` |`argument` contains `string` as a sub-string. |
|
||||
|`MatchesRegex(string)` |`argument` matches the given regular expression with the match starting at the first character and ending at the last character.|
|
||||
|`StartsWith(prefix)` |`argument` starts with string `prefix`. |
|
||||
|`StrCaseEq(string)` |`argument` is equal to `string`, ignoring case. |
|
||||
|`StrCaseNe(string)` |`argument` is not equal to `string`, ignoring case.|
|
||||
|`StrEq(string)` |`argument` is equal to `string`. |
|
||||
|`StrNe(string)` |`argument` is not equal to `string`. |
|
||||
|
||||
`ContainsRegex()` and `MatchesRegex()` use the regular expression
|
||||
syntax defined
|
||||
[here](http://code.google.com/p/googletest/wiki/V1_6_AdvancedGuide#Regular_Expression_Syntax).
|
||||
`StrCaseEq()`, `StrCaseNe()`, `StrEq()`, and `StrNe()` work for wide
|
||||
strings as well.
|
||||
|
||||
## Container Matchers ##
|
||||
|
||||
Most STL-style containers support `==`, so you can use
|
||||
`Eq(expected_container)` or simply `expected_container` to match a
|
||||
container exactly. If you want to write the elements in-line,
|
||||
match them more flexibly, or get more informative messages, you can use:
|
||||
|
||||
| `Contains(e)` | `argument` contains an element that matches `e`, which can be either a value or a matcher. |
|
||||
|:--------------|:-------------------------------------------------------------------------------------------|
|
||||
| `Each(e)` | `argument` is a container where _every_ element matches `e`, which can be either a value or a matcher. |
|
||||
| `ElementsAre(e0, e1, ..., en)` | `argument` has `n + 1` elements, where the i-th element matches `ei`, which can be a value or a matcher. 0 to 10 arguments are allowed. |
|
||||
| `ElementsAreArray(array)` or `ElementsAreArray(array, count)` | The same as `ElementsAre()` except that the expected element values/matchers come from a C-style array. |
|
||||
| `ContainerEq(container)` | The same as `Eq(container)` except that the failure message also includes which elements are in one container but not the other. |
|
||||
| `Pointwise(m, container)` | `argument` contains the same number of elements as in `container`, and for all i, (the i-th element in `argument`, the i-th element in `container`) match `m`, which is a matcher on 2-tuples. E.g. `Pointwise(Le(), upper_bounds)` verifies that each element in `argument` doesn't exceed the corresponding element in `upper_bounds`. |
|
||||
|
||||
These matchers can also match:
|
||||
|
||||
1. a native array passed by reference (e.g. in `Foo(const int (&a)[5])`), and
|
||||
1. an array passed as a pointer and a count (e.g. in `Bar(const T* buffer, int len)` -- see [Multi-argument Matchers](#Multiargument_Matchers.md)).
|
||||
|
||||
where the array may be multi-dimensional (i.e. its elements can be arrays).
|
||||
|
||||
## Member Matchers ##
|
||||
|
||||
|`Field(&class::field, m)`|`argument.field` (or `argument->field` when `argument` is a plain pointer) matches matcher `m`, where `argument` is an object of type _class_.|
|
||||
|:------------------------|:---------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
|`Key(e)` |`argument.first` matches `e`, which can be either a value or a matcher. E.g. `Contains(Key(Le(5)))` can verify that a `map` contains a key `<= 5`.|
|
||||
|`Pair(m1, m2)` |`argument` is an `std::pair` whose `first` field matches `m1` and `second` field matches `m2`. |
|
||||
|`Property(&class::property, m)`|`argument.property()` (or `argument->property()` when `argument` is a plain pointer) matches matcher `m`, where `argument` is an object of type _class_.|
|
||||
|
||||
## Matching the Result of a Function or Functor ##
|
||||
|
||||
|`ResultOf(f, m)`|`f(argument)` matches matcher `m`, where `f` is a function or functor.|
|
||||
|:---------------|:---------------------------------------------------------------------|
|
||||
|
||||
## Pointer Matchers ##
|
||||
|
||||
|`Pointee(m)`|`argument` (either a smart pointer or a raw pointer) points to a value that matches matcher `m`.|
|
||||
|:-----------|:-----------------------------------------------------------------------------------------------|
|
||||
|
||||
## Multiargument Matchers ##
|
||||
|
||||
Technically, all matchers match a _single_ value. A "multi-argument"
|
||||
matcher is just one that matches a _tuple_. The following matchers can
|
||||
be used to match a tuple `(x, y)`:
|
||||
|
||||
|`Eq()`|`x == y`|
|
||||
|:-----|:-------|
|
||||
|`Ge()`|`x >= y`|
|
||||
|`Gt()`|`x > y` |
|
||||
|`Le()`|`x <= y`|
|
||||
|`Lt()`|`x < y` |
|
||||
|`Ne()`|`x != y`|
|
||||
|
||||
You can use the following selectors to pick a subset of the arguments
|
||||
(or reorder them) to participate in the matching:
|
||||
|
||||
|`AllArgs(m)`|Equivalent to `m`. Useful as syntactic sugar in `.With(AllArgs(m))`.|
|
||||
|:-----------|:-------------------------------------------------------------------|
|
||||
|`Args<N1, N2, ..., Nk>(m)`|The tuple of the `k` selected (using 0-based indices) arguments matches `m`, e.g. `Args<1, 2>(Eq())`.|
|
||||
|
||||
## Composite Matchers ##
|
||||
|
||||
You can make a matcher from one or more other matchers:
|
||||
|
||||
|`AllOf(m1, m2, ..., mn)`|`argument` matches all of the matchers `m1` to `mn`.|
|
||||
|:-----------------------|:---------------------------------------------------|
|
||||
|`AnyOf(m1, m2, ..., mn)`|`argument` matches at least one of the matchers `m1` to `mn`.|
|
||||
|`Not(m)` |`argument` doesn't match matcher `m`. |
|
||||
|
||||
## Adapters for Matchers ##
|
||||
|
||||
|`MatcherCast<T>(m)`|casts matcher `m` to type `Matcher<T>`.|
|
||||
|:------------------|:--------------------------------------|
|
||||
|`SafeMatcherCast<T>(m)`| [safely casts](http://code.google.com/p/googlemock/wiki/V1_6_CookBook#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 ##
|
||||
|
||||
|`Matches(m)(value)`|evaluates to `true` if `value` matches `m`. You can use `Matches(m)` alone as a unary functor.|
|
||||
|:------------------|:---------------------------------------------------------------------------------------------|
|
||||
|`ExplainMatchResult(m, value, result_listener)`|evaluates to `true` if `value` matches `m`, explaining the result to `result_listener`. |
|
||||
|`Value(value, m)` |evaluates to `true` if `value` matches `m`. |
|
||||
|
||||
## Defining Matchers ##
|
||||
|
||||
| `MATCHER(IsEven, "") { return (arg % 2) == 0; }` | Defines a matcher `IsEven()` to match an even number. |
|
||||
|:-------------------------------------------------|:------------------------------------------------------|
|
||||
| `MATCHER_P(IsDivisibleBy, n, "") { *result_listener << "where the remainder is " << (arg % n); return (arg % n) == 0; }` | Defines a macher `IsDivisibleBy(n)` to match a number divisible by `n`. |
|
||||
| `MATCHER_P2(IsBetween, a, b, std::string(negation ? "isn't" : "is") + " between " + PrintToString(a) + " and " + PrintToString(b)) { return a <= arg && arg <= b; }` | Defines a matcher `IsBetween(a, b)` to match a value in the range [`a`, `b`]. |
|
||||
|
||||
**Notes:**
|
||||
|
||||
1. The `MATCHER*` macros cannot be used inside a function or class.
|
||||
1. The matcher body must be _purely functional_ (i.e. it cannot have any side effect, and the result must not depend on anything other than the value being matched and the matcher parameters).
|
||||
1. You can use `PrintToString(x)` to convert a value `x` of any type to a string.
|
||||
|
||||
## Matchers as Test Assertions ##
|
||||
|
||||
|`ASSERT_THAT(expression, m)`|Generates a [fatal failure](http://code.google.com/p/googletest/wiki/V1_6_Primer#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`. |
|
||||
|
||||
# Actions #
|
||||
|
||||
**Actions** specify what a mock function should do when invoked.
|
||||
|
||||
## Returning a Value ##
|
||||
|
||||
|`Return()`|Return from a `void` mock function.|
|
||||
|:---------|:----------------------------------|
|
||||
|`Return(value)`|Return `value`. If the type of `value` is different to the mock function's return type, `value` is converted to the latter type <i>at the time the expectation is set</i>, not when the action is executed.|
|
||||
|`ReturnArg<N>()`|Return the `N`-th (0-based) argument.|
|
||||
|`ReturnNew<T>(a1, ..., ak)`|Return `new T(a1, ..., ak)`; a different object is created each time.|
|
||||
|`ReturnNull()`|Return a null pointer. |
|
||||
|`ReturnPointee(ptr)`|Return the value pointed to by `ptr`.|
|
||||
|`ReturnRef(variable)`|Return a reference to `variable`. |
|
||||
|`ReturnRefOfCopy(value)`|Return a reference to a copy of `value`; the copy lives as long as the action.|
|
||||
|
||||
## Side Effects ##
|
||||
|
||||
|`Assign(&variable, value)`|Assign `value` to variable.|
|
||||
|:-------------------------|:--------------------------|
|
||||
| `DeleteArg<N>()` | Delete the `N`-th (0-based) argument, which must be a pointer. |
|
||||
| `SaveArg<N>(pointer)` | Save the `N`-th (0-based) argument to `*pointer`. |
|
||||
| `SaveArgPointee<N>(pointer)` | Save the value pointed to by the `N`-th (0-based) argument to `*pointer`. |
|
||||
| `SetArgReferee<N>(value)` | Assign value to the variable referenced by the `N`-th (0-based) argument. |
|
||||
|`SetArgPointee<N>(value)` |Assign `value` to the variable pointed by the `N`-th (0-based) argument.|
|
||||
|`SetArgumentPointee<N>(value)`|Same as `SetArgPointee<N>(value)`. Deprecated. Will be removed in v1.7.0.|
|
||||
|`SetArrayArgument<N>(first, last)`|Copies the elements in source range [`first`, `last`) to the array pointed to by the `N`-th (0-based) argument, which can be either a pointer or an iterator. The action does not take ownership of the elements in the source range.|
|
||||
|`SetErrnoAndReturn(error, value)`|Set `errno` to `error` and return `value`.|
|
||||
|`Throw(exception)` |Throws the given exception, which can be any copyable value. Available since v1.1.0.|
|
||||
|
||||
## Using a Function or a Functor as an Action ##
|
||||
|
||||
|`Invoke(f)`|Invoke `f` with the arguments passed to the mock function, where `f` can be a global/static function or a functor.|
|
||||
|:----------|:-----------------------------------------------------------------------------------------------------------------|
|
||||
|`Invoke(object_pointer, &class::method)`|Invoke the {method on the object with the arguments passed to the mock function. |
|
||||
|`InvokeWithoutArgs(f)`|Invoke `f`, which can be a global/static function or a functor. `f` must take no arguments. |
|
||||
|`InvokeWithoutArgs(object_pointer, &class::method)`|Invoke the method on the object, which takes no arguments. |
|
||||
|`InvokeArgument<N>(arg1, arg2, ..., argk)`|Invoke the mock function's `N`-th (0-based) argument, which must be a function or a functor, with the `k` arguments.|
|
||||
|
||||
The return value of the invoked function is used as the return value
|
||||
of the action.
|
||||
|
||||
When defining a function or functor to be used with `Invoke*()`, you can declare any unused parameters as `Unused`:
|
||||
```
|
||||
double Distance(Unused, double x, double y) { return sqrt(x*x + y*y); }
|
||||
...
|
||||
EXPECT_CALL(mock, Foo("Hi", _, _)).WillOnce(Invoke(Distance));
|
||||
```
|
||||
|
||||
In `InvokeArgument<N>(...)`, if an argument needs to be passed by reference, wrap it inside `ByRef()`. For example,
|
||||
```
|
||||
InvokeArgument<2>(5, string("Hi"), ByRef(foo))
|
||||
```
|
||||
calls the mock function's #2 argument, passing to it `5` and `string("Hi")` by value, and `foo` by reference.
|
||||
|
||||
## Default Action ##
|
||||
|
||||
|`DoDefault()`|Do the default action (specified by `ON_CALL()` or the built-in one).|
|
||||
|:------------|:--------------------------------------------------------------------|
|
||||
|
||||
**Note:** due to technical reasons, `DoDefault()` cannot be used inside a composite action - trying to do so will result in a run-time error.
|
||||
|
||||
## Composite Actions ##
|
||||
|
||||
|`DoAll(a1, a2, ..., an)`|Do all actions `a1` to `an` and return the result of `an` in each invocation. The first `n - 1` sub-actions must return void. |
|
||||
|:-----------------------|:-----------------------------------------------------------------------------------------------------------------------------|
|
||||
|`IgnoreResult(a)` |Perform action `a` and ignore its result. `a` must not return void. |
|
||||
|`WithArg<N>(a)` |Pass the `N`-th (0-based) argument of the mock function to action `a` and perform it. |
|
||||
|`WithArgs<N1, N2, ..., Nk>(a)`|Pass the selected (0-based) arguments of the mock function to action `a` and perform it. |
|
||||
|`WithoutArgs(a)` |Perform action `a` without any arguments. |
|
||||
|
||||
## Defining Actions ##
|
||||
|
||||
| `ACTION(Sum) { return arg0 + arg1; }` | Defines an action `Sum()` to return the sum of the mock function's argument #0 and #1. |
|
||||
|:--------------------------------------|:---------------------------------------------------------------------------------------|
|
||||
| `ACTION_P(Plus, n) { return arg0 + n; }` | Defines an action `Plus(n)` to return the sum of the mock function's argument #0 and `n`. |
|
||||
| `ACTION_Pk(Foo, p1, ..., pk) { statements; }` | Defines a parameterized action `Foo(p1, ..., pk)` to execute the given `statements`. |
|
||||
|
||||
The `ACTION*` macros cannot be used inside a function or class.
|
||||
|
||||
# Cardinalities #
|
||||
|
||||
These are used in `Times()` to specify how many times a mock function will be called:
|
||||
|
||||
|`AnyNumber()`|The function can be called any number of times.|
|
||||
|:------------|:----------------------------------------------|
|
||||
|`AtLeast(n)` |The call is expected at least `n` times. |
|
||||
|`AtMost(n)` |The call is expected at most `n` times. |
|
||||
|`Between(m, n)`|The call is expected between `m` and `n` (inclusive) times.|
|
||||
|`Exactly(n) or n`|The call is expected exactly `n` times. In particular, the call should never happen when `n` is 0.|
|
||||
|
||||
# Expectation Order #
|
||||
|
||||
By default, the expectations can be matched in _any_ order. If some
|
||||
or all expectations must be matched in a given order, there are two
|
||||
ways to specify it. They can be used either independently or
|
||||
together.
|
||||
|
||||
## The After Clause ##
|
||||
|
||||
```
|
||||
using ::testing::Expectation;
|
||||
...
|
||||
Expectation init_x = EXPECT_CALL(foo, InitX());
|
||||
Expectation init_y = EXPECT_CALL(foo, InitY());
|
||||
EXPECT_CALL(foo, Bar())
|
||||
.After(init_x, init_y);
|
||||
```
|
||||
says that `Bar()` can be called only after both `InitX()` and
|
||||
`InitY()` have been called.
|
||||
|
||||
If you don't know how many pre-requisites an expectation has when you
|
||||
write it, you can use an `ExpectationSet` to collect them:
|
||||
|
||||
```
|
||||
using ::testing::ExpectationSet;
|
||||
...
|
||||
ExpectationSet all_inits;
|
||||
for (int i = 0; i < element_count; i++) {
|
||||
all_inits += EXPECT_CALL(foo, InitElement(i));
|
||||
}
|
||||
EXPECT_CALL(foo, Bar())
|
||||
.After(all_inits);
|
||||
```
|
||||
says that `Bar()` can be called only after all elements have been
|
||||
initialized (but we don't care about which elements get initialized
|
||||
before the others).
|
||||
|
||||
Modifying an `ExpectationSet` after using it in an `.After()` doesn't
|
||||
affect the meaning of the `.After()`.
|
||||
|
||||
## Sequences ##
|
||||
|
||||
When you have a long chain of sequential expectations, it's easier to
|
||||
specify the order using **sequences**, which don't require you to given
|
||||
each expectation in the chain a different name. <i>All expected<br>
|
||||
calls</i> in the same sequence must occur in the order they are
|
||||
specified.
|
||||
|
||||
```
|
||||
using ::testing::Sequence;
|
||||
Sequence s1, s2;
|
||||
...
|
||||
EXPECT_CALL(foo, Reset())
|
||||
.InSequence(s1, s2)
|
||||
.WillOnce(Return(true));
|
||||
EXPECT_CALL(foo, GetSize())
|
||||
.InSequence(s1)
|
||||
.WillOnce(Return(1));
|
||||
EXPECT_CALL(foo, Describe(A<const char*>()))
|
||||
.InSequence(s2)
|
||||
.WillOnce(Return("dummy"));
|
||||
```
|
||||
says that `Reset()` must be called before _both_ `GetSize()` _and_
|
||||
`Describe()`, and the latter two can occur in any order.
|
||||
|
||||
To put many expectations in a sequence conveniently:
|
||||
```
|
||||
using ::testing::InSequence;
|
||||
{
|
||||
InSequence dummy;
|
||||
|
||||
EXPECT_CALL(...)...;
|
||||
EXPECT_CALL(...)...;
|
||||
...
|
||||
EXPECT_CALL(...)...;
|
||||
}
|
||||
```
|
||||
says that all expected calls in the scope of `dummy` must occur in
|
||||
strict order. The name `dummy` is irrelevant.)
|
||||
|
||||
# Verifying and Resetting a Mock #
|
||||
|
||||
Google Mock will verify the expectations on a mock object when it is destructed, or you can do it earlier:
|
||||
```
|
||||
using ::testing::Mock;
|
||||
...
|
||||
// Verifies and removes the expectations on mock_obj;
|
||||
// returns true iff successful.
|
||||
Mock::VerifyAndClearExpectations(&mock_obj);
|
||||
...
|
||||
// Verifies and removes the expectations on mock_obj;
|
||||
// also removes the default actions set by ON_CALL();
|
||||
// returns true iff successful.
|
||||
Mock::VerifyAndClear(&mock_obj);
|
||||
```
|
||||
|
||||
You can also tell Google Mock that a mock object can be leaked and doesn't
|
||||
need to be verified:
|
||||
```
|
||||
Mock::AllowLeak(&mock_obj);
|
||||
```
|
||||
|
||||
# Mock Classes #
|
||||
|
||||
Google Mock defines a convenient mock class template
|
||||
```
|
||||
class MockFunction<R(A1, ..., An)> {
|
||||
public:
|
||||
MOCK_METHODn(Call, R(A1, ..., An));
|
||||
};
|
||||
```
|
||||
See this [recipe](http://code.google.com/p/googlemock/wiki/V1_6_CookBook#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. |
|
||||
3342
test/gtest-1.8.0/googlemock/docs/v1_6/CookBook.md
Normal file
3342
test/gtest-1.8.0/googlemock/docs/v1_6/CookBook.md
Normal file
File diff suppressed because it is too large
Load Diff
12
test/gtest-1.8.0/googlemock/docs/v1_6/Documentation.md
Normal file
12
test/gtest-1.8.0/googlemock/docs/v1_6/Documentation.md
Normal file
@@ -0,0 +1,12 @@
|
||||
This page lists all documentation wiki pages for Google Mock **1.6**
|
||||
- **if you use a released version of Google Mock, please read the documentation for that specific version instead.**
|
||||
|
||||
* [ForDummies](V1_6_ForDummies.md) -- start here if you are new to Google Mock.
|
||||
* [CheatSheet](V1_6_CheatSheet.md) -- a quick reference.
|
||||
* [CookBook](V1_6_CookBook.md) -- recipes for doing various tasks using Google Mock.
|
||||
* [FrequentlyAskedQuestions](V1_6_FrequentlyAskedQuestions.md) -- check here before asking a question on the mailing list.
|
||||
|
||||
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/V1_6_PumpManual) -- how we generate some of Google Mock's source files.
|
||||
439
test/gtest-1.8.0/googlemock/docs/v1_6/ForDummies.md
Normal file
439
test/gtest-1.8.0/googlemock/docs/v1_6/ForDummies.md
Normal file
@@ -0,0 +1,439 @@
|
||||
|
||||
|
||||
(**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/V1_6_FrequentlyAskedQuestions#How_am_I_supposed_to_make_sense_of_these_horrible_template_error).)
|
||||
|
||||
# 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).
|
||||
|
||||
**Note:** It is easy to confuse the term _fake objects_ with mock objects. Fakes and mocks actually mean very different things in the Test-Driven Development (TDD) community:
|
||||
|
||||
* **Fake** objects have working implementations, but usually take some shortcut (perhaps to make the operations less expensive), which makes them not suitable for production. An in-memory file system would be an example of a fake.
|
||||
* **Mocks** are objects pre-programmed with _expectations_, which form a specification of the calls they are expected to receive.
|
||||
|
||||
If all this seems too abstract for you, don't worry - the most important thing to remember is that a mock allows you to check the _interaction_ between itself and code that uses it. The difference between fakes and mocks will become much clearer once you start to use mocks.
|
||||
|
||||
**Google C++ Mocking Framework** (or **Google Mock** for short) is a library (sometimes we also call it a "framework" to make it sound cool) for creating mock classes and using them. It does to C++ what [jMock](http://www.jmock.org/) and [EasyMock](http://www.easymock.org/) do to Java.
|
||||
|
||||
Using Google Mock involves three basic steps:
|
||||
|
||||
1. Use some simple macros to describe the interface you want to mock, and they will expand to the implementation of your mock class;
|
||||
1. Create some mock objects and specify its expectations and behavior using an intuitive syntax;
|
||||
1. Exercise code that uses the mock objects. Google Mock will catch any violation of the expectations as soon as it arises.
|
||||
|
||||
# Why Google Mock? #
|
||||
While mock objects help you remove unnecessary dependencies in tests and make them fast and reliable, using mocks manually in C++ is _hard_:
|
||||
|
||||
* Someone has to implement the mocks. The job is usually tedious and error-prone. No wonder people go great distance to avoid it.
|
||||
* The quality of those manually written mocks is a bit, uh, unpredictable. You may see some really polished ones, but you may also see some that were hacked up in a hurry and have all sorts of ad hoc restrictions.
|
||||
* The knowledge you gained from using one mock doesn't transfer to the next.
|
||||
|
||||
In contrast, Java and Python programmers have some fine mock frameworks, which automate the creation of mocks. As a result, mocking is a proven effective technique and widely adopted practice in those communities. Having the right tool absolutely makes the difference.
|
||||
|
||||
Google Mock was built to help C++ programmers. It was inspired by [jMock](http://www.jmock.org/) and [EasyMock](http://www.easymock.org/), but designed with C++'s specifics in mind. It is your friend if any of the following problems is bothering you:
|
||||
|
||||
* You are stuck with a sub-optimal design and wish you had done more prototyping before it was too late, but prototyping in C++ is by no means "rapid".
|
||||
* Your tests are slow as they depend on too many libraries or use expensive resources (e.g. a database).
|
||||
* Your tests are brittle as some resources they use are unreliable (e.g. the network).
|
||||
* You want to test how your code handles a failure (e.g. a file checksum error), but it's not easy to cause one.
|
||||
* You need to make sure that your module interacts with other modules in the right way, but it's hard to observe the interaction; therefore you resort to observing the side effects at the end of the action, which is awkward at best.
|
||||
* You want to "mock out" your dependencies, except that they don't have mock implementations yet; and, frankly, you aren't thrilled by some of those hand-written mocks.
|
||||
|
||||
We encourage you to use Google Mock as:
|
||||
|
||||
* a _design_ tool, for it lets you experiment with your interface design early and often. More iterations lead to better designs!
|
||||
* 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.
|
||||
|
||||
# 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:
|
||||
|
||||
```
|
||||
class Turtle {
|
||||
...
|
||||
virtual ~Turtle() {}
|
||||
virtual void PenUp() = 0;
|
||||
virtual void PenDown() = 0;
|
||||
virtual void Forward(int distance) = 0;
|
||||
virtual void Turn(int degrees) = 0;
|
||||
virtual void GoTo(int x, int y) = 0;
|
||||
virtual int GetX() const = 0;
|
||||
virtual int GetY() const = 0;
|
||||
};
|
||||
```
|
||||
|
||||
(Note that the destructor of `Turtle` **must** be virtual, as is the case for **all** classes you intend to inherit from - otherwise the destructor of the derived class will not be called when you delete an object through a base pointer, and you'll get corrupted program states like memory leaks.)
|
||||
|
||||
You can control whether the turtle's movement will leave a trace using `PenUp()` and `PenDown()`, and control its movement using `Forward()`, `Turn()`, and `GoTo()`. Finally, `GetX()` and `GetY()` tell you the current position of the turtle.
|
||||
|
||||
Your program will normally use a real implementation of this interface. In tests, you can use a mock implementation instead. This allows you to easily check what drawing primitives your program is calling, with what arguments, and in which order. Tests written this way are much more robust (they won't break because your new machine does anti-aliasing differently), easier to read and maintain (the intent of a test is expressed in the code, not in some binary images), and run _much, much faster_.
|
||||
|
||||
# Writing the Mock Class #
|
||||
If you are lucky, the mocks you need to use have already been implemented by some nice people. If, however, you find yourself in the position to write a mock class, relax - Google Mock turns this task into a fun game! (Well, almost.)
|
||||
|
||||
## How to Define It ##
|
||||
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/V1_6_CookBook#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.
|
||||
|
||||
After the process, you should have something like:
|
||||
|
||||
```
|
||||
#include "gmock/gmock.h" // Brings in Google Mock.
|
||||
class MockTurtle : public Turtle {
|
||||
public:
|
||||
...
|
||||
MOCK_METHOD0(PenUp, void());
|
||||
MOCK_METHOD0(PenDown, void());
|
||||
MOCK_METHOD1(Forward, void(int distance));
|
||||
MOCK_METHOD1(Turn, void(int degrees));
|
||||
MOCK_METHOD2(GoTo, void(int x, int y));
|
||||
MOCK_CONST_METHOD0(GetX, int());
|
||||
MOCK_CONST_METHOD0(GetY, int());
|
||||
};
|
||||
```
|
||||
|
||||
You don't need to define these mock methods somewhere else - the `MOCK_METHOD*` macros will generate the definitions for you. It's that simple! Once you get the hang of it, you can pump out mock classes faster than your source-control system can handle your check-ins.
|
||||
|
||||
**Tip:** If even this is too much work for you, you'll find the
|
||||
`gmock_gen.py` tool in Google Mock's `scripts/generator/` directory (courtesy of the [cppclean](http://code.google.com/p/cppclean/) project) useful. This command-line
|
||||
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).
|
||||
|
||||
## 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?)
|
||||
|
||||
So, the rule of thumb is: if you need to mock `Foo` and it's owned by others, define the mock class in `Foo`'s package (better, in a `testing` sub-package such that you can clearly separate production code and testing utilities), and put it in a `mock_foo.h`. Then everyone can reference `mock_foo.h` from their tests. If `Foo` ever changes, there is only one copy of `MockFoo` to change, and only tests that depend on the changed methods need to be fixed.
|
||||
|
||||
Another way to do it: you can introduce a thin layer `FooAdaptor` on top of `Foo` and code to this new interface. Since you own `FooAdaptor`, you can absorb changes in `Foo` much more easily. While this is more work initially, carefully choosing the adaptor interface can make your code easier to write and more readable (a net win in the long run), as you can choose `FooAdaptor` to fit your specific domain much better than `Foo` does.
|
||||
|
||||
# Using Mocks in Tests #
|
||||
Once you have a mock class, using it is easy. The typical work flow is:
|
||||
|
||||
1. Import the Google Mock names from the `testing` namespace such that you can use them unqualified (You only have to do it once per file. Remember that namespaces are a good idea and good for your health.).
|
||||
1. Create some mock objects.
|
||||
1. Specify your expectations on them (How many times will a method be called? With what arguments? What should it do? etc.).
|
||||
1. Exercise some code that uses the mocks; optionally, check the result using Google Test assertions. If a mock method is called more than expected or with wrong arguments, you'll get an error immediately.
|
||||
1. When a mock is destructed, Google Mock will automatically check whether all expectations on it have been satisfied.
|
||||
|
||||
Here's an example:
|
||||
|
||||
```
|
||||
#include "path/to/mock-turtle.h"
|
||||
#include "gmock/gmock.h"
|
||||
#include "gtest/gtest.h"
|
||||
using ::testing::AtLeast; // #1
|
||||
|
||||
TEST(PainterTest, CanDrawSomething) {
|
||||
MockTurtle turtle; // #2
|
||||
EXPECT_CALL(turtle, PenDown()) // #3
|
||||
.Times(AtLeast(1));
|
||||
|
||||
Painter painter(&turtle); // #4
|
||||
|
||||
EXPECT_TRUE(painter.DrawCircle(0, 0, 10));
|
||||
} // #5
|
||||
|
||||
int main(int argc, char** argv) {
|
||||
// The following line must be executed to initialize Google Mock
|
||||
// (and Google Test) before running the tests.
|
||||
::testing::InitGoogleMock(&argc, argv);
|
||||
return RUN_ALL_TESTS();
|
||||
}
|
||||
```
|
||||
|
||||
As you might have guessed, this test checks that `PenDown()` is called at least once. If the `painter` object didn't call this method, your test will fail with a message like this:
|
||||
|
||||
```
|
||||
path/to/my_test.cc:119: Failure
|
||||
Actual function call count doesn't match this expectation:
|
||||
Actually: never called;
|
||||
Expected: called at least once.
|
||||
```
|
||||
|
||||
**Tip 1:** If you run the test from an Emacs buffer, you can hit `<Enter>` on the line number displayed in the error message to jump right to the failed expectation.
|
||||
|
||||
**Tip 2:** If your mock objects are never deleted, the final verification won't happen. Therefore it's a good idea to use a heap leak checker in your tests when you allocate mocks on the heap.
|
||||
|
||||
**Important note:** Google Mock requires expectations to be set **before** the mock functions are called, otherwise the behavior is **undefined**. In particular, you mustn't interleave `EXPECT_CALL()`s and calls to the mock functions.
|
||||
|
||||
This means `EXPECT_CALL()` should be read as expecting that a call will occur _in the future_, not that a call has occurred. Why does Google Mock work like that? Well, specifying the expectation beforehand allows Google Mock to report a violation as soon as it arises, when the context (stack trace, etc) is still available. This makes debugging much easier.
|
||||
|
||||
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
|
||||
[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) {
|
||||
// The following line causes Google Mock to throw an exception on failure,
|
||||
// which will be interpreted by your testing framework as a test failure.
|
||||
::testing::GTEST_FLAG(throw_on_failure) = true;
|
||||
::testing::InitGoogleMock(&argc, argv);
|
||||
... whatever your testing framework requires ...
|
||||
}
|
||||
```
|
||||
|
||||
This approach has a catch: it makes Google Mock throw an exception
|
||||
from a mock object's destructor sometimes. With some compilers, this
|
||||
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/V1_6_AdvancedGuide#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.
|
||||
|
||||
If this turns out to be too much work, we suggest that you stick with
|
||||
Google Test, which works with Google Mock seamlessly (in fact, it is
|
||||
technically part of Google Mock.). If there is a reason that you
|
||||
cannot use Google Test, please let us know.
|
||||
|
||||
# Setting Expectations #
|
||||
The key to using a mock object successfully is to set the _right expectations_ on it. If you set the expectations too strict, your test will fail as the result of unrelated changes. If you set them too loose, bugs can slip through. You want to do it just right such that your test can catch exactly the kind of bugs you intend it to catch. Google Mock provides the necessary means for you to do it "just right."
|
||||
|
||||
## General Syntax ##
|
||||
In Google Mock we use the `EXPECT_CALL()` macro to set an expectation on a mock method. The general syntax is:
|
||||
|
||||
```
|
||||
EXPECT_CALL(mock_object, method(matchers))
|
||||
.Times(cardinality)
|
||||
.WillOnce(action)
|
||||
.WillRepeatedly(action);
|
||||
```
|
||||
|
||||
The macro has two arguments: first the mock object, and then the method and its arguments. Note that the two are separated by a comma (`,`), not a period (`.`). (Why using a comma? The answer is that it was necessary for technical reasons.)
|
||||
|
||||
The macro can be followed by some optional _clauses_ that provide more information about the expectation. We'll discuss how each clause works in the coming sections.
|
||||
|
||||
This syntax is designed to make an expectation read like English. For example, you can probably guess that
|
||||
|
||||
```
|
||||
using ::testing::Return;...
|
||||
EXPECT_CALL(turtle, GetX())
|
||||
.Times(5)
|
||||
.WillOnce(Return(100))
|
||||
.WillOnce(Return(150))
|
||||
.WillRepeatedly(Return(200));
|
||||
```
|
||||
|
||||
says that the `turtle` object's `GetX()` method will be called five times, it will return 100 the first time, 150 the second time, and then 200 every time. Some people like to call this style of syntax a Domain-Specific Language (DSL).
|
||||
|
||||
**Note:** Why do we use a macro to do this? It serves two purposes: first it makes expectations easily identifiable (either by `grep` or by a human reader), and second it allows Google Mock to include the source file location of a failed expectation in messages, making debugging easier.
|
||||
|
||||
## Matchers: What Arguments Do We Expect? ##
|
||||
When a mock function takes arguments, we must specify what arguments we are expecting; for example:
|
||||
|
||||
```
|
||||
// Expects the turtle to move forward by 100 units.
|
||||
EXPECT_CALL(turtle, Forward(100));
|
||||
```
|
||||
|
||||
Sometimes you may not want to be too specific (Remember that talk about tests being too rigid? Over specification leads to brittle tests and obscures the intent of tests. Therefore we encourage you to specify only what's necessary - no more, no less.). If you care to check that `Forward()` will be called but aren't interested in its actual argument, write `_` as the argument, which means "anything goes":
|
||||
|
||||
```
|
||||
using ::testing::_;
|
||||
...
|
||||
// Expects the turtle to move forward.
|
||||
EXPECT_CALL(turtle, Forward(_));
|
||||
```
|
||||
|
||||
`_` is an instance of what we call **matchers**. A matcher is like a predicate and can test whether an argument is what we'd expect. You can use a matcher inside `EXPECT_CALL()` wherever a function argument is expected.
|
||||
|
||||
A list of built-in matchers can be found in the [CheatSheet](V1_6_CheatSheet.md). For example, here's the `Ge` (greater than or equal) matcher:
|
||||
|
||||
```
|
||||
using ::testing::Ge;...
|
||||
EXPECT_CALL(turtle, Forward(Ge(100)));
|
||||
```
|
||||
|
||||
This checks that the turtle will be told to go forward by at least 100 units.
|
||||
|
||||
## Cardinalities: How Many Times Will It Be Called? ##
|
||||
The first clause we can specify following an `EXPECT_CALL()` is `Times()`. We call its argument a **cardinality** as it tells _how many times_ the call should occur. It allows us to repeat an expectation many times without actually writing it as many times. More importantly, a cardinality can be "fuzzy", just like a matcher can be. This allows a user to express the intent of a test exactly.
|
||||
|
||||
An interesting special case is when we say `Times(0)`. You may have guessed - it means that the function shouldn't be called with the given arguments at all, and Google Mock will report a Google Test failure whenever the function is (wrongfully) called.
|
||||
|
||||
We've seen `AtLeast(n)` as an example of fuzzy cardinalities earlier. For the list of built-in cardinalities you can use, see the [CheatSheet](V1_6_CheatSheet.md).
|
||||
|
||||
The `Times()` clause can be omitted. **If you omit `Times()`, Google Mock will infer the cardinality for you.** The rules are easy to remember:
|
||||
|
||||
* If **neither** `WillOnce()` **nor** `WillRepeatedly()` is in the `EXPECT_CALL()`, the inferred cardinality is `Times(1)`.
|
||||
* If there are `n WillOnce()`'s but **no** `WillRepeatedly()`, where `n` >= 1, the cardinality is `Times(n)`.
|
||||
* If there are `n WillOnce()`'s and **one** `WillRepeatedly()`, where `n` >= 0, the cardinality is `Times(AtLeast(n))`.
|
||||
|
||||
**Quick quiz:** what do you think will happen if a function is expected to be called twice but actually called four times?
|
||||
|
||||
## Actions: What Should It Do? ##
|
||||
Remember that a mock object doesn't really have a working implementation? We as users have to tell it what to do when a method is invoked. This is easy in Google Mock.
|
||||
|
||||
First, if the return type of a mock function is a built-in type or a pointer, the function has a **default action** (a `void` function will just return, a `bool` function will return `false`, and other functions will return 0). If you don't say anything, this behavior will be used.
|
||||
|
||||
Second, if a mock function doesn't have a default action, or the default action doesn't suit you, you can specify the action to be taken each time the expectation matches using a series of `WillOnce()` clauses followed by an optional `WillRepeatedly()`. For example,
|
||||
|
||||
```
|
||||
using ::testing::Return;...
|
||||
EXPECT_CALL(turtle, GetX())
|
||||
.WillOnce(Return(100))
|
||||
.WillOnce(Return(200))
|
||||
.WillOnce(Return(300));
|
||||
```
|
||||
|
||||
This says that `turtle.GetX()` will be called _exactly three times_ (Google Mock inferred this from how many `WillOnce()` clauses we've written, since we didn't explicitly write `Times()`), and will return 100, 200, and 300 respectively.
|
||||
|
||||
```
|
||||
using ::testing::Return;...
|
||||
EXPECT_CALL(turtle, GetY())
|
||||
.WillOnce(Return(100))
|
||||
.WillOnce(Return(200))
|
||||
.WillRepeatedly(Return(300));
|
||||
```
|
||||
|
||||
says that `turtle.GetY()` will be called _at least twice_ (Google Mock knows this as we've written two `WillOnce()` clauses and a `WillRepeatedly()` while having no explicit `Times()`), will return 100 the first time, 200 the second time, and 300 from the third time on.
|
||||
|
||||
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/V1_6_CheatSheet#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:
|
||||
|
||||
```
|
||||
int n = 100;
|
||||
EXPECT_CALL(turtle, GetX())
|
||||
.Times(4)
|
||||
.WillRepeatedly(Return(n++));
|
||||
```
|
||||
|
||||
Instead of returning 100, 101, 102, ..., consecutively, this mock function will always return 100 as `n++` is only evaluated once. Similarly, `Return(new Foo)` will create a new `Foo` object when the `EXPECT_CALL()` is executed, and will return the same pointer every time. If you want the side effect to happen every time, you need to define a custom action, which we'll teach in the [CookBook](V1_6_CookBook.md).
|
||||
|
||||
Time for another quiz! What do you think the following means?
|
||||
|
||||
```
|
||||
using ::testing::Return;...
|
||||
EXPECT_CALL(turtle, GetY())
|
||||
.Times(4)
|
||||
.WillOnce(Return(100));
|
||||
```
|
||||
|
||||
Obviously `turtle.GetY()` is expected to be called four times. But if you think it will return 100 every time, think twice! Remember that one `WillOnce()` clause will be consumed each time the function is invoked and the default action will be taken afterwards. So the right answer is that `turtle.GetY()` will return 100 the first time, but **return 0 from the second time on**, as returning 0 is the default action for `int` functions.
|
||||
|
||||
## Using Multiple Expectations ##
|
||||
So far we've only shown examples where you have a single expectation. More realistically, you're going to specify expectations on multiple mock methods, which may be from multiple mock objects.
|
||||
|
||||
By default, when a mock method is invoked, Google Mock will search the expectations in the **reverse order** they are defined, and stop when an active expectation that matches the arguments is found (you can think of it as "newer rules override older ones."). If the matching expectation cannot take any more calls, you will get an upper-bound-violated failure. Here's an example:
|
||||
|
||||
```
|
||||
using ::testing::_;...
|
||||
EXPECT_CALL(turtle, Forward(_)); // #1
|
||||
EXPECT_CALL(turtle, Forward(10)) // #2
|
||||
.Times(2);
|
||||
```
|
||||
|
||||
If `Forward(10)` is called three times in a row, the third time it will be an error, as the last matching expectation (#2) has been saturated. If, however, the third `Forward(10)` call is replaced by `Forward(20)`, then it would be OK, as now #1 will be the matching expectation.
|
||||
|
||||
**Side note:** Why does Google Mock search for a match in the _reverse_ order of the expectations? The reason is that this allows a user to set up the default expectations in a mock object's constructor or the test fixture's set-up phase and then customize the mock by writing more specific expectations in the test body. So, if you have two expectations on the same method, you want to put the one with more specific matchers **after** the other, or the more specific rule would be shadowed by the more general one that comes after it.
|
||||
|
||||
## Ordered vs Unordered Calls ##
|
||||
By default, an expectation can match a call even though an earlier expectation hasn't been satisfied. In other words, the calls don't have to occur in the order the expectations are specified.
|
||||
|
||||
Sometimes, you may want all the expected calls to occur in a strict order. To say this in Google Mock is easy:
|
||||
|
||||
```
|
||||
using ::testing::InSequence;...
|
||||
TEST(FooTest, DrawsLineSegment) {
|
||||
...
|
||||
{
|
||||
InSequence dummy;
|
||||
|
||||
EXPECT_CALL(turtle, PenDown());
|
||||
EXPECT_CALL(turtle, Forward(100));
|
||||
EXPECT_CALL(turtle, PenUp());
|
||||
}
|
||||
Foo();
|
||||
}
|
||||
```
|
||||
|
||||
By creating an object of type `InSequence`, all expectations in its scope are put into a _sequence_ and have to occur _sequentially_. Since we are just relying on the constructor and destructor of this object to do the actual work, its name is really irrelevant.
|
||||
|
||||
In this example, we test that `Foo()` calls the three expected functions in the order as written. If a call is made out-of-order, it will be an error.
|
||||
|
||||
(What if you care about the relative order of some of the calls, but not all of them? Can you specify an arbitrary partial order? The answer is ... yes! If you are impatient, the details can be found in the [CookBook](V1_6_CookBook.md).)
|
||||
|
||||
## All Expectations Are Sticky (Unless Said Otherwise) ##
|
||||
Now let's do a quick quiz to see how well you can use this mock stuff already. How would you test that the turtle is asked to go to the origin _exactly twice_ (you want to ignore any other instructions it receives)?
|
||||
|
||||
After you've come up with your answer, take a look at ours and compare notes (solve it yourself first - don't cheat!):
|
||||
|
||||
```
|
||||
using ::testing::_;...
|
||||
EXPECT_CALL(turtle, GoTo(_, _)) // #1
|
||||
.Times(AnyNumber());
|
||||
EXPECT_CALL(turtle, GoTo(0, 0)) // #2
|
||||
.Times(2);
|
||||
```
|
||||
|
||||
Suppose `turtle.GoTo(0, 0)` is called three times. In the third time, Google Mock will see that the arguments match expectation #2 (remember that we always pick the last matching expectation). Now, since we said that there should be only two such calls, Google Mock will report an error immediately. This is basically what we've told you in the "Using Multiple Expectations" section above.
|
||||
|
||||
This example shows that **expectations in Google Mock are "sticky" by default**, in the sense that they remain active even after we have reached their invocation upper bounds. This is an important rule to remember, as it affects the meaning of the spec, and is **different** to how it's done in many other mocking frameworks (Why'd we do that? Because we think our rule makes the common cases easier to express and understand.).
|
||||
|
||||
Simple? Let's see if you've really understood it: what does the following code say?
|
||||
|
||||
```
|
||||
using ::testing::Return;
|
||||
...
|
||||
for (int i = n; i > 0; i--) {
|
||||
EXPECT_CALL(turtle, GetX())
|
||||
.WillOnce(Return(10*i));
|
||||
}
|
||||
```
|
||||
|
||||
If you think it says that `turtle.GetX()` will be called `n` times and will return 10, 20, 30, ..., consecutively, think twice! The problem is that, as we said, expectations are sticky. So, the second time `turtle.GetX()` is called, the last (latest) `EXPECT_CALL()` statement will match, and will immediately lead to an "upper bound exceeded" error - this piece of code is not very useful!
|
||||
|
||||
One correct way of saying that `turtle.GetX()` will return 10, 20, 30, ..., is to explicitly say that the expectations are _not_ sticky. In other words, they should _retire_ as soon as they are saturated:
|
||||
|
||||
```
|
||||
using ::testing::Return;
|
||||
...
|
||||
for (int i = n; i > 0; i--) {
|
||||
EXPECT_CALL(turtle, GetX())
|
||||
.WillOnce(Return(10*i))
|
||||
.RetiresOnSaturation();
|
||||
}
|
||||
```
|
||||
|
||||
And, there's a better way to do it: in this case, we expect the calls to occur in a specific order, and we line up the actions to match the order. Since the order is important here, we should make it explicit using a sequence:
|
||||
|
||||
```
|
||||
using ::testing::InSequence;
|
||||
using ::testing::Return;
|
||||
...
|
||||
{
|
||||
InSequence s;
|
||||
|
||||
for (int i = 1; i <= n; i++) {
|
||||
EXPECT_CALL(turtle, GetX())
|
||||
.WillOnce(Return(10*i))
|
||||
.RetiresOnSaturation();
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
By the way, the other situation where an expectation may _not_ be sticky is when it's in a sequence - as soon as another expectation that comes after it in the sequence has been used, it automatically retires (and will never be used to match any call).
|
||||
|
||||
## Uninteresting Calls ##
|
||||
A mock object may have many methods, and not all of them are that interesting. For example, in some tests we may not care about how many times `GetX()` and `GetY()` get called.
|
||||
|
||||
In Google Mock, if you are not interested in a method, just don't say anything about it. If a call to this method occurs, you'll see a warning in the test output, but it won't be a failure.
|
||||
|
||||
# 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](V1_6_CookBook.md). You can learn many advanced features of Google Mock there -- and advance your level of enjoyment and testing bliss.
|
||||
@@ -0,0 +1,628 @@
|
||||
|
||||
|
||||
Please send your questions to the
|
||||
[googlemock](http://groups.google.com/group/googlemock) discussion
|
||||
group. If you need help with compiler errors, make sure you have
|
||||
tried [Google Mock Doctor](#How_am_I_supposed_to_make_sense_of_these_horrible_template_error.md) first.
|
||||
|
||||
## 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/V1_6_CookBook#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? ##
|
||||
|
||||
After version 1.4.0 of Google Mock was released, we had an idea on how
|
||||
to make it easier to write matchers that can generate informative
|
||||
messages efficiently. We experimented with this idea and liked what
|
||||
we saw. Therefore we decided to implement it.
|
||||
|
||||
Unfortunately, this means that if you have defined your own matchers
|
||||
by implementing `MatcherInterface` or using `MakePolymorphicMatcher()`,
|
||||
your definitions will no longer compile. Matchers defined using the
|
||||
`MATCHER*` family of macros are not affected.
|
||||
|
||||
Sorry for the hassle if your matchers are affected. We believe it's
|
||||
in everyone's long-term interest to make this change sooner than
|
||||
later. Fortunately, it's usually not hard to migrate an existing
|
||||
matcher to the new API. Here's what you need to do:
|
||||
|
||||
If you wrote your matcher like this:
|
||||
```
|
||||
// Old matcher definition that doesn't work with the latest
|
||||
// Google Mock.
|
||||
using ::testing::MatcherInterface;
|
||||
...
|
||||
class MyWonderfulMatcher : public MatcherInterface<MyType> {
|
||||
public:
|
||||
...
|
||||
virtual bool Matches(MyType value) const {
|
||||
// Returns true if value matches.
|
||||
return value.GetFoo() > 5;
|
||||
}
|
||||
...
|
||||
};
|
||||
```
|
||||
|
||||
you'll need to change it to:
|
||||
```
|
||||
// New matcher definition that works with the latest Google Mock.
|
||||
using ::testing::MatcherInterface;
|
||||
using ::testing::MatchResultListener;
|
||||
...
|
||||
class MyWonderfulMatcher : public MatcherInterface<MyType> {
|
||||
public:
|
||||
...
|
||||
virtual bool MatchAndExplain(MyType value,
|
||||
MatchResultListener* listener) const {
|
||||
// Returns true if value matches.
|
||||
return value.GetFoo() > 5;
|
||||
}
|
||||
...
|
||||
};
|
||||
```
|
||||
(i.e. rename `Matches()` to `MatchAndExplain()` and give it a second
|
||||
argument of type `MatchResultListener*`.)
|
||||
|
||||
If you were also using `ExplainMatchResultTo()` to improve the matcher
|
||||
message:
|
||||
```
|
||||
// Old matcher definition that doesn't work with the lastest
|
||||
// Google Mock.
|
||||
using ::testing::MatcherInterface;
|
||||
...
|
||||
class MyWonderfulMatcher : public MatcherInterface<MyType> {
|
||||
public:
|
||||
...
|
||||
virtual bool Matches(MyType value) const {
|
||||
// Returns true if value matches.
|
||||
return value.GetFoo() > 5;
|
||||
}
|
||||
|
||||
virtual void ExplainMatchResultTo(MyType value,
|
||||
::std::ostream* os) const {
|
||||
// Prints some helpful information to os to help
|
||||
// a user understand why value matches (or doesn't match).
|
||||
*os << "the Foo property is " << value.GetFoo();
|
||||
}
|
||||
...
|
||||
};
|
||||
```
|
||||
|
||||
you should move the logic of `ExplainMatchResultTo()` into
|
||||
`MatchAndExplain()`, using the `MatchResultListener` argument where
|
||||
the `::std::ostream` was used:
|
||||
```
|
||||
// New matcher definition that works with the latest Google Mock.
|
||||
using ::testing::MatcherInterface;
|
||||
using ::testing::MatchResultListener;
|
||||
...
|
||||
class MyWonderfulMatcher : public MatcherInterface<MyType> {
|
||||
public:
|
||||
...
|
||||
virtual bool MatchAndExplain(MyType value,
|
||||
MatchResultListener* listener) const {
|
||||
// Returns true if value matches.
|
||||
*listener << "the Foo property is " << value.GetFoo();
|
||||
return value.GetFoo() > 5;
|
||||
}
|
||||
...
|
||||
};
|
||||
```
|
||||
|
||||
If your matcher is defined using `MakePolymorphicMatcher()`:
|
||||
```
|
||||
// Old matcher definition that doesn't work with the latest
|
||||
// Google Mock.
|
||||
using ::testing::MakePolymorphicMatcher;
|
||||
...
|
||||
class MyGreatMatcher {
|
||||
public:
|
||||
...
|
||||
bool Matches(MyType value) const {
|
||||
// Returns true if value matches.
|
||||
return value.GetBar() < 42;
|
||||
}
|
||||
...
|
||||
};
|
||||
... MakePolymorphicMatcher(MyGreatMatcher()) ...
|
||||
```
|
||||
|
||||
you should rename the `Matches()` method to `MatchAndExplain()` and
|
||||
add a `MatchResultListener*` argument (the same as what you need to do
|
||||
for matchers defined by implementing `MatcherInterface`):
|
||||
```
|
||||
// New matcher definition that works with the latest Google Mock.
|
||||
using ::testing::MakePolymorphicMatcher;
|
||||
using ::testing::MatchResultListener;
|
||||
...
|
||||
class MyGreatMatcher {
|
||||
public:
|
||||
...
|
||||
bool MatchAndExplain(MyType value,
|
||||
MatchResultListener* listener) const {
|
||||
// Returns true if value matches.
|
||||
return value.GetBar() < 42;
|
||||
}
|
||||
...
|
||||
};
|
||||
... MakePolymorphicMatcher(MyGreatMatcher()) ...
|
||||
```
|
||||
|
||||
If your polymorphic matcher uses `ExplainMatchResultTo()` for better
|
||||
failure messages:
|
||||
```
|
||||
// Old matcher definition that doesn't work with the latest
|
||||
// Google Mock.
|
||||
using ::testing::MakePolymorphicMatcher;
|
||||
...
|
||||
class MyGreatMatcher {
|
||||
public:
|
||||
...
|
||||
bool Matches(MyType value) const {
|
||||
// Returns true if value matches.
|
||||
return value.GetBar() < 42;
|
||||
}
|
||||
...
|
||||
};
|
||||
void ExplainMatchResultTo(const MyGreatMatcher& matcher,
|
||||
MyType value,
|
||||
::std::ostream* os) {
|
||||
// Prints some helpful information to os to help
|
||||
// a user understand why value matches (or doesn't match).
|
||||
*os << "the Bar property is " << value.GetBar();
|
||||
}
|
||||
... MakePolymorphicMatcher(MyGreatMatcher()) ...
|
||||
```
|
||||
|
||||
you'll need to move the logic inside `ExplainMatchResultTo()` to
|
||||
`MatchAndExplain()`:
|
||||
```
|
||||
// New matcher definition that works with the latest Google Mock.
|
||||
using ::testing::MakePolymorphicMatcher;
|
||||
using ::testing::MatchResultListener;
|
||||
...
|
||||
class MyGreatMatcher {
|
||||
public:
|
||||
...
|
||||
bool MatchAndExplain(MyType value,
|
||||
MatchResultListener* listener) const {
|
||||
// Returns true if value matches.
|
||||
*listener << "the Bar property is " << value.GetBar();
|
||||
return value.GetBar() < 42;
|
||||
}
|
||||
...
|
||||
};
|
||||
... MakePolymorphicMatcher(MyGreatMatcher()) ...
|
||||
```
|
||||
|
||||
For more information, you can read these
|
||||
[two](http://code.google.com/p/googlemock/wiki/V1_6_CookBook#Writing_New_Monomorphic_Matchers)
|
||||
[recipes](http://code.google.com/p/googlemock/wiki/V1_6_CookBook#Writing_New_Polymorphic_Matchers)
|
||||
from the cookbook. As always, you
|
||||
are welcome to post questions on `googlemock@googlegroups.com` if you
|
||||
need any help.
|
||||
|
||||
## When using Google Mock, do I have to use Google Test as the testing framework? I have my favorite testing framework and don't want to switch. ##
|
||||
|
||||
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/V1_6_ForDummies#Using_Google_Mock_with_Any_Testing_Framework) is how.
|
||||
|
||||
## How am I supposed to make sense of these horrible template errors? ##
|
||||
|
||||
If you are confused by the compiler errors gcc threw at you,
|
||||
try consulting the _Google Mock Doctor_ tool first. What it does is to
|
||||
scan stdin for gcc error messages, and spit out diagnoses on the
|
||||
problems (we call them diseases) your code has.
|
||||
|
||||
To "install", run command:
|
||||
```
|
||||
alias gmd='<path to googlemock>/scripts/gmock_doctor.py'
|
||||
```
|
||||
|
||||
To use it, do:
|
||||
```
|
||||
<your-favorite-build-command> <your-test> 2>&1 | gmd
|
||||
```
|
||||
|
||||
For example:
|
||||
```
|
||||
make my_test 2>&1 | gmd
|
||||
```
|
||||
|
||||
Or you can run `gmd` and copy-n-paste gcc's error messages to it.
|
||||
|
||||
## Can I mock a variadic function? ##
|
||||
|
||||
You cannot mock a variadic function (i.e. a function taking ellipsis
|
||||
(`...`) arguments) directly in Google Mock.
|
||||
|
||||
The problem is that in general, there is _no way_ for a mock object to
|
||||
know how many arguments are passed to the variadic method, and what
|
||||
the arguments' types are. Only the _author of the base class_ knows
|
||||
the protocol, and we cannot look into his head.
|
||||
|
||||
Therefore, to mock such a function, the _user_ must teach the mock
|
||||
object how to figure out the number of arguments and their types. One
|
||||
way to do it is to provide overloaded versions of the function.
|
||||
|
||||
Ellipsis arguments are inherited from C and not really a C++ feature.
|
||||
They are unsafe to use and don't work with arguments that have
|
||||
constructors or destructors. Therefore we recommend to avoid them in
|
||||
C++ as much as possible.
|
||||
|
||||
## MSVC gives me warning C4301 or C4373 when I define a mock method with a const parameter. Why? ##
|
||||
|
||||
If you compile this using Microsoft Visual C++ 2005 SP1:
|
||||
```
|
||||
class Foo {
|
||||
...
|
||||
virtual void Bar(const int i) = 0;
|
||||
};
|
||||
|
||||
class MockFoo : public Foo {
|
||||
...
|
||||
MOCK_METHOD1(Bar, void(const int i));
|
||||
};
|
||||
```
|
||||
You may get the following warning:
|
||||
```
|
||||
warning C4301: 'MockFoo::Bar': overriding virtual function only differs from 'Foo::Bar' by const/volatile qualifier
|
||||
```
|
||||
|
||||
This is a MSVC bug. The same code compiles fine with gcc ,for
|
||||
example. If you use Visual C++ 2008 SP1, you would get the warning:
|
||||
```
|
||||
warning C4373: 'MockFoo::Bar': virtual function overrides 'Foo::Bar', previous versions of the compiler did not override when parameters only differed by const/volatile qualifiers
|
||||
```
|
||||
|
||||
In C++, if you _declare_ a function with a `const` parameter, the
|
||||
`const` modifier is _ignored_. Therefore, the `Foo` base class above
|
||||
is equivalent to:
|
||||
```
|
||||
class Foo {
|
||||
...
|
||||
virtual void Bar(int i) = 0; // int or const int? Makes no difference.
|
||||
};
|
||||
```
|
||||
|
||||
In fact, you can _declare_ Bar() with an `int` parameter, and _define_
|
||||
it with a `const int` parameter. The compiler will still match them
|
||||
up.
|
||||
|
||||
Since making a parameter `const` is meaningless in the method
|
||||
_declaration_, we recommend to remove it in both `Foo` and `MockFoo`.
|
||||
That should workaround the VC bug.
|
||||
|
||||
Note that we are talking about the _top-level_ `const` modifier here.
|
||||
If the function parameter is passed by pointer or reference, declaring
|
||||
the _pointee_ or _referee_ as `const` is still meaningful. For
|
||||
example, the following two declarations are _not_ equivalent:
|
||||
```
|
||||
void Bar(int* p); // Neither p nor *p is const.
|
||||
void Bar(const int* p); // p is not const, but *p is.
|
||||
```
|
||||
|
||||
## I have a huge mock class, and Microsoft Visual C++ runs out of memory when compiling it. What can I do? ##
|
||||
|
||||
We've noticed that when the `/clr` compiler flag is used, Visual C++
|
||||
uses 5~6 times as much memory when compiling a mock class. We suggest
|
||||
to avoid `/clr` when compiling native C++ mocks.
|
||||
|
||||
## I can't figure out why Google Mock thinks my expectations are not satisfied. What should I do? ##
|
||||
|
||||
You might want to run your test with
|
||||
`--gmock_verbose=info`. This flag lets Google Mock print a trace
|
||||
of every mock function call it receives. By studying the trace,
|
||||
you'll gain insights on why the expectations you set are not met.
|
||||
|
||||
## How can I assert that a function is NEVER called? ##
|
||||
|
||||
```
|
||||
EXPECT_CALL(foo, Bar(_))
|
||||
.Times(0);
|
||||
```
|
||||
|
||||
## I have a failed test where Google Mock tells me TWICE that a particular expectation is not satisfied. Isn't this redundant? ##
|
||||
|
||||
When Google Mock detects a failure, it prints relevant information
|
||||
(the mock function arguments, the state of relevant expectations, and
|
||||
etc) to help the user debug. If another failure is detected, Google
|
||||
Mock will do the same, including printing the state of relevant
|
||||
expectations.
|
||||
|
||||
Sometimes an expectation's state didn't change between two failures,
|
||||
and you'll see the same description of the state twice. They are
|
||||
however _not_ redundant, as they refer to _different points in time_.
|
||||
The fact they are the same _is_ interesting information.
|
||||
|
||||
## I get a heap check failure when using a mock object, but using a real object is fine. What can be wrong? ##
|
||||
|
||||
Does the class (hopefully a pure interface) you are mocking have a
|
||||
virtual destructor?
|
||||
|
||||
Whenever you derive from a base class, make sure its destructor is
|
||||
virtual. Otherwise Bad Things will happen. Consider the following
|
||||
code:
|
||||
|
||||
```
|
||||
class Base {
|
||||
public:
|
||||
// Not virtual, but should be.
|
||||
~Base() { ... }
|
||||
...
|
||||
};
|
||||
|
||||
class Derived : public Base {
|
||||
public:
|
||||
...
|
||||
private:
|
||||
std::string value_;
|
||||
};
|
||||
|
||||
...
|
||||
Base* p = new Derived;
|
||||
...
|
||||
delete p; // Surprise! ~Base() will be called, but ~Derived() will not
|
||||
// - value_ is leaked.
|
||||
```
|
||||
|
||||
By changing `~Base()` to virtual, `~Derived()` will be correctly
|
||||
called when `delete p` is executed, and the heap checker
|
||||
will be happy.
|
||||
|
||||
## The "newer expectations override older ones" rule makes writing expectations awkward. Why does Google Mock do that? ##
|
||||
|
||||
When people complain about this, often they are referring to code like:
|
||||
|
||||
```
|
||||
// foo.Bar() should be called twice, return 1 the first time, and return
|
||||
// 2 the second time. However, I have to write the expectations in the
|
||||
// reverse order. This sucks big time!!!
|
||||
EXPECT_CALL(foo, Bar())
|
||||
.WillOnce(Return(2))
|
||||
.RetiresOnSaturation();
|
||||
EXPECT_CALL(foo, Bar())
|
||||
.WillOnce(Return(1))
|
||||
.RetiresOnSaturation();
|
||||
```
|
||||
|
||||
The problem is that they didn't pick the **best** way to express the test's
|
||||
intent.
|
||||
|
||||
By default, expectations don't have to be matched in _any_ particular
|
||||
order. If you want them to match in a certain order, you need to be
|
||||
explicit. This is Google Mock's (and jMock's) fundamental philosophy: it's
|
||||
easy to accidentally over-specify your tests, and we want to make it
|
||||
harder to do so.
|
||||
|
||||
There are two better ways to write the test spec. You could either
|
||||
put the expectations in sequence:
|
||||
|
||||
```
|
||||
// foo.Bar() should be called twice, return 1 the first time, and return
|
||||
// 2 the second time. Using a sequence, we can write the expectations
|
||||
// in their natural order.
|
||||
{
|
||||
InSequence s;
|
||||
EXPECT_CALL(foo, Bar())
|
||||
.WillOnce(Return(1))
|
||||
.RetiresOnSaturation();
|
||||
EXPECT_CALL(foo, Bar())
|
||||
.WillOnce(Return(2))
|
||||
.RetiresOnSaturation();
|
||||
}
|
||||
```
|
||||
|
||||
or you can put the sequence of actions in the same expectation:
|
||||
|
||||
```
|
||||
// foo.Bar() should be called twice, return 1 the first time, and return
|
||||
// 2 the second time.
|
||||
EXPECT_CALL(foo, Bar())
|
||||
.WillOnce(Return(1))
|
||||
.WillOnce(Return(2))
|
||||
.RetiresOnSaturation();
|
||||
```
|
||||
|
||||
Back to the original questions: why does Google Mock search the
|
||||
expectations (and `ON_CALL`s) from back to front? Because this
|
||||
allows a user to set up a mock's behavior for the common case early
|
||||
(e.g. in the mock's constructor or the test fixture's set-up phase)
|
||||
and customize it with more specific rules later. If Google Mock
|
||||
searches from front to back, this very useful pattern won't be
|
||||
possible.
|
||||
|
||||
## Google Mock prints a warning when a function without EXPECT\_CALL is called, even if I have set its behavior using ON\_CALL. Would it be reasonable not to show the warning in this case? ##
|
||||
|
||||
When choosing between being neat and being safe, we lean toward the
|
||||
latter. So the answer is that we think it's better to show the
|
||||
warning.
|
||||
|
||||
Often people write `ON_CALL`s in the mock object's
|
||||
constructor or `SetUp()`, as the default behavior rarely changes from
|
||||
test to test. Then in the test body they set the expectations, which
|
||||
are often different for each test. Having an `ON_CALL` in the set-up
|
||||
part of a test doesn't mean that the calls are expected. If there's
|
||||
no `EXPECT_CALL` and the method is called, it's possibly an error. If
|
||||
we quietly let the call go through without notifying the user, bugs
|
||||
may creep in unnoticed.
|
||||
|
||||
If, however, you are sure that the calls are OK, you can write
|
||||
|
||||
```
|
||||
EXPECT_CALL(foo, Bar(_))
|
||||
.WillRepeatedly(...);
|
||||
```
|
||||
|
||||
instead of
|
||||
|
||||
```
|
||||
ON_CALL(foo, Bar(_))
|
||||
.WillByDefault(...);
|
||||
```
|
||||
|
||||
This tells Google Mock that you do expect the calls and no warning should be
|
||||
printed.
|
||||
|
||||
Also, you can control the verbosity using the `--gmock_verbose` flag.
|
||||
If you find the output too noisy when debugging, just choose a less
|
||||
verbose level.
|
||||
|
||||
## How can I delete the mock function's argument in an action? ##
|
||||
|
||||
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/V1_6_CookBook#Writing_New_Actions) or
|
||||
[MakePolymorphicAction()](http://code.google.com/p/googlemock/wiki/V1_6_CookBook#Writing_New_Polymorphic_Actions),
|
||||
or you can write a stub function and invoke it using
|
||||
[Invoke()](http://code.google.com/p/googlemock/wiki/V1_6_CookBook#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? ##
|
||||
|
||||
What?! I think it's beautiful. :-)
|
||||
|
||||
While which syntax looks more natural is a subjective matter to some
|
||||
extent, Google Mock's syntax was chosen for several practical advantages it
|
||||
has.
|
||||
|
||||
Try to mock a function that takes a map as an argument:
|
||||
```
|
||||
virtual int GetSize(const map<int, std::string>& m);
|
||||
```
|
||||
|
||||
Using the proposed syntax, it would be:
|
||||
```
|
||||
MOCK_METHOD1(GetSize, int, const map<int, std::string>& m);
|
||||
```
|
||||
|
||||
Guess what? You'll get a compiler error as the compiler thinks that
|
||||
`const map<int, std::string>& m` are **two**, not one, arguments. To work
|
||||
around this you can use `typedef` to give the map type a name, but
|
||||
that gets in the way of your work. Google Mock's syntax avoids this
|
||||
problem as the function's argument types are protected inside a pair
|
||||
of parentheses:
|
||||
```
|
||||
// This compiles fine.
|
||||
MOCK_METHOD1(GetSize, int(const map<int, std::string>& m));
|
||||
```
|
||||
|
||||
You still need a `typedef` if the return type contains an unprotected
|
||||
comma, but that's much rarer.
|
||||
|
||||
Other advantages include:
|
||||
1. `MOCK_METHOD1(Foo, int, bool)` can leave a reader wonder whether the method returns `int` or `bool`, while there won't be such confusion using Google Mock's syntax.
|
||||
1. The way Google Mock describes a function type is nothing new, although many people may not be familiar with it. The same syntax was used in C, and the `function` library in `tr1` uses this syntax extensively. Since `tr1` will become a part of the new version of STL, we feel very comfortable to be consistent with it.
|
||||
1. The function type syntax is also used in other parts of Google Mock's API (e.g. the action interface) in order to make the implementation tractable. A user needs to learn it anyway in order to utilize Google Mock's more advanced features. We'd as well stick to the same syntax in `MOCK_METHOD*`!
|
||||
|
||||
## My code calls a static/global function. Can I mock it? ##
|
||||
|
||||
You can, but you need to make some changes.
|
||||
|
||||
In general, if you find yourself needing to mock a static function,
|
||||
it's a sign that your modules are too tightly coupled (and less
|
||||
flexible, less reusable, less testable, etc). You are probably better
|
||||
off defining a small interface and call the function through that
|
||||
interface, which then can be easily mocked. It's a bit of work
|
||||
initially, but usually pays for itself quickly.
|
||||
|
||||
This Google Testing Blog
|
||||
[post](http://googletesting.blogspot.com/2008/06/defeat-static-cling.html)
|
||||
says it excellently. Check it out.
|
||||
|
||||
## My mock object needs to do complex stuff. It's a lot of pain to specify the actions. Google Mock sucks! ##
|
||||
|
||||
I know it's not a question, but you get an answer for free any way. :-)
|
||||
|
||||
With Google Mock, you can create mocks in C++ easily. And people might be
|
||||
tempted to use them everywhere. Sometimes they work great, and
|
||||
sometimes you may find them, well, a pain to use. So, what's wrong in
|
||||
the latter case?
|
||||
|
||||
When you write a test without using mocks, you exercise the code and
|
||||
assert that it returns the correct value or that the system is in an
|
||||
expected state. This is sometimes called "state-based testing".
|
||||
|
||||
Mocks are great for what some call "interaction-based" testing:
|
||||
instead of checking the system state at the very end, mock objects
|
||||
verify that they are invoked the right way and report an error as soon
|
||||
as it arises, giving you a handle on the precise context in which the
|
||||
error was triggered. This is often more effective and economical to
|
||||
do than state-based testing.
|
||||
|
||||
If you are doing state-based testing and using a test double just to
|
||||
simulate the real object, you are probably better off using a fake.
|
||||
Using a mock in this case causes pain, as it's not a strong point for
|
||||
mocks to perform complex actions. If you experience this and think
|
||||
that mocks suck, you are just not using the right tool for your
|
||||
problem. Or, you might be trying to solve the wrong problem. :-)
|
||||
|
||||
## I got a warning "Uninteresting function call encountered - default action taken.." Should I panic? ##
|
||||
|
||||
By all means, NO! It's just an FYI.
|
||||
|
||||
What it means is that you have a mock function, you haven't set any
|
||||
expectations on it (by Google Mock's rule this means that you are not
|
||||
interested in calls to this function and therefore it can be called
|
||||
any number of times), and it is called. That's OK - you didn't say
|
||||
it's not OK to call the function!
|
||||
|
||||
What if you actually meant to disallow this function to be called, but
|
||||
forgot to write `EXPECT_CALL(foo, Bar()).Times(0)`? While
|
||||
one can argue that it's the user's fault, Google Mock tries to be nice and
|
||||
prints you a note.
|
||||
|
||||
So, when you see the message and believe that there shouldn't be any
|
||||
uninteresting calls, you should investigate what's going on. To make
|
||||
your life easier, Google Mock prints the function name and arguments
|
||||
when an uninteresting call is encountered.
|
||||
|
||||
## I want to define a custom action. Should I use Invoke() or implement the action interface? ##
|
||||
|
||||
Either way is fine - you want to choose the one that's more convenient
|
||||
for your circumstance.
|
||||
|
||||
Usually, if your action is for a particular function type, defining it
|
||||
using `Invoke()` should be easier; if your action can be used in
|
||||
functions of different types (e.g. if you are defining
|
||||
`Return(value)`), `MakePolymorphicAction()` is
|
||||
easiest. Sometimes you want precise control on what types of
|
||||
functions the action can be used in, and implementing
|
||||
`ActionInterface` is the way to go here. See the implementation of
|
||||
`Return()` in `include/gmock/gmock-actions.h` for an example.
|
||||
|
||||
## I'm using the set-argument-pointee action, and the compiler complains about "conflicting return type specified". What does it mean? ##
|
||||
|
||||
You got this error as Google Mock has no idea what value it should return
|
||||
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/V1_6_CookBook#Mocking_Side_Effects) for more details and an example.
|
||||
|
||||
|
||||
## My question is not 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/googlemock/w/list),
|
||||
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_
|
||||
a good way to get your answer, as it is monitored infrequently by a
|
||||
very small number of people.
|
||||
|
||||
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 Mock you use (Google Mock 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.
|
||||
556
test/gtest-1.8.0/googlemock/docs/v1_7/CheatSheet.md
Normal file
556
test/gtest-1.8.0/googlemock/docs/v1_7/CheatSheet.md
Normal file
@@ -0,0 +1,556 @@
|
||||
|
||||
|
||||
# Defining a Mock Class #
|
||||
|
||||
## Mocking a Normal Class ##
|
||||
|
||||
Given
|
||||
```
|
||||
class Foo {
|
||||
...
|
||||
virtual ~Foo();
|
||||
virtual int GetSize() const = 0;
|
||||
virtual string Describe(const char* name) = 0;
|
||||
virtual string Describe(int type) = 0;
|
||||
virtual bool Process(Bar elem, int count) = 0;
|
||||
};
|
||||
```
|
||||
(note that `~Foo()` **must** be virtual) we can define its mock as
|
||||
```
|
||||
#include "gmock/gmock.h"
|
||||
|
||||
class MockFoo : public Foo {
|
||||
MOCK_CONST_METHOD0(GetSize, int());
|
||||
MOCK_METHOD1(Describe, string(const char* name));
|
||||
MOCK_METHOD1(Describe, string(int type));
|
||||
MOCK_METHOD2(Process, bool(Bar elem, int count));
|
||||
};
|
||||
```
|
||||
|
||||
To create a "nice" mock object which ignores all uninteresting calls,
|
||||
or a "strict" mock object, which treats them as failures:
|
||||
```
|
||||
NiceMock<MockFoo> nice_foo; // The type is a subclass of MockFoo.
|
||||
StrictMock<MockFoo> strict_foo; // The type is a subclass of MockFoo.
|
||||
```
|
||||
|
||||
## Mocking a Class Template ##
|
||||
|
||||
To mock
|
||||
```
|
||||
template <typename Elem>
|
||||
class StackInterface {
|
||||
public:
|
||||
...
|
||||
virtual ~StackInterface();
|
||||
virtual int GetSize() const = 0;
|
||||
virtual void Push(const Elem& x) = 0;
|
||||
};
|
||||
```
|
||||
(note that `~StackInterface()` **must** be virtual) just append `_T` to the `MOCK_*` macros:
|
||||
```
|
||||
template <typename Elem>
|
||||
class MockStack : public StackInterface<Elem> {
|
||||
public:
|
||||
...
|
||||
MOCK_CONST_METHOD0_T(GetSize, int());
|
||||
MOCK_METHOD1_T(Push, void(const Elem& x));
|
||||
};
|
||||
```
|
||||
|
||||
## Specifying Calling Conventions for Mock Functions ##
|
||||
|
||||
If your mock function doesn't use the default calling convention, you
|
||||
can specify it by appending `_WITH_CALLTYPE` to any of the macros
|
||||
described in the previous two sections and supplying the calling
|
||||
convention as the first argument to the macro. For example,
|
||||
```
|
||||
MOCK_METHOD_1_WITH_CALLTYPE(STDMETHODCALLTYPE, Foo, bool(int n));
|
||||
MOCK_CONST_METHOD2_WITH_CALLTYPE(STDMETHODCALLTYPE, Bar, int(double x, double y));
|
||||
```
|
||||
where `STDMETHODCALLTYPE` is defined by `<objbase.h>` on Windows.
|
||||
|
||||
# Using Mocks in Tests #
|
||||
|
||||
The typical flow is:
|
||||
1. Import the Google Mock names you need to use. All Google Mock names are in the `testing` namespace unless they are macros or otherwise noted.
|
||||
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. When a mock objects is destructed, Google Mock automatically verifies that all expectations on it have been satisfied.
|
||||
|
||||
Here is an example:
|
||||
```
|
||||
using ::testing::Return; // #1
|
||||
|
||||
TEST(BarTest, DoesThis) {
|
||||
MockFoo foo; // #2
|
||||
|
||||
ON_CALL(foo, GetSize()) // #3
|
||||
.WillByDefault(Return(1));
|
||||
// ... other default actions ...
|
||||
|
||||
EXPECT_CALL(foo, Describe(5)) // #4
|
||||
.Times(3)
|
||||
.WillRepeatedly(Return("Category 5"));
|
||||
// ... other expectations ...
|
||||
|
||||
EXPECT_EQ("good", MyProductionFunction(&foo)); // #5
|
||||
} // #6
|
||||
```
|
||||
|
||||
# Setting Default Actions #
|
||||
|
||||
Google Mock has a **built-in default action** for any function that
|
||||
returns `void`, `bool`, a numeric value, or a pointer.
|
||||
|
||||
To customize the default action for functions with return type `T` globally:
|
||||
```
|
||||
using ::testing::DefaultValue;
|
||||
|
||||
DefaultValue<T>::Set(value); // Sets the default value to be returned.
|
||||
// ... use the mocks ...
|
||||
DefaultValue<T>::Clear(); // Resets the default value.
|
||||
```
|
||||
|
||||
To customize the default action for a particular method, use `ON_CALL()`:
|
||||
```
|
||||
ON_CALL(mock_object, method(matchers))
|
||||
.With(multi_argument_matcher) ?
|
||||
.WillByDefault(action);
|
||||
```
|
||||
|
||||
# Setting Expectations #
|
||||
|
||||
`EXPECT_CALL()` sets **expectations** on a mock method (How will it be
|
||||
called? What will it do?):
|
||||
```
|
||||
EXPECT_CALL(mock_object, method(matchers))
|
||||
.With(multi_argument_matcher) ?
|
||||
.Times(cardinality) ?
|
||||
.InSequence(sequences) *
|
||||
.After(expectations) *
|
||||
.WillOnce(action) *
|
||||
.WillRepeatedly(action) ?
|
||||
.RetiresOnSaturation(); ?
|
||||
```
|
||||
|
||||
If `Times()` is omitted, the cardinality is assumed to be:
|
||||
|
||||
* `Times(1)` when there is neither `WillOnce()` nor `WillRepeatedly()`;
|
||||
* `Times(n)` when there are `n WillOnce()`s but no `WillRepeatedly()`, where `n` >= 1; or
|
||||
* `Times(AtLeast(n))` when there are `n WillOnce()`s and a `WillRepeatedly()`, where `n` >= 0.
|
||||
|
||||
A method with no `EXPECT_CALL()` is free to be invoked _any number of times_, and the default action will be taken each time.
|
||||
|
||||
# Matchers #
|
||||
|
||||
A **matcher** matches a _single_ argument. You can use it inside
|
||||
`ON_CALL()` or `EXPECT_CALL()`, or use it to validate a value
|
||||
directly:
|
||||
|
||||
| `EXPECT_THAT(value, matcher)` | Asserts that `value` matches `matcher`. |
|
||||
|:------------------------------|:----------------------------------------|
|
||||
| `ASSERT_THAT(value, matcher)` | The same as `EXPECT_THAT(value, matcher)`, except that it generates a **fatal** failure. |
|
||||
|
||||
Built-in matchers (where `argument` is the function argument) are
|
||||
divided into several categories:
|
||||
|
||||
## Wildcard ##
|
||||
|`_`|`argument` can be any value of the correct type.|
|
||||
|:--|:-----------------------------------------------|
|
||||
|`A<type>()` or `An<type>()`|`argument` can be any value of type `type`. |
|
||||
|
||||
## Generic Comparison ##
|
||||
|
||||
|`Eq(value)` or `value`|`argument == value`|
|
||||
|:---------------------|:------------------|
|
||||
|`Ge(value)` |`argument >= value`|
|
||||
|`Gt(value)` |`argument > value` |
|
||||
|`Le(value)` |`argument <= value`|
|
||||
|`Lt(value)` |`argument < value` |
|
||||
|`Ne(value)` |`argument != value`|
|
||||
|`IsNull()` |`argument` is a `NULL` pointer (raw or smart).|
|
||||
|`NotNull()` |`argument` is a non-null pointer (raw or smart).|
|
||||
|`Ref(variable)` |`argument` is a reference to `variable`.|
|
||||
|`TypedEq<type>(value)`|`argument` has type `type` and is equal to `value`. You may need to use this instead of `Eq(value)` when the mock function is overloaded.|
|
||||
|
||||
Except `Ref()`, these matchers make a _copy_ of `value` in case it's
|
||||
modified or destructed later. If the compiler complains that `value`
|
||||
doesn't have a public copy constructor, try wrap it in `ByRef()`,
|
||||
e.g. `Eq(ByRef(non_copyable_value))`. If you do that, make sure
|
||||
`non_copyable_value` is not changed afterwards, or the meaning of your
|
||||
matcher will be changed.
|
||||
|
||||
## Floating-Point Matchers ##
|
||||
|
||||
|`DoubleEq(a_double)`|`argument` is a `double` value approximately equal to `a_double`, treating two NaNs as unequal.|
|
||||
|:-------------------|:----------------------------------------------------------------------------------------------|
|
||||
|`FloatEq(a_float)` |`argument` is a `float` value approximately equal to `a_float`, treating two NaNs as unequal. |
|
||||
|`NanSensitiveDoubleEq(a_double)`|`argument` is a `double` value approximately equal to `a_double`, treating two NaNs as equal. |
|
||||
|`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
|
||||
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
|
||||
return false. The `NanSensitive*` version instead treats two NaNs as
|
||||
equal, which is often what a user wants.
|
||||
|
||||
|`DoubleNear(a_double, max_abs_error)`|`argument` is a `double` value close to `a_double` (absolute error <= `max_abs_error`), treating two NaNs as unequal.|
|
||||
|:------------------------------------|:--------------------------------------------------------------------------------------------------------------------|
|
||||
|`FloatNear(a_float, max_abs_error)` |`argument` is a `float` value close to `a_float` (absolute error <= `max_abs_error`), treating two NaNs as unequal. |
|
||||
|`NanSensitiveDoubleNear(a_double, max_abs_error)`|`argument` is a `double` value close to `a_double` (absolute error <= `max_abs_error`), treating two NaNs as equal. |
|
||||
|`NanSensitiveFloatNear(a_float, max_abs_error)`|`argument` is a `float` value close to `a_float` (absolute error <= `max_abs_error`), treating two NaNs as equal. |
|
||||
|
||||
## String Matchers ##
|
||||
|
||||
The `argument` can be either a C string or a C++ string object:
|
||||
|
||||
|`ContainsRegex(string)`|`argument` matches the given regular expression.|
|
||||
|:----------------------|:-----------------------------------------------|
|
||||
|`EndsWith(suffix)` |`argument` ends with string `suffix`. |
|
||||
|`HasSubstr(string)` |`argument` contains `string` as a sub-string. |
|
||||
|`MatchesRegex(string)` |`argument` matches the given regular expression with the match starting at the first character and ending at the last character.|
|
||||
|`StartsWith(prefix)` |`argument` starts with string `prefix`. |
|
||||
|`StrCaseEq(string)` |`argument` is equal to `string`, ignoring case. |
|
||||
|`StrCaseNe(string)` |`argument` is not equal to `string`, ignoring case.|
|
||||
|`StrEq(string)` |`argument` is equal to `string`. |
|
||||
|`StrNe(string)` |`argument` is not equal to `string`. |
|
||||
|
||||
`ContainsRegex()` and `MatchesRegex()` use the regular expression
|
||||
syntax defined
|
||||
[here](http://code.google.com/p/googletest/wiki/AdvancedGuide#Regular_Expression_Syntax).
|
||||
`StrCaseEq()`, `StrCaseNe()`, `StrEq()`, and `StrNe()` work for wide
|
||||
strings as well.
|
||||
|
||||
## Container Matchers ##
|
||||
|
||||
Most STL-style containers support `==`, so you can use
|
||||
`Eq(expected_container)` or simply `expected_container` to match a
|
||||
container exactly. If you want to write the elements in-line,
|
||||
match them more flexibly, or get more informative messages, you can use:
|
||||
|
||||
| `ContainerEq(container)` | The same as `Eq(container)` except that the failure message also includes which elements are in one container but not the other. |
|
||||
|:-------------------------|:---------------------------------------------------------------------------------------------------------------------------------|
|
||||
| `Contains(e)` | `argument` contains an element that matches `e`, which can be either a value or a matcher. |
|
||||
| `Each(e)` | `argument` is a container where _every_ element matches `e`, which can be either a value or a matcher. |
|
||||
| `ElementsAre(e0, e1, ..., en)` | `argument` has `n + 1` elements, where the i-th element matches `ei`, which can be a value or a matcher. 0 to 10 arguments are allowed. |
|
||||
| `ElementsAreArray({ e0, e1, ..., en })`, `ElementsAreArray(array)`, or `ElementsAreArray(array, count)` | The same as `ElementsAre()` except that the expected element values/matchers come from an initializer list, vector, or C-style array. |
|
||||
| `IsEmpty()` | `argument` is an empty container (`container.empty()`). |
|
||||
| `Pointwise(m, container)` | `argument` contains the same number of elements as in `container`, and for all i, (the i-th element in `argument`, the i-th element in `container`) match `m`, which is a matcher on 2-tuples. E.g. `Pointwise(Le(), upper_bounds)` verifies that each element in `argument` doesn't exceed the corresponding element in `upper_bounds`. See more detail below. |
|
||||
| `SizeIs(m)` | `argument` is a container whose size matches `m`. E.g. `SizeIs(2)` or `SizeIs(Lt(2))`. |
|
||||
| `UnorderedElementsAre(e0, e1, ..., en)` | `argument` has `n + 1` elements, and under some permutation each element matches an `ei` (for a different `i`), which can be a value or a matcher. 0 to 10 arguments are allowed. |
|
||||
| `UnorderedElementsAreArray({ e0, e1, ..., en })`, `UnorderedElementsAreArray(array)`, or `UnorderedElementsAreArray(array, count)` | The same as `UnorderedElementsAre()` except that the expected element values/matchers come from an initializer list, vector, or C-style array. |
|
||||
| `WhenSorted(m)` | When `argument` is sorted using the `<` operator, it matches container matcher `m`. E.g. `WhenSorted(UnorderedElementsAre(1, 2, 3))` verifies that `argument` contains elements `1`, `2`, and `3`, ignoring order. |
|
||||
| `WhenSortedBy(comparator, m)` | The same as `WhenSorted(m)`, except that the given comparator instead of `<` is used to sort `argument`. E.g. `WhenSortedBy(std::greater<int>(), ElementsAre(3, 2, 1))`. |
|
||||
|
||||
Notes:
|
||||
|
||||
* These matchers can also match:
|
||||
1. a native array passed by reference (e.g. in `Foo(const int (&a)[5])`), and
|
||||
1. an array passed as a pointer and a count (e.g. in `Bar(const T* buffer, int len)` -- see [Multi-argument Matchers](#Multiargument_Matchers.md)).
|
||||
* The array being matched may be multi-dimensional (i.e. its elements can be arrays).
|
||||
* `m` in `Pointwise(m, ...)` should be a matcher for `std::tr1::tuple<T, U>` where `T` and `U` are the element type of the actual container and the expected container, respectively. For example, to compare two `Foo` containers where `Foo` doesn't support `operator==` but has an `Equals()` method, one might write:
|
||||
|
||||
```
|
||||
using ::std::tr1::get;
|
||||
MATCHER(FooEq, "") {
|
||||
return get<0>(arg).Equals(get<1>(arg));
|
||||
}
|
||||
...
|
||||
EXPECT_THAT(actual_foos, Pointwise(FooEq(), expected_foos));
|
||||
```
|
||||
|
||||
## Member Matchers ##
|
||||
|
||||
|`Field(&class::field, m)`|`argument.field` (or `argument->field` when `argument` is a plain pointer) matches matcher `m`, where `argument` is an object of type _class_.|
|
||||
|:------------------------|:---------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
|`Key(e)` |`argument.first` matches `e`, which can be either a value or a matcher. E.g. `Contains(Key(Le(5)))` can verify that a `map` contains a key `<= 5`.|
|
||||
|`Pair(m1, m2)` |`argument` is an `std::pair` whose `first` field matches `m1` and `second` field matches `m2`. |
|
||||
|`Property(&class::property, m)`|`argument.property()` (or `argument->property()` when `argument` is a plain pointer) matches matcher `m`, where `argument` is an object of type _class_.|
|
||||
|
||||
## Matching the Result of a Function or Functor ##
|
||||
|
||||
|`ResultOf(f, m)`|`f(argument)` matches matcher `m`, where `f` is a function or functor.|
|
||||
|:---------------|:---------------------------------------------------------------------|
|
||||
|
||||
## Pointer Matchers ##
|
||||
|
||||
|`Pointee(m)`|`argument` (either a smart pointer or a raw pointer) points to a value that matches matcher `m`.|
|
||||
|:-----------|:-----------------------------------------------------------------------------------------------|
|
||||
|
||||
## Multiargument Matchers ##
|
||||
|
||||
Technically, all matchers match a _single_ value. A "multi-argument"
|
||||
matcher is just one that matches a _tuple_. The following matchers can
|
||||
be used to match a tuple `(x, y)`:
|
||||
|
||||
|`Eq()`|`x == y`|
|
||||
|:-----|:-------|
|
||||
|`Ge()`|`x >= y`|
|
||||
|`Gt()`|`x > y` |
|
||||
|`Le()`|`x <= y`|
|
||||
|`Lt()`|`x < y` |
|
||||
|`Ne()`|`x != y`|
|
||||
|
||||
You can use the following selectors to pick a subset of the arguments
|
||||
(or reorder them) to participate in the matching:
|
||||
|
||||
|`AllArgs(m)`|Equivalent to `m`. Useful as syntactic sugar in `.With(AllArgs(m))`.|
|
||||
|:-----------|:-------------------------------------------------------------------|
|
||||
|`Args<N1, N2, ..., Nk>(m)`|The tuple of the `k` selected (using 0-based indices) arguments matches `m`, e.g. `Args<1, 2>(Eq())`.|
|
||||
|
||||
## Composite Matchers ##
|
||||
|
||||
You can make a matcher from one or more other matchers:
|
||||
|
||||
|`AllOf(m1, m2, ..., mn)`|`argument` matches all of the matchers `m1` to `mn`.|
|
||||
|:-----------------------|:---------------------------------------------------|
|
||||
|`AnyOf(m1, m2, ..., mn)`|`argument` matches at least one of the matchers `m1` to `mn`.|
|
||||
|`Not(m)` |`argument` doesn't match matcher `m`. |
|
||||
|
||||
## Adapters for Matchers ##
|
||||
|
||||
|`MatcherCast<T>(m)`|casts matcher `m` to type `Matcher<T>`.|
|
||||
|:------------------|:--------------------------------------|
|
||||
|`SafeMatcherCast<T>(m)`| [safely casts](http://code.google.com/p/googlemock/wiki/V1_7_CookBook#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 ##
|
||||
|
||||
|`Matches(m)(value)`|evaluates to `true` if `value` matches `m`. You can use `Matches(m)` alone as a unary functor.|
|
||||
|:------------------|:---------------------------------------------------------------------------------------------|
|
||||
|`ExplainMatchResult(m, value, result_listener)`|evaluates to `true` if `value` matches `m`, explaining the result to `result_listener`. |
|
||||
|`Value(value, m)` |evaluates to `true` if `value` matches `m`. |
|
||||
|
||||
## Defining Matchers ##
|
||||
|
||||
| `MATCHER(IsEven, "") { return (arg % 2) == 0; }` | Defines a matcher `IsEven()` to match an even number. |
|
||||
|:-------------------------------------------------|:------------------------------------------------------|
|
||||
| `MATCHER_P(IsDivisibleBy, n, "") { *result_listener << "where the remainder is " << (arg % n); return (arg % n) == 0; }` | Defines a macher `IsDivisibleBy(n)` to match a number divisible by `n`. |
|
||||
| `MATCHER_P2(IsBetween, a, b, std::string(negation ? "isn't" : "is") + " between " + PrintToString(a) + " and " + PrintToString(b)) { return a <= arg && arg <= b; }` | Defines a matcher `IsBetween(a, b)` to match a value in the range [`a`, `b`]. |
|
||||
|
||||
**Notes:**
|
||||
|
||||
1. The `MATCHER*` macros cannot be used inside a function or class.
|
||||
1. The matcher body must be _purely functional_ (i.e. it cannot have any side effect, and the result must not depend on anything other than the value being matched and the matcher parameters).
|
||||
1. You can use `PrintToString(x)` to convert a value `x` of any type to a string.
|
||||
|
||||
## 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`.|
|
||||
|:---------------------------|:----------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
|`EXPECT_THAT(expression, m)`|Generates a non-fatal failure if the value of `expression` doesn't match matcher `m`. |
|
||||
|
||||
# Actions #
|
||||
|
||||
**Actions** specify what a mock function should do when invoked.
|
||||
|
||||
## Returning a Value ##
|
||||
|
||||
|`Return()`|Return from a `void` mock function.|
|
||||
|:---------|:----------------------------------|
|
||||
|`Return(value)`|Return `value`. If the type of `value` is different to the mock function's return type, `value` is converted to the latter type <i>at the time the expectation is set</i>, not when the action is executed.|
|
||||
|`ReturnArg<N>()`|Return the `N`-th (0-based) argument.|
|
||||
|`ReturnNew<T>(a1, ..., ak)`|Return `new T(a1, ..., ak)`; a different object is created each time.|
|
||||
|`ReturnNull()`|Return a null pointer. |
|
||||
|`ReturnPointee(ptr)`|Return the value pointed to by `ptr`.|
|
||||
|`ReturnRef(variable)`|Return a reference to `variable`. |
|
||||
|`ReturnRefOfCopy(value)`|Return a reference to a copy of `value`; the copy lives as long as the action.|
|
||||
|
||||
## Side Effects ##
|
||||
|
||||
|`Assign(&variable, value)`|Assign `value` to variable.|
|
||||
|:-------------------------|:--------------------------|
|
||||
| `DeleteArg<N>()` | Delete the `N`-th (0-based) argument, which must be a pointer. |
|
||||
| `SaveArg<N>(pointer)` | Save the `N`-th (0-based) argument to `*pointer`. |
|
||||
| `SaveArgPointee<N>(pointer)` | Save the value pointed to by the `N`-th (0-based) argument to `*pointer`. |
|
||||
| `SetArgReferee<N>(value)` | Assign value to the variable referenced by the `N`-th (0-based) argument. |
|
||||
|`SetArgPointee<N>(value)` |Assign `value` to the variable pointed by the `N`-th (0-based) argument.|
|
||||
|`SetArgumentPointee<N>(value)`|Same as `SetArgPointee<N>(value)`. Deprecated. Will be removed in v1.7.0.|
|
||||
|`SetArrayArgument<N>(first, last)`|Copies the elements in source range [`first`, `last`) to the array pointed to by the `N`-th (0-based) argument, which can be either a pointer or an iterator. The action does not take ownership of the elements in the source range.|
|
||||
|`SetErrnoAndReturn(error, value)`|Set `errno` to `error` and return `value`.|
|
||||
|`Throw(exception)` |Throws the given exception, which can be any copyable value. Available since v1.1.0.|
|
||||
|
||||
## Using a Function or a Functor as an Action ##
|
||||
|
||||
|`Invoke(f)`|Invoke `f` with the arguments passed to the mock function, where `f` can be a global/static function or a functor.|
|
||||
|:----------|:-----------------------------------------------------------------------------------------------------------------|
|
||||
|`Invoke(object_pointer, &class::method)`|Invoke the {method on the object with the arguments passed to the mock function. |
|
||||
|`InvokeWithoutArgs(f)`|Invoke `f`, which can be a global/static function or a functor. `f` must take no arguments. |
|
||||
|`InvokeWithoutArgs(object_pointer, &class::method)`|Invoke the method on the object, which takes no arguments. |
|
||||
|`InvokeArgument<N>(arg1, arg2, ..., argk)`|Invoke the mock function's `N`-th (0-based) argument, which must be a function or a functor, with the `k` arguments.|
|
||||
|
||||
The return value of the invoked function is used as the return value
|
||||
of the action.
|
||||
|
||||
When defining a function or functor to be used with `Invoke*()`, you can declare any unused parameters as `Unused`:
|
||||
```
|
||||
double Distance(Unused, double x, double y) { return sqrt(x*x + y*y); }
|
||||
...
|
||||
EXPECT_CALL(mock, Foo("Hi", _, _)).WillOnce(Invoke(Distance));
|
||||
```
|
||||
|
||||
In `InvokeArgument<N>(...)`, if an argument needs to be passed by reference, wrap it inside `ByRef()`. For example,
|
||||
```
|
||||
InvokeArgument<2>(5, string("Hi"), ByRef(foo))
|
||||
```
|
||||
calls the mock function's #2 argument, passing to it `5` and `string("Hi")` by value, and `foo` by reference.
|
||||
|
||||
## Default Action ##
|
||||
|
||||
|`DoDefault()`|Do the default action (specified by `ON_CALL()` or the built-in one).|
|
||||
|:------------|:--------------------------------------------------------------------|
|
||||
|
||||
**Note:** due to technical reasons, `DoDefault()` cannot be used inside a composite action - trying to do so will result in a run-time error.
|
||||
|
||||
## Composite Actions ##
|
||||
|
||||
|`DoAll(a1, a2, ..., an)`|Do all actions `a1` to `an` and return the result of `an` in each invocation. The first `n - 1` sub-actions must return void. |
|
||||
|:-----------------------|:-----------------------------------------------------------------------------------------------------------------------------|
|
||||
|`IgnoreResult(a)` |Perform action `a` and ignore its result. `a` must not return void. |
|
||||
|`WithArg<N>(a)` |Pass the `N`-th (0-based) argument of the mock function to action `a` and perform it. |
|
||||
|`WithArgs<N1, N2, ..., Nk>(a)`|Pass the selected (0-based) arguments of the mock function to action `a` and perform it. |
|
||||
|`WithoutArgs(a)` |Perform action `a` without any arguments. |
|
||||
|
||||
## Defining Actions ##
|
||||
|
||||
| `ACTION(Sum) { return arg0 + arg1; }` | Defines an action `Sum()` to return the sum of the mock function's argument #0 and #1. |
|
||||
|:--------------------------------------|:---------------------------------------------------------------------------------------|
|
||||
| `ACTION_P(Plus, n) { return arg0 + n; }` | Defines an action `Plus(n)` to return the sum of the mock function's argument #0 and `n`. |
|
||||
| `ACTION_Pk(Foo, p1, ..., pk) { statements; }` | Defines a parameterized action `Foo(p1, ..., pk)` to execute the given `statements`. |
|
||||
|
||||
The `ACTION*` macros cannot be used inside a function or class.
|
||||
|
||||
# Cardinalities #
|
||||
|
||||
These are used in `Times()` to specify how many times a mock function will be called:
|
||||
|
||||
|`AnyNumber()`|The function can be called any number of times.|
|
||||
|:------------|:----------------------------------------------|
|
||||
|`AtLeast(n)` |The call is expected at least `n` times. |
|
||||
|`AtMost(n)` |The call is expected at most `n` times. |
|
||||
|`Between(m, n)`|The call is expected between `m` and `n` (inclusive) times.|
|
||||
|`Exactly(n) or n`|The call is expected exactly `n` times. In particular, the call should never happen when `n` is 0.|
|
||||
|
||||
# Expectation Order #
|
||||
|
||||
By default, the expectations can be matched in _any_ order. If some
|
||||
or all expectations must be matched in a given order, there are two
|
||||
ways to specify it. They can be used either independently or
|
||||
together.
|
||||
|
||||
## The After Clause ##
|
||||
|
||||
```
|
||||
using ::testing::Expectation;
|
||||
...
|
||||
Expectation init_x = EXPECT_CALL(foo, InitX());
|
||||
Expectation init_y = EXPECT_CALL(foo, InitY());
|
||||
EXPECT_CALL(foo, Bar())
|
||||
.After(init_x, init_y);
|
||||
```
|
||||
says that `Bar()` can be called only after both `InitX()` and
|
||||
`InitY()` have been called.
|
||||
|
||||
If you don't know how many pre-requisites an expectation has when you
|
||||
write it, you can use an `ExpectationSet` to collect them:
|
||||
|
||||
```
|
||||
using ::testing::ExpectationSet;
|
||||
...
|
||||
ExpectationSet all_inits;
|
||||
for (int i = 0; i < element_count; i++) {
|
||||
all_inits += EXPECT_CALL(foo, InitElement(i));
|
||||
}
|
||||
EXPECT_CALL(foo, Bar())
|
||||
.After(all_inits);
|
||||
```
|
||||
says that `Bar()` can be called only after all elements have been
|
||||
initialized (but we don't care about which elements get initialized
|
||||
before the others).
|
||||
|
||||
Modifying an `ExpectationSet` after using it in an `.After()` doesn't
|
||||
affect the meaning of the `.After()`.
|
||||
|
||||
## Sequences ##
|
||||
|
||||
When you have a long chain of sequential expectations, it's easier to
|
||||
specify the order using **sequences**, which don't require you to given
|
||||
each expectation in the chain a different name. <i>All expected<br>
|
||||
calls</i> in the same sequence must occur in the order they are
|
||||
specified.
|
||||
|
||||
```
|
||||
using ::testing::Sequence;
|
||||
Sequence s1, s2;
|
||||
...
|
||||
EXPECT_CALL(foo, Reset())
|
||||
.InSequence(s1, s2)
|
||||
.WillOnce(Return(true));
|
||||
EXPECT_CALL(foo, GetSize())
|
||||
.InSequence(s1)
|
||||
.WillOnce(Return(1));
|
||||
EXPECT_CALL(foo, Describe(A<const char*>()))
|
||||
.InSequence(s2)
|
||||
.WillOnce(Return("dummy"));
|
||||
```
|
||||
says that `Reset()` must be called before _both_ `GetSize()` _and_
|
||||
`Describe()`, and the latter two can occur in any order.
|
||||
|
||||
To put many expectations in a sequence conveniently:
|
||||
```
|
||||
using ::testing::InSequence;
|
||||
{
|
||||
InSequence dummy;
|
||||
|
||||
EXPECT_CALL(...)...;
|
||||
EXPECT_CALL(...)...;
|
||||
...
|
||||
EXPECT_CALL(...)...;
|
||||
}
|
||||
```
|
||||
says that all expected calls in the scope of `dummy` must occur in
|
||||
strict order. The name `dummy` is irrelevant.)
|
||||
|
||||
# Verifying and Resetting a Mock #
|
||||
|
||||
Google Mock will verify the expectations on a mock object when it is destructed, or you can do it earlier:
|
||||
```
|
||||
using ::testing::Mock;
|
||||
...
|
||||
// Verifies and removes the expectations on mock_obj;
|
||||
// returns true iff successful.
|
||||
Mock::VerifyAndClearExpectations(&mock_obj);
|
||||
...
|
||||
// Verifies and removes the expectations on mock_obj;
|
||||
// also removes the default actions set by ON_CALL();
|
||||
// returns true iff successful.
|
||||
Mock::VerifyAndClear(&mock_obj);
|
||||
```
|
||||
|
||||
You can also tell Google Mock that a mock object can be leaked and doesn't
|
||||
need to be verified:
|
||||
```
|
||||
Mock::AllowLeak(&mock_obj);
|
||||
```
|
||||
|
||||
# Mock Classes #
|
||||
|
||||
Google Mock defines a convenient mock class template
|
||||
```
|
||||
class MockFunction<R(A1, ..., An)> {
|
||||
public:
|
||||
MOCK_METHODn(Call, R(A1, ..., An));
|
||||
};
|
||||
```
|
||||
See this [recipe](http://code.google.com/p/googlemock/wiki/V1_7_CookBook#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. |
|
||||
3432
test/gtest-1.8.0/googlemock/docs/v1_7/CookBook.md
Normal file
3432
test/gtest-1.8.0/googlemock/docs/v1_7/CookBook.md
Normal file
File diff suppressed because it is too large
Load Diff
12
test/gtest-1.8.0/googlemock/docs/v1_7/Documentation.md
Normal file
12
test/gtest-1.8.0/googlemock/docs/v1_7/Documentation.md
Normal file
@@ -0,0 +1,12 @@
|
||||
This page lists all documentation wiki pages for Google Mock **(the SVN trunk version)**
|
||||
- **if you use a released version of Google Mock, please read the documentation for that specific version instead.**
|
||||
|
||||
* [ForDummies](V1_7_ForDummies.md) -- start here if you are new to Google Mock.
|
||||
* [CheatSheet](V1_7_CheatSheet.md) -- a quick reference.
|
||||
* [CookBook](V1_7_CookBook.md) -- recipes for doing various tasks using Google Mock.
|
||||
* [FrequentlyAskedQuestions](V1_7_FrequentlyAskedQuestions.md) -- check here before asking a question on the mailing list.
|
||||
|
||||
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.
|
||||
439
test/gtest-1.8.0/googlemock/docs/v1_7/ForDummies.md
Normal file
439
test/gtest-1.8.0/googlemock/docs/v1_7/ForDummies.md
Normal file
@@ -0,0 +1,439 @@
|
||||
|
||||
|
||||
(**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/V1_7_FrequentlyAskedQuestions#How_am_I_supposed_to_make_sense_of_these_horrible_template_error).)
|
||||
|
||||
# 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).
|
||||
|
||||
**Note:** It is easy to confuse the term _fake objects_ with mock objects. Fakes and mocks actually mean very different things in the Test-Driven Development (TDD) community:
|
||||
|
||||
* **Fake** objects have working implementations, but usually take some shortcut (perhaps to make the operations less expensive), which makes them not suitable for production. An in-memory file system would be an example of a fake.
|
||||
* **Mocks** are objects pre-programmed with _expectations_, which form a specification of the calls they are expected to receive.
|
||||
|
||||
If all this seems too abstract for you, don't worry - the most important thing to remember is that a mock allows you to check the _interaction_ between itself and code that uses it. The difference between fakes and mocks will become much clearer once you start to use mocks.
|
||||
|
||||
**Google C++ Mocking Framework** (or **Google Mock** for short) is a library (sometimes we also call it a "framework" to make it sound cool) for creating mock classes and using them. It does to C++ what [jMock](http://www.jmock.org/) and [EasyMock](http://www.easymock.org/) do to Java.
|
||||
|
||||
Using Google Mock involves three basic steps:
|
||||
|
||||
1. Use some simple macros to describe the interface you want to mock, and they will expand to the implementation of your mock class;
|
||||
1. Create some mock objects and specify its expectations and behavior using an intuitive syntax;
|
||||
1. Exercise code that uses the mock objects. Google Mock will catch any violation of the expectations as soon as it arises.
|
||||
|
||||
# Why Google Mock? #
|
||||
While mock objects help you remove unnecessary dependencies in tests and make them fast and reliable, using mocks manually in C++ is _hard_:
|
||||
|
||||
* Someone has to implement the mocks. The job is usually tedious and error-prone. No wonder people go great distance to avoid it.
|
||||
* The quality of those manually written mocks is a bit, uh, unpredictable. You may see some really polished ones, but you may also see some that were hacked up in a hurry and have all sorts of ad hoc restrictions.
|
||||
* The knowledge you gained from using one mock doesn't transfer to the next.
|
||||
|
||||
In contrast, Java and Python programmers have some fine mock frameworks, which automate the creation of mocks. As a result, mocking is a proven effective technique and widely adopted practice in those communities. Having the right tool absolutely makes the difference.
|
||||
|
||||
Google Mock was built to help C++ programmers. It was inspired by [jMock](http://www.jmock.org/) and [EasyMock](http://www.easymock.org/), but designed with C++'s specifics in mind. It is your friend if any of the following problems is bothering you:
|
||||
|
||||
* You are stuck with a sub-optimal design and wish you had done more prototyping before it was too late, but prototyping in C++ is by no means "rapid".
|
||||
* Your tests are slow as they depend on too many libraries or use expensive resources (e.g. a database).
|
||||
* Your tests are brittle as some resources they use are unreliable (e.g. the network).
|
||||
* You want to test how your code handles a failure (e.g. a file checksum error), but it's not easy to cause one.
|
||||
* You need to make sure that your module interacts with other modules in the right way, but it's hard to observe the interaction; therefore you resort to observing the side effects at the end of the action, which is awkward at best.
|
||||
* You want to "mock out" your dependencies, except that they don't have mock implementations yet; and, frankly, you aren't thrilled by some of those hand-written mocks.
|
||||
|
||||
We encourage you to use Google Mock as:
|
||||
|
||||
* a _design_ tool, for it lets you experiment with your interface design early and often. More iterations lead to better designs!
|
||||
* 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.
|
||||
|
||||
# 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:
|
||||
|
||||
```
|
||||
class Turtle {
|
||||
...
|
||||
virtual ~Turtle() {}
|
||||
virtual void PenUp() = 0;
|
||||
virtual void PenDown() = 0;
|
||||
virtual void Forward(int distance) = 0;
|
||||
virtual void Turn(int degrees) = 0;
|
||||
virtual void GoTo(int x, int y) = 0;
|
||||
virtual int GetX() const = 0;
|
||||
virtual int GetY() const = 0;
|
||||
};
|
||||
```
|
||||
|
||||
(Note that the destructor of `Turtle` **must** be virtual, as is the case for **all** classes you intend to inherit from - otherwise the destructor of the derived class will not be called when you delete an object through a base pointer, and you'll get corrupted program states like memory leaks.)
|
||||
|
||||
You can control whether the turtle's movement will leave a trace using `PenUp()` and `PenDown()`, and control its movement using `Forward()`, `Turn()`, and `GoTo()`. Finally, `GetX()` and `GetY()` tell you the current position of the turtle.
|
||||
|
||||
Your program will normally use a real implementation of this interface. In tests, you can use a mock implementation instead. This allows you to easily check what drawing primitives your program is calling, with what arguments, and in which order. Tests written this way are much more robust (they won't break because your new machine does anti-aliasing differently), easier to read and maintain (the intent of a test is expressed in the code, not in some binary images), and run _much, much faster_.
|
||||
|
||||
# Writing the Mock Class #
|
||||
If you are lucky, the mocks you need to use have already been implemented by some nice people. If, however, you find yourself in the position to write a mock class, relax - Google Mock turns this task into a fun game! (Well, almost.)
|
||||
|
||||
## How to Define It ##
|
||||
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/V1_7_CookBook#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.
|
||||
|
||||
After the process, you should have something like:
|
||||
|
||||
```
|
||||
#include "gmock/gmock.h" // Brings in Google Mock.
|
||||
class MockTurtle : public Turtle {
|
||||
public:
|
||||
...
|
||||
MOCK_METHOD0(PenUp, void());
|
||||
MOCK_METHOD0(PenDown, void());
|
||||
MOCK_METHOD1(Forward, void(int distance));
|
||||
MOCK_METHOD1(Turn, void(int degrees));
|
||||
MOCK_METHOD2(GoTo, void(int x, int y));
|
||||
MOCK_CONST_METHOD0(GetX, int());
|
||||
MOCK_CONST_METHOD0(GetY, int());
|
||||
};
|
||||
```
|
||||
|
||||
You don't need to define these mock methods somewhere else - the `MOCK_METHOD*` macros will generate the definitions for you. It's that simple! Once you get the hang of it, you can pump out mock classes faster than your source-control system can handle your check-ins.
|
||||
|
||||
**Tip:** If even this is too much work for you, you'll find the
|
||||
`gmock_gen.py` tool in Google Mock's `scripts/generator/` directory (courtesy of the [cppclean](http://code.google.com/p/cppclean/) project) useful. This command-line
|
||||
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).
|
||||
|
||||
## 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?)
|
||||
|
||||
So, the rule of thumb is: if you need to mock `Foo` and it's owned by others, define the mock class in `Foo`'s package (better, in a `testing` sub-package such that you can clearly separate production code and testing utilities), and put it in a `mock_foo.h`. Then everyone can reference `mock_foo.h` from their tests. If `Foo` ever changes, there is only one copy of `MockFoo` to change, and only tests that depend on the changed methods need to be fixed.
|
||||
|
||||
Another way to do it: you can introduce a thin layer `FooAdaptor` on top of `Foo` and code to this new interface. Since you own `FooAdaptor`, you can absorb changes in `Foo` much more easily. While this is more work initially, carefully choosing the adaptor interface can make your code easier to write and more readable (a net win in the long run), as you can choose `FooAdaptor` to fit your specific domain much better than `Foo` does.
|
||||
|
||||
# Using Mocks in Tests #
|
||||
Once you have a mock class, using it is easy. The typical work flow is:
|
||||
|
||||
1. Import the Google Mock names from the `testing` namespace such that you can use them unqualified (You only have to do it once per file. Remember that namespaces are a good idea and good for your health.).
|
||||
1. Create some mock objects.
|
||||
1. Specify your expectations on them (How many times will a method be called? With what arguments? What should it do? etc.).
|
||||
1. Exercise some code that uses the mocks; optionally, check the result using Google Test assertions. If a mock method is called more than expected or with wrong arguments, you'll get an error immediately.
|
||||
1. When a mock is destructed, Google Mock will automatically check whether all expectations on it have been satisfied.
|
||||
|
||||
Here's an example:
|
||||
|
||||
```
|
||||
#include "path/to/mock-turtle.h"
|
||||
#include "gmock/gmock.h"
|
||||
#include "gtest/gtest.h"
|
||||
using ::testing::AtLeast; // #1
|
||||
|
||||
TEST(PainterTest, CanDrawSomething) {
|
||||
MockTurtle turtle; // #2
|
||||
EXPECT_CALL(turtle, PenDown()) // #3
|
||||
.Times(AtLeast(1));
|
||||
|
||||
Painter painter(&turtle); // #4
|
||||
|
||||
EXPECT_TRUE(painter.DrawCircle(0, 0, 10));
|
||||
} // #5
|
||||
|
||||
int main(int argc, char** argv) {
|
||||
// The following line must be executed to initialize Google Mock
|
||||
// (and Google Test) before running the tests.
|
||||
::testing::InitGoogleMock(&argc, argv);
|
||||
return RUN_ALL_TESTS();
|
||||
}
|
||||
```
|
||||
|
||||
As you might have guessed, this test checks that `PenDown()` is called at least once. If the `painter` object didn't call this method, your test will fail with a message like this:
|
||||
|
||||
```
|
||||
path/to/my_test.cc:119: Failure
|
||||
Actual function call count doesn't match this expectation:
|
||||
Actually: never called;
|
||||
Expected: called at least once.
|
||||
```
|
||||
|
||||
**Tip 1:** If you run the test from an Emacs buffer, you can hit `<Enter>` on the line number displayed in the error message to jump right to the failed expectation.
|
||||
|
||||
**Tip 2:** If your mock objects are never deleted, the final verification won't happen. Therefore it's a good idea to use a heap leak checker in your tests when you allocate mocks on the heap.
|
||||
|
||||
**Important note:** Google Mock requires expectations to be set **before** the mock functions are called, otherwise the behavior is **undefined**. In particular, you mustn't interleave `EXPECT_CALL()`s and calls to the mock functions.
|
||||
|
||||
This means `EXPECT_CALL()` should be read as expecting that a call will occur _in the future_, not that a call has occurred. Why does Google Mock work like that? Well, specifying the expectation beforehand allows Google Mock to report a violation as soon as it arises, when the context (stack trace, etc) is still available. This makes debugging much easier.
|
||||
|
||||
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
|
||||
[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) {
|
||||
// The following line causes Google Mock to throw an exception on failure,
|
||||
// which will be interpreted by your testing framework as a test failure.
|
||||
::testing::GTEST_FLAG(throw_on_failure) = true;
|
||||
::testing::InitGoogleMock(&argc, argv);
|
||||
... whatever your testing framework requires ...
|
||||
}
|
||||
```
|
||||
|
||||
This approach has a catch: it makes Google Mock throw an exception
|
||||
from a mock object's destructor sometimes. With some compilers, this
|
||||
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)
|
||||
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.
|
||||
|
||||
If this turns out to be too much work, we suggest that you stick with
|
||||
Google Test, which works with Google Mock seamlessly (in fact, it is
|
||||
technically part of Google Mock.). If there is a reason that you
|
||||
cannot use Google Test, please let us know.
|
||||
|
||||
# Setting Expectations #
|
||||
The key to using a mock object successfully is to set the _right expectations_ on it. If you set the expectations too strict, your test will fail as the result of unrelated changes. If you set them too loose, bugs can slip through. You want to do it just right such that your test can catch exactly the kind of bugs you intend it to catch. Google Mock provides the necessary means for you to do it "just right."
|
||||
|
||||
## General Syntax ##
|
||||
In Google Mock we use the `EXPECT_CALL()` macro to set an expectation on a mock method. The general syntax is:
|
||||
|
||||
```
|
||||
EXPECT_CALL(mock_object, method(matchers))
|
||||
.Times(cardinality)
|
||||
.WillOnce(action)
|
||||
.WillRepeatedly(action);
|
||||
```
|
||||
|
||||
The macro has two arguments: first the mock object, and then the method and its arguments. Note that the two are separated by a comma (`,`), not a period (`.`). (Why using a comma? The answer is that it was necessary for technical reasons.)
|
||||
|
||||
The macro can be followed by some optional _clauses_ that provide more information about the expectation. We'll discuss how each clause works in the coming sections.
|
||||
|
||||
This syntax is designed to make an expectation read like English. For example, you can probably guess that
|
||||
|
||||
```
|
||||
using ::testing::Return;...
|
||||
EXPECT_CALL(turtle, GetX())
|
||||
.Times(5)
|
||||
.WillOnce(Return(100))
|
||||
.WillOnce(Return(150))
|
||||
.WillRepeatedly(Return(200));
|
||||
```
|
||||
|
||||
says that the `turtle` object's `GetX()` method will be called five times, it will return 100 the first time, 150 the second time, and then 200 every time. Some people like to call this style of syntax a Domain-Specific Language (DSL).
|
||||
|
||||
**Note:** Why do we use a macro to do this? It serves two purposes: first it makes expectations easily identifiable (either by `grep` or by a human reader), and second it allows Google Mock to include the source file location of a failed expectation in messages, making debugging easier.
|
||||
|
||||
## Matchers: What Arguments Do We Expect? ##
|
||||
When a mock function takes arguments, we must specify what arguments we are expecting; for example:
|
||||
|
||||
```
|
||||
// Expects the turtle to move forward by 100 units.
|
||||
EXPECT_CALL(turtle, Forward(100));
|
||||
```
|
||||
|
||||
Sometimes you may not want to be too specific (Remember that talk about tests being too rigid? Over specification leads to brittle tests and obscures the intent of tests. Therefore we encourage you to specify only what's necessary - no more, no less.). If you care to check that `Forward()` will be called but aren't interested in its actual argument, write `_` as the argument, which means "anything goes":
|
||||
|
||||
```
|
||||
using ::testing::_;
|
||||
...
|
||||
// Expects the turtle to move forward.
|
||||
EXPECT_CALL(turtle, Forward(_));
|
||||
```
|
||||
|
||||
`_` is an instance of what we call **matchers**. A matcher is like a predicate and can test whether an argument is what we'd expect. You can use a matcher inside `EXPECT_CALL()` wherever a function argument is expected.
|
||||
|
||||
A list of built-in matchers can be found in the [CheatSheet](V1_7_CheatSheet.md). For example, here's the `Ge` (greater than or equal) matcher:
|
||||
|
||||
```
|
||||
using ::testing::Ge;...
|
||||
EXPECT_CALL(turtle, Forward(Ge(100)));
|
||||
```
|
||||
|
||||
This checks that the turtle will be told to go forward by at least 100 units.
|
||||
|
||||
## Cardinalities: How Many Times Will It Be Called? ##
|
||||
The first clause we can specify following an `EXPECT_CALL()` is `Times()`. We call its argument a **cardinality** as it tells _how many times_ the call should occur. It allows us to repeat an expectation many times without actually writing it as many times. More importantly, a cardinality can be "fuzzy", just like a matcher can be. This allows a user to express the intent of a test exactly.
|
||||
|
||||
An interesting special case is when we say `Times(0)`. You may have guessed - it means that the function shouldn't be called with the given arguments at all, and Google Mock will report a Google Test failure whenever the function is (wrongfully) called.
|
||||
|
||||
We've seen `AtLeast(n)` as an example of fuzzy cardinalities earlier. For the list of built-in cardinalities you can use, see the [CheatSheet](V1_7_CheatSheet.md).
|
||||
|
||||
The `Times()` clause can be omitted. **If you omit `Times()`, Google Mock will infer the cardinality for you.** The rules are easy to remember:
|
||||
|
||||
* If **neither** `WillOnce()` **nor** `WillRepeatedly()` is in the `EXPECT_CALL()`, the inferred cardinality is `Times(1)`.
|
||||
* If there are `n WillOnce()`'s but **no** `WillRepeatedly()`, where `n` >= 1, the cardinality is `Times(n)`.
|
||||
* If there are `n WillOnce()`'s and **one** `WillRepeatedly()`, where `n` >= 0, the cardinality is `Times(AtLeast(n))`.
|
||||
|
||||
**Quick quiz:** what do you think will happen if a function is expected to be called twice but actually called four times?
|
||||
|
||||
## Actions: What Should It Do? ##
|
||||
Remember that a mock object doesn't really have a working implementation? We as users have to tell it what to do when a method is invoked. This is easy in Google Mock.
|
||||
|
||||
First, if the return type of a mock function is a built-in type or a pointer, the function has a **default action** (a `void` function will just return, a `bool` function will return `false`, and other functions will return 0). If you don't say anything, this behavior will be used.
|
||||
|
||||
Second, if a mock function doesn't have a default action, or the default action doesn't suit you, you can specify the action to be taken each time the expectation matches using a series of `WillOnce()` clauses followed by an optional `WillRepeatedly()`. For example,
|
||||
|
||||
```
|
||||
using ::testing::Return;...
|
||||
EXPECT_CALL(turtle, GetX())
|
||||
.WillOnce(Return(100))
|
||||
.WillOnce(Return(200))
|
||||
.WillOnce(Return(300));
|
||||
```
|
||||
|
||||
This says that `turtle.GetX()` will be called _exactly three times_ (Google Mock inferred this from how many `WillOnce()` clauses we've written, since we didn't explicitly write `Times()`), and will return 100, 200, and 300 respectively.
|
||||
|
||||
```
|
||||
using ::testing::Return;...
|
||||
EXPECT_CALL(turtle, GetY())
|
||||
.WillOnce(Return(100))
|
||||
.WillOnce(Return(200))
|
||||
.WillRepeatedly(Return(300));
|
||||
```
|
||||
|
||||
says that `turtle.GetY()` will be called _at least twice_ (Google Mock knows this as we've written two `WillOnce()` clauses and a `WillRepeatedly()` while having no explicit `Times()`), will return 100 the first time, 200 the second time, and 300 from the third time on.
|
||||
|
||||
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/V1_7_CheatSheet#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:
|
||||
|
||||
```
|
||||
int n = 100;
|
||||
EXPECT_CALL(turtle, GetX())
|
||||
.Times(4)
|
||||
.WillRepeatedly(Return(n++));
|
||||
```
|
||||
|
||||
Instead of returning 100, 101, 102, ..., consecutively, this mock function will always return 100 as `n++` is only evaluated once. Similarly, `Return(new Foo)` will create a new `Foo` object when the `EXPECT_CALL()` is executed, and will return the same pointer every time. If you want the side effect to happen every time, you need to define a custom action, which we'll teach in the [CookBook](V1_7_CookBook.md).
|
||||
|
||||
Time for another quiz! What do you think the following means?
|
||||
|
||||
```
|
||||
using ::testing::Return;...
|
||||
EXPECT_CALL(turtle, GetY())
|
||||
.Times(4)
|
||||
.WillOnce(Return(100));
|
||||
```
|
||||
|
||||
Obviously `turtle.GetY()` is expected to be called four times. But if you think it will return 100 every time, think twice! Remember that one `WillOnce()` clause will be consumed each time the function is invoked and the default action will be taken afterwards. So the right answer is that `turtle.GetY()` will return 100 the first time, but **return 0 from the second time on**, as returning 0 is the default action for `int` functions.
|
||||
|
||||
## Using Multiple Expectations ##
|
||||
So far we've only shown examples where you have a single expectation. More realistically, you're going to specify expectations on multiple mock methods, which may be from multiple mock objects.
|
||||
|
||||
By default, when a mock method is invoked, Google Mock will search the expectations in the **reverse order** they are defined, and stop when an active expectation that matches the arguments is found (you can think of it as "newer rules override older ones."). If the matching expectation cannot take any more calls, you will get an upper-bound-violated failure. Here's an example:
|
||||
|
||||
```
|
||||
using ::testing::_;...
|
||||
EXPECT_CALL(turtle, Forward(_)); // #1
|
||||
EXPECT_CALL(turtle, Forward(10)) // #2
|
||||
.Times(2);
|
||||
```
|
||||
|
||||
If `Forward(10)` is called three times in a row, the third time it will be an error, as the last matching expectation (#2) has been saturated. If, however, the third `Forward(10)` call is replaced by `Forward(20)`, then it would be OK, as now #1 will be the matching expectation.
|
||||
|
||||
**Side note:** Why does Google Mock search for a match in the _reverse_ order of the expectations? The reason is that this allows a user to set up the default expectations in a mock object's constructor or the test fixture's set-up phase and then customize the mock by writing more specific expectations in the test body. So, if you have two expectations on the same method, you want to put the one with more specific matchers **after** the other, or the more specific rule would be shadowed by the more general one that comes after it.
|
||||
|
||||
## Ordered vs Unordered Calls ##
|
||||
By default, an expectation can match a call even though an earlier expectation hasn't been satisfied. In other words, the calls don't have to occur in the order the expectations are specified.
|
||||
|
||||
Sometimes, you may want all the expected calls to occur in a strict order. To say this in Google Mock is easy:
|
||||
|
||||
```
|
||||
using ::testing::InSequence;...
|
||||
TEST(FooTest, DrawsLineSegment) {
|
||||
...
|
||||
{
|
||||
InSequence dummy;
|
||||
|
||||
EXPECT_CALL(turtle, PenDown());
|
||||
EXPECT_CALL(turtle, Forward(100));
|
||||
EXPECT_CALL(turtle, PenUp());
|
||||
}
|
||||
Foo();
|
||||
}
|
||||
```
|
||||
|
||||
By creating an object of type `InSequence`, all expectations in its scope are put into a _sequence_ and have to occur _sequentially_. Since we are just relying on the constructor and destructor of this object to do the actual work, its name is really irrelevant.
|
||||
|
||||
In this example, we test that `Foo()` calls the three expected functions in the order as written. If a call is made out-of-order, it will be an error.
|
||||
|
||||
(What if you care about the relative order of some of the calls, but not all of them? Can you specify an arbitrary partial order? The answer is ... yes! If you are impatient, the details can be found in the [CookBook](V1_7_CookBook#Expecting_Partially_Ordered_Calls.md).)
|
||||
|
||||
## All Expectations Are Sticky (Unless Said Otherwise) ##
|
||||
Now let's do a quick quiz to see how well you can use this mock stuff already. How would you test that the turtle is asked to go to the origin _exactly twice_ (you want to ignore any other instructions it receives)?
|
||||
|
||||
After you've come up with your answer, take a look at ours and compare notes (solve it yourself first - don't cheat!):
|
||||
|
||||
```
|
||||
using ::testing::_;...
|
||||
EXPECT_CALL(turtle, GoTo(_, _)) // #1
|
||||
.Times(AnyNumber());
|
||||
EXPECT_CALL(turtle, GoTo(0, 0)) // #2
|
||||
.Times(2);
|
||||
```
|
||||
|
||||
Suppose `turtle.GoTo(0, 0)` is called three times. In the third time, Google Mock will see that the arguments match expectation #2 (remember that we always pick the last matching expectation). Now, since we said that there should be only two such calls, Google Mock will report an error immediately. This is basically what we've told you in the "Using Multiple Expectations" section above.
|
||||
|
||||
This example shows that **expectations in Google Mock are "sticky" by default**, in the sense that they remain active even after we have reached their invocation upper bounds. This is an important rule to remember, as it affects the meaning of the spec, and is **different** to how it's done in many other mocking frameworks (Why'd we do that? Because we think our rule makes the common cases easier to express and understand.).
|
||||
|
||||
Simple? Let's see if you've really understood it: what does the following code say?
|
||||
|
||||
```
|
||||
using ::testing::Return;
|
||||
...
|
||||
for (int i = n; i > 0; i--) {
|
||||
EXPECT_CALL(turtle, GetX())
|
||||
.WillOnce(Return(10*i));
|
||||
}
|
||||
```
|
||||
|
||||
If you think it says that `turtle.GetX()` will be called `n` times and will return 10, 20, 30, ..., consecutively, think twice! The problem is that, as we said, expectations are sticky. So, the second time `turtle.GetX()` is called, the last (latest) `EXPECT_CALL()` statement will match, and will immediately lead to an "upper bound exceeded" error - this piece of code is not very useful!
|
||||
|
||||
One correct way of saying that `turtle.GetX()` will return 10, 20, 30, ..., is to explicitly say that the expectations are _not_ sticky. In other words, they should _retire_ as soon as they are saturated:
|
||||
|
||||
```
|
||||
using ::testing::Return;
|
||||
...
|
||||
for (int i = n; i > 0; i--) {
|
||||
EXPECT_CALL(turtle, GetX())
|
||||
.WillOnce(Return(10*i))
|
||||
.RetiresOnSaturation();
|
||||
}
|
||||
```
|
||||
|
||||
And, there's a better way to do it: in this case, we expect the calls to occur in a specific order, and we line up the actions to match the order. Since the order is important here, we should make it explicit using a sequence:
|
||||
|
||||
```
|
||||
using ::testing::InSequence;
|
||||
using ::testing::Return;
|
||||
...
|
||||
{
|
||||
InSequence s;
|
||||
|
||||
for (int i = 1; i <= n; i++) {
|
||||
EXPECT_CALL(turtle, GetX())
|
||||
.WillOnce(Return(10*i))
|
||||
.RetiresOnSaturation();
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
By the way, the other situation where an expectation may _not_ be sticky is when it's in a sequence - as soon as another expectation that comes after it in the sequence has been used, it automatically retires (and will never be used to match any call).
|
||||
|
||||
## Uninteresting Calls ##
|
||||
A mock object may have many methods, and not all of them are that interesting. For example, in some tests we may not care about how many times `GetX()` and `GetY()` get called.
|
||||
|
||||
In Google Mock, if you are not interested in a method, just don't say anything about it. If a call to this method occurs, you'll see a warning in the test output, but it won't be a failure.
|
||||
|
||||
# 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](V1_7_CookBook.md). You can learn many advanced features of Google Mock there -- and advance your level of enjoyment and testing bliss.
|
||||
@@ -0,0 +1,628 @@
|
||||
|
||||
|
||||
Please send your questions to the
|
||||
[googlemock](http://groups.google.com/group/googlemock) discussion
|
||||
group. If you need help with compiler errors, make sure you have
|
||||
tried [Google Mock Doctor](#How_am_I_supposed_to_make_sense_of_these_horrible_template_error.md) first.
|
||||
|
||||
## 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/V1_7_CookBook#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? ##
|
||||
|
||||
After version 1.4.0 of Google Mock was released, we had an idea on how
|
||||
to make it easier to write matchers that can generate informative
|
||||
messages efficiently. We experimented with this idea and liked what
|
||||
we saw. Therefore we decided to implement it.
|
||||
|
||||
Unfortunately, this means that if you have defined your own matchers
|
||||
by implementing `MatcherInterface` or using `MakePolymorphicMatcher()`,
|
||||
your definitions will no longer compile. Matchers defined using the
|
||||
`MATCHER*` family of macros are not affected.
|
||||
|
||||
Sorry for the hassle if your matchers are affected. We believe it's
|
||||
in everyone's long-term interest to make this change sooner than
|
||||
later. Fortunately, it's usually not hard to migrate an existing
|
||||
matcher to the new API. Here's what you need to do:
|
||||
|
||||
If you wrote your matcher like this:
|
||||
```
|
||||
// Old matcher definition that doesn't work with the latest
|
||||
// Google Mock.
|
||||
using ::testing::MatcherInterface;
|
||||
...
|
||||
class MyWonderfulMatcher : public MatcherInterface<MyType> {
|
||||
public:
|
||||
...
|
||||
virtual bool Matches(MyType value) const {
|
||||
// Returns true if value matches.
|
||||
return value.GetFoo() > 5;
|
||||
}
|
||||
...
|
||||
};
|
||||
```
|
||||
|
||||
you'll need to change it to:
|
||||
```
|
||||
// New matcher definition that works with the latest Google Mock.
|
||||
using ::testing::MatcherInterface;
|
||||
using ::testing::MatchResultListener;
|
||||
...
|
||||
class MyWonderfulMatcher : public MatcherInterface<MyType> {
|
||||
public:
|
||||
...
|
||||
virtual bool MatchAndExplain(MyType value,
|
||||
MatchResultListener* listener) const {
|
||||
// Returns true if value matches.
|
||||
return value.GetFoo() > 5;
|
||||
}
|
||||
...
|
||||
};
|
||||
```
|
||||
(i.e. rename `Matches()` to `MatchAndExplain()` and give it a second
|
||||
argument of type `MatchResultListener*`.)
|
||||
|
||||
If you were also using `ExplainMatchResultTo()` to improve the matcher
|
||||
message:
|
||||
```
|
||||
// Old matcher definition that doesn't work with the lastest
|
||||
// Google Mock.
|
||||
using ::testing::MatcherInterface;
|
||||
...
|
||||
class MyWonderfulMatcher : public MatcherInterface<MyType> {
|
||||
public:
|
||||
...
|
||||
virtual bool Matches(MyType value) const {
|
||||
// Returns true if value matches.
|
||||
return value.GetFoo() > 5;
|
||||
}
|
||||
|
||||
virtual void ExplainMatchResultTo(MyType value,
|
||||
::std::ostream* os) const {
|
||||
// Prints some helpful information to os to help
|
||||
// a user understand why value matches (or doesn't match).
|
||||
*os << "the Foo property is " << value.GetFoo();
|
||||
}
|
||||
...
|
||||
};
|
||||
```
|
||||
|
||||
you should move the logic of `ExplainMatchResultTo()` into
|
||||
`MatchAndExplain()`, using the `MatchResultListener` argument where
|
||||
the `::std::ostream` was used:
|
||||
```
|
||||
// New matcher definition that works with the latest Google Mock.
|
||||
using ::testing::MatcherInterface;
|
||||
using ::testing::MatchResultListener;
|
||||
...
|
||||
class MyWonderfulMatcher : public MatcherInterface<MyType> {
|
||||
public:
|
||||
...
|
||||
virtual bool MatchAndExplain(MyType value,
|
||||
MatchResultListener* listener) const {
|
||||
// Returns true if value matches.
|
||||
*listener << "the Foo property is " << value.GetFoo();
|
||||
return value.GetFoo() > 5;
|
||||
}
|
||||
...
|
||||
};
|
||||
```
|
||||
|
||||
If your matcher is defined using `MakePolymorphicMatcher()`:
|
||||
```
|
||||
// Old matcher definition that doesn't work with the latest
|
||||
// Google Mock.
|
||||
using ::testing::MakePolymorphicMatcher;
|
||||
...
|
||||
class MyGreatMatcher {
|
||||
public:
|
||||
...
|
||||
bool Matches(MyType value) const {
|
||||
// Returns true if value matches.
|
||||
return value.GetBar() < 42;
|
||||
}
|
||||
...
|
||||
};
|
||||
... MakePolymorphicMatcher(MyGreatMatcher()) ...
|
||||
```
|
||||
|
||||
you should rename the `Matches()` method to `MatchAndExplain()` and
|
||||
add a `MatchResultListener*` argument (the same as what you need to do
|
||||
for matchers defined by implementing `MatcherInterface`):
|
||||
```
|
||||
// New matcher definition that works with the latest Google Mock.
|
||||
using ::testing::MakePolymorphicMatcher;
|
||||
using ::testing::MatchResultListener;
|
||||
...
|
||||
class MyGreatMatcher {
|
||||
public:
|
||||
...
|
||||
bool MatchAndExplain(MyType value,
|
||||
MatchResultListener* listener) const {
|
||||
// Returns true if value matches.
|
||||
return value.GetBar() < 42;
|
||||
}
|
||||
...
|
||||
};
|
||||
... MakePolymorphicMatcher(MyGreatMatcher()) ...
|
||||
```
|
||||
|
||||
If your polymorphic matcher uses `ExplainMatchResultTo()` for better
|
||||
failure messages:
|
||||
```
|
||||
// Old matcher definition that doesn't work with the latest
|
||||
// Google Mock.
|
||||
using ::testing::MakePolymorphicMatcher;
|
||||
...
|
||||
class MyGreatMatcher {
|
||||
public:
|
||||
...
|
||||
bool Matches(MyType value) const {
|
||||
// Returns true if value matches.
|
||||
return value.GetBar() < 42;
|
||||
}
|
||||
...
|
||||
};
|
||||
void ExplainMatchResultTo(const MyGreatMatcher& matcher,
|
||||
MyType value,
|
||||
::std::ostream* os) {
|
||||
// Prints some helpful information to os to help
|
||||
// a user understand why value matches (or doesn't match).
|
||||
*os << "the Bar property is " << value.GetBar();
|
||||
}
|
||||
... MakePolymorphicMatcher(MyGreatMatcher()) ...
|
||||
```
|
||||
|
||||
you'll need to move the logic inside `ExplainMatchResultTo()` to
|
||||
`MatchAndExplain()`:
|
||||
```
|
||||
// New matcher definition that works with the latest Google Mock.
|
||||
using ::testing::MakePolymorphicMatcher;
|
||||
using ::testing::MatchResultListener;
|
||||
...
|
||||
class MyGreatMatcher {
|
||||
public:
|
||||
...
|
||||
bool MatchAndExplain(MyType value,
|
||||
MatchResultListener* listener) const {
|
||||
// Returns true if value matches.
|
||||
*listener << "the Bar property is " << value.GetBar();
|
||||
return value.GetBar() < 42;
|
||||
}
|
||||
...
|
||||
};
|
||||
... MakePolymorphicMatcher(MyGreatMatcher()) ...
|
||||
```
|
||||
|
||||
For more information, you can read these
|
||||
[two](http://code.google.com/p/googlemock/wiki/V1_7_CookBook#Writing_New_Monomorphic_Matchers)
|
||||
[recipes](http://code.google.com/p/googlemock/wiki/V1_7_CookBook#Writing_New_Polymorphic_Matchers)
|
||||
from the cookbook. As always, you
|
||||
are welcome to post questions on `googlemock@googlegroups.com` if you
|
||||
need any help.
|
||||
|
||||
## When using Google Mock, do I have to use Google Test as the testing framework? I have my favorite testing framework and don't want to switch. ##
|
||||
|
||||
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/V1_7_ForDummies#Using_Google_Mock_with_Any_Testing_Framework) is how.
|
||||
|
||||
## How am I supposed to make sense of these horrible template errors? ##
|
||||
|
||||
If you are confused by the compiler errors gcc threw at you,
|
||||
try consulting the _Google Mock Doctor_ tool first. What it does is to
|
||||
scan stdin for gcc error messages, and spit out diagnoses on the
|
||||
problems (we call them diseases) your code has.
|
||||
|
||||
To "install", run command:
|
||||
```
|
||||
alias gmd='<path to googlemock>/scripts/gmock_doctor.py'
|
||||
```
|
||||
|
||||
To use it, do:
|
||||
```
|
||||
<your-favorite-build-command> <your-test> 2>&1 | gmd
|
||||
```
|
||||
|
||||
For example:
|
||||
```
|
||||
make my_test 2>&1 | gmd
|
||||
```
|
||||
|
||||
Or you can run `gmd` and copy-n-paste gcc's error messages to it.
|
||||
|
||||
## Can I mock a variadic function? ##
|
||||
|
||||
You cannot mock a variadic function (i.e. a function taking ellipsis
|
||||
(`...`) arguments) directly in Google Mock.
|
||||
|
||||
The problem is that in general, there is _no way_ for a mock object to
|
||||
know how many arguments are passed to the variadic method, and what
|
||||
the arguments' types are. Only the _author of the base class_ knows
|
||||
the protocol, and we cannot look into his head.
|
||||
|
||||
Therefore, to mock such a function, the _user_ must teach the mock
|
||||
object how to figure out the number of arguments and their types. One
|
||||
way to do it is to provide overloaded versions of the function.
|
||||
|
||||
Ellipsis arguments are inherited from C and not really a C++ feature.
|
||||
They are unsafe to use and don't work with arguments that have
|
||||
constructors or destructors. Therefore we recommend to avoid them in
|
||||
C++ as much as possible.
|
||||
|
||||
## MSVC gives me warning C4301 or C4373 when I define a mock method with a const parameter. Why? ##
|
||||
|
||||
If you compile this using Microsoft Visual C++ 2005 SP1:
|
||||
```
|
||||
class Foo {
|
||||
...
|
||||
virtual void Bar(const int i) = 0;
|
||||
};
|
||||
|
||||
class MockFoo : public Foo {
|
||||
...
|
||||
MOCK_METHOD1(Bar, void(const int i));
|
||||
};
|
||||
```
|
||||
You may get the following warning:
|
||||
```
|
||||
warning C4301: 'MockFoo::Bar': overriding virtual function only differs from 'Foo::Bar' by const/volatile qualifier
|
||||
```
|
||||
|
||||
This is a MSVC bug. The same code compiles fine with gcc ,for
|
||||
example. If you use Visual C++ 2008 SP1, you would get the warning:
|
||||
```
|
||||
warning C4373: 'MockFoo::Bar': virtual function overrides 'Foo::Bar', previous versions of the compiler did not override when parameters only differed by const/volatile qualifiers
|
||||
```
|
||||
|
||||
In C++, if you _declare_ a function with a `const` parameter, the
|
||||
`const` modifier is _ignored_. Therefore, the `Foo` base class above
|
||||
is equivalent to:
|
||||
```
|
||||
class Foo {
|
||||
...
|
||||
virtual void Bar(int i) = 0; // int or const int? Makes no difference.
|
||||
};
|
||||
```
|
||||
|
||||
In fact, you can _declare_ Bar() with an `int` parameter, and _define_
|
||||
it with a `const int` parameter. The compiler will still match them
|
||||
up.
|
||||
|
||||
Since making a parameter `const` is meaningless in the method
|
||||
_declaration_, we recommend to remove it in both `Foo` and `MockFoo`.
|
||||
That should workaround the VC bug.
|
||||
|
||||
Note that we are talking about the _top-level_ `const` modifier here.
|
||||
If the function parameter is passed by pointer or reference, declaring
|
||||
the _pointee_ or _referee_ as `const` is still meaningful. For
|
||||
example, the following two declarations are _not_ equivalent:
|
||||
```
|
||||
void Bar(int* p); // Neither p nor *p is const.
|
||||
void Bar(const int* p); // p is not const, but *p is.
|
||||
```
|
||||
|
||||
## I have a huge mock class, and Microsoft Visual C++ runs out of memory when compiling it. What can I do? ##
|
||||
|
||||
We've noticed that when the `/clr` compiler flag is used, Visual C++
|
||||
uses 5~6 times as much memory when compiling a mock class. We suggest
|
||||
to avoid `/clr` when compiling native C++ mocks.
|
||||
|
||||
## I can't figure out why Google Mock thinks my expectations are not satisfied. What should I do? ##
|
||||
|
||||
You might want to run your test with
|
||||
`--gmock_verbose=info`. This flag lets Google Mock print a trace
|
||||
of every mock function call it receives. By studying the trace,
|
||||
you'll gain insights on why the expectations you set are not met.
|
||||
|
||||
## How can I assert that a function is NEVER called? ##
|
||||
|
||||
```
|
||||
EXPECT_CALL(foo, Bar(_))
|
||||
.Times(0);
|
||||
```
|
||||
|
||||
## I have a failed test where Google Mock tells me TWICE that a particular expectation is not satisfied. Isn't this redundant? ##
|
||||
|
||||
When Google Mock detects a failure, it prints relevant information
|
||||
(the mock function arguments, the state of relevant expectations, and
|
||||
etc) to help the user debug. If another failure is detected, Google
|
||||
Mock will do the same, including printing the state of relevant
|
||||
expectations.
|
||||
|
||||
Sometimes an expectation's state didn't change between two failures,
|
||||
and you'll see the same description of the state twice. They are
|
||||
however _not_ redundant, as they refer to _different points in time_.
|
||||
The fact they are the same _is_ interesting information.
|
||||
|
||||
## I get a heap check failure when using a mock object, but using a real object is fine. What can be wrong? ##
|
||||
|
||||
Does the class (hopefully a pure interface) you are mocking have a
|
||||
virtual destructor?
|
||||
|
||||
Whenever you derive from a base class, make sure its destructor is
|
||||
virtual. Otherwise Bad Things will happen. Consider the following
|
||||
code:
|
||||
|
||||
```
|
||||
class Base {
|
||||
public:
|
||||
// Not virtual, but should be.
|
||||
~Base() { ... }
|
||||
...
|
||||
};
|
||||
|
||||
class Derived : public Base {
|
||||
public:
|
||||
...
|
||||
private:
|
||||
std::string value_;
|
||||
};
|
||||
|
||||
...
|
||||
Base* p = new Derived;
|
||||
...
|
||||
delete p; // Surprise! ~Base() will be called, but ~Derived() will not
|
||||
// - value_ is leaked.
|
||||
```
|
||||
|
||||
By changing `~Base()` to virtual, `~Derived()` will be correctly
|
||||
called when `delete p` is executed, and the heap checker
|
||||
will be happy.
|
||||
|
||||
## The "newer expectations override older ones" rule makes writing expectations awkward. Why does Google Mock do that? ##
|
||||
|
||||
When people complain about this, often they are referring to code like:
|
||||
|
||||
```
|
||||
// foo.Bar() should be called twice, return 1 the first time, and return
|
||||
// 2 the second time. However, I have to write the expectations in the
|
||||
// reverse order. This sucks big time!!!
|
||||
EXPECT_CALL(foo, Bar())
|
||||
.WillOnce(Return(2))
|
||||
.RetiresOnSaturation();
|
||||
EXPECT_CALL(foo, Bar())
|
||||
.WillOnce(Return(1))
|
||||
.RetiresOnSaturation();
|
||||
```
|
||||
|
||||
The problem is that they didn't pick the **best** way to express the test's
|
||||
intent.
|
||||
|
||||
By default, expectations don't have to be matched in _any_ particular
|
||||
order. If you want them to match in a certain order, you need to be
|
||||
explicit. This is Google Mock's (and jMock's) fundamental philosophy: it's
|
||||
easy to accidentally over-specify your tests, and we want to make it
|
||||
harder to do so.
|
||||
|
||||
There are two better ways to write the test spec. You could either
|
||||
put the expectations in sequence:
|
||||
|
||||
```
|
||||
// foo.Bar() should be called twice, return 1 the first time, and return
|
||||
// 2 the second time. Using a sequence, we can write the expectations
|
||||
// in their natural order.
|
||||
{
|
||||
InSequence s;
|
||||
EXPECT_CALL(foo, Bar())
|
||||
.WillOnce(Return(1))
|
||||
.RetiresOnSaturation();
|
||||
EXPECT_CALL(foo, Bar())
|
||||
.WillOnce(Return(2))
|
||||
.RetiresOnSaturation();
|
||||
}
|
||||
```
|
||||
|
||||
or you can put the sequence of actions in the same expectation:
|
||||
|
||||
```
|
||||
// foo.Bar() should be called twice, return 1 the first time, and return
|
||||
// 2 the second time.
|
||||
EXPECT_CALL(foo, Bar())
|
||||
.WillOnce(Return(1))
|
||||
.WillOnce(Return(2))
|
||||
.RetiresOnSaturation();
|
||||
```
|
||||
|
||||
Back to the original questions: why does Google Mock search the
|
||||
expectations (and `ON_CALL`s) from back to front? Because this
|
||||
allows a user to set up a mock's behavior for the common case early
|
||||
(e.g. in the mock's constructor or the test fixture's set-up phase)
|
||||
and customize it with more specific rules later. If Google Mock
|
||||
searches from front to back, this very useful pattern won't be
|
||||
possible.
|
||||
|
||||
## Google Mock prints a warning when a function without EXPECT\_CALL is called, even if I have set its behavior using ON\_CALL. Would it be reasonable not to show the warning in this case? ##
|
||||
|
||||
When choosing between being neat and being safe, we lean toward the
|
||||
latter. So the answer is that we think it's better to show the
|
||||
warning.
|
||||
|
||||
Often people write `ON_CALL`s in the mock object's
|
||||
constructor or `SetUp()`, as the default behavior rarely changes from
|
||||
test to test. Then in the test body they set the expectations, which
|
||||
are often different for each test. Having an `ON_CALL` in the set-up
|
||||
part of a test doesn't mean that the calls are expected. If there's
|
||||
no `EXPECT_CALL` and the method is called, it's possibly an error. If
|
||||
we quietly let the call go through without notifying the user, bugs
|
||||
may creep in unnoticed.
|
||||
|
||||
If, however, you are sure that the calls are OK, you can write
|
||||
|
||||
```
|
||||
EXPECT_CALL(foo, Bar(_))
|
||||
.WillRepeatedly(...);
|
||||
```
|
||||
|
||||
instead of
|
||||
|
||||
```
|
||||
ON_CALL(foo, Bar(_))
|
||||
.WillByDefault(...);
|
||||
```
|
||||
|
||||
This tells Google Mock that you do expect the calls and no warning should be
|
||||
printed.
|
||||
|
||||
Also, you can control the verbosity using the `--gmock_verbose` flag.
|
||||
If you find the output too noisy when debugging, just choose a less
|
||||
verbose level.
|
||||
|
||||
## How can I delete the mock function's argument in an action? ##
|
||||
|
||||
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/V1_7_CookBook#Writing_New_Actions) or
|
||||
[MakePolymorphicAction()](http://code.google.com/p/googlemock/wiki/V1_7_CookBook#Writing_New_Polymorphic_Actions),
|
||||
or you can write a stub function and invoke it using
|
||||
[Invoke()](http://code.google.com/p/googlemock/wiki/V1_7_CookBook#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? ##
|
||||
|
||||
What?! I think it's beautiful. :-)
|
||||
|
||||
While which syntax looks more natural is a subjective matter to some
|
||||
extent, Google Mock's syntax was chosen for several practical advantages it
|
||||
has.
|
||||
|
||||
Try to mock a function that takes a map as an argument:
|
||||
```
|
||||
virtual int GetSize(const map<int, std::string>& m);
|
||||
```
|
||||
|
||||
Using the proposed syntax, it would be:
|
||||
```
|
||||
MOCK_METHOD1(GetSize, int, const map<int, std::string>& m);
|
||||
```
|
||||
|
||||
Guess what? You'll get a compiler error as the compiler thinks that
|
||||
`const map<int, std::string>& m` are **two**, not one, arguments. To work
|
||||
around this you can use `typedef` to give the map type a name, but
|
||||
that gets in the way of your work. Google Mock's syntax avoids this
|
||||
problem as the function's argument types are protected inside a pair
|
||||
of parentheses:
|
||||
```
|
||||
// This compiles fine.
|
||||
MOCK_METHOD1(GetSize, int(const map<int, std::string>& m));
|
||||
```
|
||||
|
||||
You still need a `typedef` if the return type contains an unprotected
|
||||
comma, but that's much rarer.
|
||||
|
||||
Other advantages include:
|
||||
1. `MOCK_METHOD1(Foo, int, bool)` can leave a reader wonder whether the method returns `int` or `bool`, while there won't be such confusion using Google Mock's syntax.
|
||||
1. The way Google Mock describes a function type is nothing new, although many people may not be familiar with it. The same syntax was used in C, and the `function` library in `tr1` uses this syntax extensively. Since `tr1` will become a part of the new version of STL, we feel very comfortable to be consistent with it.
|
||||
1. The function type syntax is also used in other parts of Google Mock's API (e.g. the action interface) in order to make the implementation tractable. A user needs to learn it anyway in order to utilize Google Mock's more advanced features. We'd as well stick to the same syntax in `MOCK_METHOD*`!
|
||||
|
||||
## My code calls a static/global function. Can I mock it? ##
|
||||
|
||||
You can, but you need to make some changes.
|
||||
|
||||
In general, if you find yourself needing to mock a static function,
|
||||
it's a sign that your modules are too tightly coupled (and less
|
||||
flexible, less reusable, less testable, etc). You are probably better
|
||||
off defining a small interface and call the function through that
|
||||
interface, which then can be easily mocked. It's a bit of work
|
||||
initially, but usually pays for itself quickly.
|
||||
|
||||
This Google Testing Blog
|
||||
[post](http://googletesting.blogspot.com/2008/06/defeat-static-cling.html)
|
||||
says it excellently. Check it out.
|
||||
|
||||
## My mock object needs to do complex stuff. It's a lot of pain to specify the actions. Google Mock sucks! ##
|
||||
|
||||
I know it's not a question, but you get an answer for free any way. :-)
|
||||
|
||||
With Google Mock, you can create mocks in C++ easily. And people might be
|
||||
tempted to use them everywhere. Sometimes they work great, and
|
||||
sometimes you may find them, well, a pain to use. So, what's wrong in
|
||||
the latter case?
|
||||
|
||||
When you write a test without using mocks, you exercise the code and
|
||||
assert that it returns the correct value or that the system is in an
|
||||
expected state. This is sometimes called "state-based testing".
|
||||
|
||||
Mocks are great for what some call "interaction-based" testing:
|
||||
instead of checking the system state at the very end, mock objects
|
||||
verify that they are invoked the right way and report an error as soon
|
||||
as it arises, giving you a handle on the precise context in which the
|
||||
error was triggered. This is often more effective and economical to
|
||||
do than state-based testing.
|
||||
|
||||
If you are doing state-based testing and using a test double just to
|
||||
simulate the real object, you are probably better off using a fake.
|
||||
Using a mock in this case causes pain, as it's not a strong point for
|
||||
mocks to perform complex actions. If you experience this and think
|
||||
that mocks suck, you are just not using the right tool for your
|
||||
problem. Or, you might be trying to solve the wrong problem. :-)
|
||||
|
||||
## I got a warning "Uninteresting function call encountered - default action taken.." Should I panic? ##
|
||||
|
||||
By all means, NO! It's just an FYI.
|
||||
|
||||
What it means is that you have a mock function, you haven't set any
|
||||
expectations on it (by Google Mock's rule this means that you are not
|
||||
interested in calls to this function and therefore it can be called
|
||||
any number of times), and it is called. That's OK - you didn't say
|
||||
it's not OK to call the function!
|
||||
|
||||
What if you actually meant to disallow this function to be called, but
|
||||
forgot to write `EXPECT_CALL(foo, Bar()).Times(0)`? While
|
||||
one can argue that it's the user's fault, Google Mock tries to be nice and
|
||||
prints you a note.
|
||||
|
||||
So, when you see the message and believe that there shouldn't be any
|
||||
uninteresting calls, you should investigate what's going on. To make
|
||||
your life easier, Google Mock prints the function name and arguments
|
||||
when an uninteresting call is encountered.
|
||||
|
||||
## I want to define a custom action. Should I use Invoke() or implement the action interface? ##
|
||||
|
||||
Either way is fine - you want to choose the one that's more convenient
|
||||
for your circumstance.
|
||||
|
||||
Usually, if your action is for a particular function type, defining it
|
||||
using `Invoke()` should be easier; if your action can be used in
|
||||
functions of different types (e.g. if you are defining
|
||||
`Return(value)`), `MakePolymorphicAction()` is
|
||||
easiest. Sometimes you want precise control on what types of
|
||||
functions the action can be used in, and implementing
|
||||
`ActionInterface` is the way to go here. See the implementation of
|
||||
`Return()` in `include/gmock/gmock-actions.h` for an example.
|
||||
|
||||
## I'm using the set-argument-pointee action, and the compiler complains about "conflicting return type specified". What does it mean? ##
|
||||
|
||||
You got this error as Google Mock has no idea what value it should return
|
||||
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/V1_7_CookBook#Mocking_Side_Effects) for more details and an example.
|
||||
|
||||
|
||||
## My question is not 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/googlemock/w/list),
|
||||
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_
|
||||
a good way to get your answer, as it is monitored infrequently by a
|
||||
very small number of people.
|
||||
|
||||
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 Mock you use (Google Mock 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.
|
||||
@@ -46,6 +46,10 @@
|
||||
#include "gmock/internal/gmock-internal-utils.h"
|
||||
#include "gmock/internal/gmock-port.h"
|
||||
|
||||
#if GTEST_HAS_STD_TYPE_TRAITS_ // Defined by gtest-port.h via gmock-port.h.
|
||||
#include <type_traits>
|
||||
#endif
|
||||
|
||||
namespace testing {
|
||||
|
||||
// To implement an action Foo, define:
|
||||
@@ -62,16 +66,17 @@ namespace internal {
|
||||
template <typename F1, typename F2>
|
||||
class ActionAdaptor;
|
||||
|
||||
// BuiltInDefaultValue<T>::Get() returns the "built-in" default
|
||||
// value for type T, which is NULL when T is a pointer type, 0 when T
|
||||
// is a numeric type, false when T is bool, or "" when T is string or
|
||||
// std::string. For any other type T, this value is undefined and the
|
||||
// function will abort the process.
|
||||
// BuiltInDefaultValueGetter<T, true>::Get() returns a
|
||||
// default-constructed T value. BuiltInDefaultValueGetter<T,
|
||||
// false>::Get() crashes with an error.
|
||||
//
|
||||
// This primary template is used when kDefaultConstructible is true.
|
||||
template <typename T, bool kDefaultConstructible>
|
||||
struct BuiltInDefaultValueGetter {
|
||||
static T Get() { return T(); }
|
||||
};
|
||||
template <typename T>
|
||||
class BuiltInDefaultValue {
|
||||
public:
|
||||
// This function returns true iff type T has a built-in default value.
|
||||
static bool Exists() { return false; }
|
||||
struct BuiltInDefaultValueGetter<T, false> {
|
||||
static T Get() {
|
||||
Assert(false, __FILE__, __LINE__,
|
||||
"Default action undefined for the function return type.");
|
||||
@@ -81,6 +86,40 @@ class BuiltInDefaultValue {
|
||||
}
|
||||
};
|
||||
|
||||
// BuiltInDefaultValue<T>::Get() returns the "built-in" default value
|
||||
// for type T, which is NULL when T is a raw pointer type, 0 when T is
|
||||
// a numeric type, false when T is bool, or "" when T is string or
|
||||
// std::string. In addition, in C++11 and above, it turns a
|
||||
// default-constructed T value if T is default constructible. For any
|
||||
// other type T, the built-in default T value is undefined, and the
|
||||
// function will abort the process.
|
||||
template <typename T>
|
||||
class BuiltInDefaultValue {
|
||||
public:
|
||||
#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;
|
||||
}
|
||||
|
||||
static T Get() {
|
||||
return BuiltInDefaultValueGetter<
|
||||
T, ::std::is_default_constructible<T>::value>::Get();
|
||||
}
|
||||
|
||||
#else // GTEST_HAS_STD_TYPE_TRAITS_
|
||||
// This function returns true iff type T has a built-in default value.
|
||||
static bool Exists() {
|
||||
return false;
|
||||
}
|
||||
|
||||
static T Get() {
|
||||
return BuiltInDefaultValueGetter<T, false>::Get();
|
||||
}
|
||||
|
||||
#endif // GTEST_HAS_STD_TYPE_TRAITS_
|
||||
};
|
||||
|
||||
// This partial specialization says that we use the same built-in
|
||||
// default value for T and const T.
|
||||
template <typename T>
|
||||
@@ -163,18 +202,27 @@ class DefaultValue {
|
||||
// Sets the default value for type T; requires T to be
|
||||
// copy-constructable and have a public destructor.
|
||||
static void Set(T x) {
|
||||
delete value_;
|
||||
value_ = new T(x);
|
||||
delete producer_;
|
||||
producer_ = new FixedValueProducer(x);
|
||||
}
|
||||
|
||||
// Provides a factory function to be called to generate the default value.
|
||||
// This method can be used even if T is only move-constructible, but it is not
|
||||
// limited to that case.
|
||||
typedef T (*FactoryFunction)();
|
||||
static void SetFactory(FactoryFunction factory) {
|
||||
delete producer_;
|
||||
producer_ = new FactoryValueProducer(factory);
|
||||
}
|
||||
|
||||
// Unsets the default value for type T.
|
||||
static void Clear() {
|
||||
delete value_;
|
||||
value_ = NULL;
|
||||
delete producer_;
|
||||
producer_ = NULL;
|
||||
}
|
||||
|
||||
// Returns true iff the user has set the default value for type T.
|
||||
static bool IsSet() { return value_ != NULL; }
|
||||
static bool IsSet() { return producer_ != NULL; }
|
||||
|
||||
// Returns true if T has a default return value set by the user or there
|
||||
// exists a built-in default value.
|
||||
@@ -183,15 +231,42 @@ class DefaultValue {
|
||||
}
|
||||
|
||||
// Returns the default value for type T if the user has set one;
|
||||
// otherwise returns the built-in default value if there is one;
|
||||
// otherwise aborts the process.
|
||||
// otherwise returns the built-in default value. Requires that Exists()
|
||||
// is true, which ensures that the return value is well-defined.
|
||||
static T Get() {
|
||||
return value_ == NULL ?
|
||||
internal::BuiltInDefaultValue<T>::Get() : *value_;
|
||||
return producer_ == NULL ?
|
||||
internal::BuiltInDefaultValue<T>::Get() : producer_->Produce();
|
||||
}
|
||||
|
||||
private:
|
||||
static const T* value_;
|
||||
class ValueProducer {
|
||||
public:
|
||||
virtual ~ValueProducer() {}
|
||||
virtual T Produce() = 0;
|
||||
};
|
||||
|
||||
class FixedValueProducer : public ValueProducer {
|
||||
public:
|
||||
explicit FixedValueProducer(T value) : value_(value) {}
|
||||
virtual T Produce() { return value_; }
|
||||
|
||||
private:
|
||||
const T value_;
|
||||
GTEST_DISALLOW_COPY_AND_ASSIGN_(FixedValueProducer);
|
||||
};
|
||||
|
||||
class FactoryValueProducer : public ValueProducer {
|
||||
public:
|
||||
explicit FactoryValueProducer(FactoryFunction factory)
|
||||
: factory_(factory) {}
|
||||
virtual T Produce() { return factory_(); }
|
||||
|
||||
private:
|
||||
const FactoryFunction factory_;
|
||||
GTEST_DISALLOW_COPY_AND_ASSIGN_(FactoryValueProducer);
|
||||
};
|
||||
|
||||
static ValueProducer* producer_;
|
||||
};
|
||||
|
||||
// This partial specialization allows a user to set default values for
|
||||
@@ -241,7 +316,7 @@ class DefaultValue<void> {
|
||||
|
||||
// Points to the user-set default value for type T.
|
||||
template <typename T>
|
||||
const T* DefaultValue<T>::value_ = NULL;
|
||||
typename DefaultValue<T>::ValueProducer* DefaultValue<T>::producer_ = NULL;
|
||||
|
||||
// Points to the user-set default value for type T&.
|
||||
template <typename T>
|
||||
@@ -423,6 +498,14 @@ class ActionAdaptor : public ActionInterface<F1> {
|
||||
GTEST_DISALLOW_ASSIGN_(ActionAdaptor);
|
||||
};
|
||||
|
||||
// Helper struct to specialize ReturnAction to execute a move instead of a copy
|
||||
// on return. Useful for move-only types, but could be used on any type.
|
||||
template <typename T>
|
||||
struct ByMoveWrapper {
|
||||
explicit ByMoveWrapper(T value) : payload(internal::move(value)) {}
|
||||
T payload;
|
||||
};
|
||||
|
||||
// Implements the polymorphic Return(x) action, which can be used in
|
||||
// any function that returns the type of x, regardless of the argument
|
||||
// types.
|
||||
@@ -453,7 +536,7 @@ class ReturnAction {
|
||||
// Constructs a ReturnAction object from the value to be returned.
|
||||
// 'value' is passed by value instead of by const reference in order
|
||||
// to allow Return("string literal") to compile.
|
||||
explicit ReturnAction(R value) : value_(value) {}
|
||||
explicit ReturnAction(R value) : value_(new R(internal::move(value))) {}
|
||||
|
||||
// This template type conversion operator allows Return(x) to be
|
||||
// used in ANY function that returns x's type.
|
||||
@@ -469,14 +552,14 @@ class ReturnAction {
|
||||
// in the Impl class. But both definitions must be the same.
|
||||
typedef typename Function<F>::Result Result;
|
||||
GTEST_COMPILE_ASSERT_(
|
||||
!internal::is_reference<Result>::value,
|
||||
!is_reference<Result>::value,
|
||||
use_ReturnRef_instead_of_Return_to_return_a_reference);
|
||||
return Action<F>(new Impl<F>(value_));
|
||||
return Action<F>(new Impl<R, F>(value_));
|
||||
}
|
||||
|
||||
private:
|
||||
// Implements the Return(x) action for a particular function type F.
|
||||
template <typename F>
|
||||
template <typename R_, typename F>
|
||||
class Impl : public ActionInterface<F> {
|
||||
public:
|
||||
typedef typename Function<F>::Result Result;
|
||||
@@ -489,20 +572,49 @@ class ReturnAction {
|
||||
// Result to call. ImplicitCast_ forces the compiler to convert R to
|
||||
// Result without considering explicit constructors, thus resolving the
|
||||
// ambiguity. value_ is then initialized using its copy constructor.
|
||||
explicit Impl(R value)
|
||||
: value_(::testing::internal::ImplicitCast_<Result>(value)) {}
|
||||
explicit Impl(const linked_ptr<R>& value)
|
||||
: value_before_cast_(*value),
|
||||
value_(ImplicitCast_<Result>(value_before_cast_)) {}
|
||||
|
||||
virtual Result Perform(const ArgumentTuple&) { return value_; }
|
||||
|
||||
private:
|
||||
GTEST_COMPILE_ASSERT_(!internal::is_reference<Result>::value,
|
||||
GTEST_COMPILE_ASSERT_(!is_reference<Result>::value,
|
||||
Result_cannot_be_a_reference_type);
|
||||
// We save the value before casting just in case it is being cast to a
|
||||
// wrapper type.
|
||||
R value_before_cast_;
|
||||
Result value_;
|
||||
|
||||
GTEST_DISALLOW_COPY_AND_ASSIGN_(Impl);
|
||||
};
|
||||
|
||||
// Partially specialize for ByMoveWrapper. This version of ReturnAction will
|
||||
// move its contents instead.
|
||||
template <typename R_, typename F>
|
||||
class Impl<ByMoveWrapper<R_>, F> : public ActionInterface<F> {
|
||||
public:
|
||||
typedef typename Function<F>::Result Result;
|
||||
typedef typename Function<F>::ArgumentTuple ArgumentTuple;
|
||||
|
||||
explicit Impl(const linked_ptr<R>& wrapper)
|
||||
: performed_(false), wrapper_(wrapper) {}
|
||||
|
||||
virtual Result Perform(const ArgumentTuple&) {
|
||||
GTEST_CHECK_(!performed_)
|
||||
<< "A ByMove() action should only be performed once.";
|
||||
performed_ = true;
|
||||
return internal::move(wrapper_->payload);
|
||||
}
|
||||
|
||||
private:
|
||||
bool performed_;
|
||||
const linked_ptr<R> wrapper_;
|
||||
|
||||
GTEST_DISALLOW_ASSIGN_(Impl);
|
||||
};
|
||||
|
||||
R value_;
|
||||
const linked_ptr<R> value_;
|
||||
|
||||
GTEST_DISALLOW_ASSIGN_(ReturnAction);
|
||||
};
|
||||
@@ -510,12 +622,18 @@ class ReturnAction {
|
||||
// Implements the ReturnNull() action.
|
||||
class ReturnNullAction {
|
||||
public:
|
||||
// Allows ReturnNull() to be used in any pointer-returning function.
|
||||
// Allows ReturnNull() to be used in any pointer-returning function. In C++11
|
||||
// this is enforced by returning nullptr, and in non-C++11 by asserting a
|
||||
// pointer type on compile time.
|
||||
template <typename Result, typename ArgumentTuple>
|
||||
static Result Perform(const ArgumentTuple&) {
|
||||
#if GTEST_LANG_CXX11
|
||||
return nullptr;
|
||||
#else
|
||||
GTEST_COMPILE_ASSERT_(internal::is_pointer<Result>::value,
|
||||
ReturnNull_can_be_used_to_return_a_pointer_only);
|
||||
return NULL;
|
||||
#endif // GTEST_LANG_CXX11
|
||||
}
|
||||
};
|
||||
|
||||
@@ -692,7 +810,7 @@ class SetArgumentPointeeAction {
|
||||
template <typename Result, typename ArgumentTuple>
|
||||
void Perform(const ArgumentTuple& args) const {
|
||||
CompileAssertTypesEqual<void, Result>();
|
||||
*::std::tr1::get<N>(args) = value_;
|
||||
*::testing::get<N>(args) = value_;
|
||||
}
|
||||
|
||||
private:
|
||||
@@ -715,7 +833,7 @@ class SetArgumentPointeeAction<N, Proto, true> {
|
||||
template <typename Result, typename ArgumentTuple>
|
||||
void Perform(const ArgumentTuple& args) const {
|
||||
CompileAssertTypesEqual<void, Result>();
|
||||
::std::tr1::get<N>(args)->CopyFrom(*proto_);
|
||||
::testing::get<N>(args)->CopyFrom(*proto_);
|
||||
}
|
||||
|
||||
private:
|
||||
@@ -941,7 +1059,7 @@ Action<To>::Action(const Action<From>& from)
|
||||
// will trigger a compiler error about using array as initializer.
|
||||
template <typename R>
|
||||
internal::ReturnAction<R> Return(R value) {
|
||||
return internal::ReturnAction<R>(value);
|
||||
return internal::ReturnAction<R>(internal::move(value));
|
||||
}
|
||||
|
||||
// Creates an action that returns NULL.
|
||||
@@ -968,6 +1086,15 @@ inline internal::ReturnRefOfCopyAction<R> ReturnRefOfCopy(const R& x) {
|
||||
return internal::ReturnRefOfCopyAction<R>(x);
|
||||
}
|
||||
|
||||
// Modifies the parent action (a Return() action) to perform a move of the
|
||||
// argument instead of a copy.
|
||||
// Return(ByMove()) actions can only be executed once and will assert this
|
||||
// invariant.
|
||||
template <typename R>
|
||||
internal::ByMoveWrapper<R> ByMove(R x) {
|
||||
return internal::ByMoveWrapper<R>(internal::move(x));
|
||||
}
|
||||
|
||||
// Creates an action that does the default action for the give mock function.
|
||||
inline internal::DoDefaultAction DoDefault() {
|
||||
return internal::DoDefaultAction();
|
||||
@@ -51,356 +51,240 @@ template <typename Result, typename ArgumentTuple>
|
||||
class InvokeHelper;
|
||||
|
||||
template <typename R>
|
||||
class InvokeHelper<R, ::std::tr1::tuple<> > {
|
||||
class InvokeHelper<R, ::testing::tuple<> > {
|
||||
public:
|
||||
template <typename Function>
|
||||
static R Invoke(Function function, const ::std::tr1::tuple<>&) {
|
||||
return function();
|
||||
static R Invoke(Function function, const ::testing::tuple<>&) {
|
||||
return function();
|
||||
}
|
||||
|
||||
template <class Class, typename MethodPtr>
|
||||
static R InvokeMethod(Class* obj_ptr,
|
||||
MethodPtr method_ptr,
|
||||
const ::std::tr1::tuple<>&) {
|
||||
return (obj_ptr->*method_ptr)();
|
||||
const ::testing::tuple<>&) {
|
||||
return (obj_ptr->*method_ptr)();
|
||||
}
|
||||
};
|
||||
|
||||
template <typename R, typename A1>
|
||||
class InvokeHelper<R, ::std::tr1::tuple<A1> > {
|
||||
class InvokeHelper<R, ::testing::tuple<A1> > {
|
||||
public:
|
||||
template <typename Function>
|
||||
static R Invoke(Function function, const ::std::tr1::tuple<A1>& args) {
|
||||
using ::std::tr1::get;
|
||||
return function(get<0>(args));
|
||||
static R Invoke(Function function, const ::testing::tuple<A1>& args) {
|
||||
return function(get<0>(args));
|
||||
}
|
||||
|
||||
template <class Class, typename MethodPtr>
|
||||
static R InvokeMethod(Class* obj_ptr,
|
||||
MethodPtr method_ptr,
|
||||
const ::std::tr1::tuple<A1>& args) {
|
||||
using ::std::tr1::get;
|
||||
return (obj_ptr->*method_ptr)(get<0>(args));
|
||||
const ::testing::tuple<A1>& args) {
|
||||
return (obj_ptr->*method_ptr)(get<0>(args));
|
||||
}
|
||||
};
|
||||
|
||||
template <typename R, typename A1, typename A2>
|
||||
class InvokeHelper<R, ::std::tr1::tuple<A1, A2> > {
|
||||
class InvokeHelper<R, ::testing::tuple<A1, A2> > {
|
||||
public:
|
||||
template <typename Function>
|
||||
static R Invoke(Function function, const ::std::tr1::tuple<A1, A2>& args) {
|
||||
using ::std::tr1::get;
|
||||
return function(get<0>(args), get<1>(args));
|
||||
static R Invoke(Function function, const ::testing::tuple<A1, A2>& args) {
|
||||
return function(get<0>(args), get<1>(args));
|
||||
}
|
||||
|
||||
template <class Class, typename MethodPtr>
|
||||
static R InvokeMethod(Class* obj_ptr,
|
||||
MethodPtr method_ptr,
|
||||
const ::std::tr1::tuple<A1, A2>& args) {
|
||||
using ::std::tr1::get;
|
||||
return (obj_ptr->*method_ptr)(get<0>(args), get<1>(args));
|
||||
const ::testing::tuple<A1, A2>& args) {
|
||||
return (obj_ptr->*method_ptr)(get<0>(args), get<1>(args));
|
||||
}
|
||||
};
|
||||
|
||||
template <typename R, typename A1, typename A2, typename A3>
|
||||
class InvokeHelper<R, ::std::tr1::tuple<A1, A2, A3> > {
|
||||
class InvokeHelper<R, ::testing::tuple<A1, A2, A3> > {
|
||||
public:
|
||||
template <typename Function>
|
||||
static R Invoke(Function function, const ::std::tr1::tuple<A1, A2,
|
||||
A3>& args) {
|
||||
using ::std::tr1::get;
|
||||
return function(get<0>(args), get<1>(args), get<2>(args));
|
||||
static R Invoke(Function function, const ::testing::tuple<A1, A2, A3>& args) {
|
||||
return function(get<0>(args), get<1>(args), get<2>(args));
|
||||
}
|
||||
|
||||
template <class Class, typename MethodPtr>
|
||||
static R InvokeMethod(Class* obj_ptr,
|
||||
MethodPtr method_ptr,
|
||||
const ::std::tr1::tuple<A1, A2, A3>& args) {
|
||||
using ::std::tr1::get;
|
||||
return (obj_ptr->*method_ptr)(get<0>(args), get<1>(args), get<2>(args));
|
||||
const ::testing::tuple<A1, A2, A3>& args) {
|
||||
return (obj_ptr->*method_ptr)(get<0>(args), get<1>(args),
|
||||
get<2>(args));
|
||||
}
|
||||
};
|
||||
|
||||
template <typename R, typename A1, typename A2, typename A3, typename A4>
|
||||
class InvokeHelper<R, ::std::tr1::tuple<A1, A2, A3, A4> > {
|
||||
class InvokeHelper<R, ::testing::tuple<A1, A2, A3, A4> > {
|
||||
public:
|
||||
template <typename Function>
|
||||
static R Invoke(Function function, const ::std::tr1::tuple<A1, A2, A3,
|
||||
static R Invoke(Function function, const ::testing::tuple<A1, A2, A3,
|
||||
A4>& args) {
|
||||
using ::std::tr1::get;
|
||||
return function(get<0>(args), get<1>(args), get<2>(args), get<3>(args));
|
||||
return function(get<0>(args), get<1>(args), get<2>(args),
|
||||
get<3>(args));
|
||||
}
|
||||
|
||||
template <class Class, typename MethodPtr>
|
||||
static R InvokeMethod(Class* obj_ptr,
|
||||
MethodPtr method_ptr,
|
||||
const ::std::tr1::tuple<A1, A2, A3, A4>& args) {
|
||||
using ::std::tr1::get;
|
||||
return (obj_ptr->*method_ptr)(get<0>(args), get<1>(args), get<2>(args),
|
||||
get<3>(args));
|
||||
const ::testing::tuple<A1, A2, A3, A4>& args) {
|
||||
return (obj_ptr->*method_ptr)(get<0>(args), get<1>(args),
|
||||
get<2>(args), get<3>(args));
|
||||
}
|
||||
};
|
||||
|
||||
template <typename R, typename A1, typename A2, typename A3, typename A4,
|
||||
typename A5>
|
||||
class InvokeHelper<R, ::std::tr1::tuple<A1, A2, A3, A4, A5> > {
|
||||
class InvokeHelper<R, ::testing::tuple<A1, A2, A3, A4, A5> > {
|
||||
public:
|
||||
template <typename Function>
|
||||
static R Invoke(Function function, const ::std::tr1::tuple<A1, A2, A3, A4,
|
||||
static R Invoke(Function function, const ::testing::tuple<A1, A2, A3, A4,
|
||||
A5>& args) {
|
||||
using ::std::tr1::get;
|
||||
return function(get<0>(args), get<1>(args), get<2>(args), get<3>(args),
|
||||
get<4>(args));
|
||||
return function(get<0>(args), get<1>(args), get<2>(args),
|
||||
get<3>(args), get<4>(args));
|
||||
}
|
||||
|
||||
template <class Class, typename MethodPtr>
|
||||
static R InvokeMethod(Class* obj_ptr,
|
||||
MethodPtr method_ptr,
|
||||
const ::std::tr1::tuple<A1, A2, A3, A4, A5>& args) {
|
||||
using ::std::tr1::get;
|
||||
return (obj_ptr->*method_ptr)(get<0>(args), get<1>(args), get<2>(args),
|
||||
get<3>(args), get<4>(args));
|
||||
const ::testing::tuple<A1, A2, A3, A4, A5>& args) {
|
||||
return (obj_ptr->*method_ptr)(get<0>(args), get<1>(args),
|
||||
get<2>(args), get<3>(args), get<4>(args));
|
||||
}
|
||||
};
|
||||
|
||||
template <typename R, typename A1, typename A2, typename A3, typename A4,
|
||||
typename A5, typename A6>
|
||||
class InvokeHelper<R, ::std::tr1::tuple<A1, A2, A3, A4, A5, A6> > {
|
||||
class InvokeHelper<R, ::testing::tuple<A1, A2, A3, A4, A5, A6> > {
|
||||
public:
|
||||
template <typename Function>
|
||||
static R Invoke(Function function, const ::std::tr1::tuple<A1, A2, A3, A4,
|
||||
A5, A6>& args) {
|
||||
using ::std::tr1::get;
|
||||
return function(get<0>(args), get<1>(args), get<2>(args), get<3>(args),
|
||||
get<4>(args), get<5>(args));
|
||||
static R Invoke(Function function, const ::testing::tuple<A1, A2, A3, A4, A5,
|
||||
A6>& args) {
|
||||
return function(get<0>(args), get<1>(args), get<2>(args),
|
||||
get<3>(args), get<4>(args), get<5>(args));
|
||||
}
|
||||
|
||||
template <class Class, typename MethodPtr>
|
||||
static R InvokeMethod(Class* obj_ptr,
|
||||
MethodPtr method_ptr,
|
||||
const ::std::tr1::tuple<A1, A2, A3, A4, A5, A6>& args) {
|
||||
using ::std::tr1::get;
|
||||
return (obj_ptr->*method_ptr)(get<0>(args), get<1>(args), get<2>(args),
|
||||
get<3>(args), get<4>(args), get<5>(args));
|
||||
const ::testing::tuple<A1, A2, A3, A4, A5, A6>& args) {
|
||||
return (obj_ptr->*method_ptr)(get<0>(args), get<1>(args),
|
||||
get<2>(args), get<3>(args), get<4>(args), get<5>(args));
|
||||
}
|
||||
};
|
||||
|
||||
template <typename R, typename A1, typename A2, typename A3, typename A4,
|
||||
typename A5, typename A6, typename A7>
|
||||
class InvokeHelper<R, ::std::tr1::tuple<A1, A2, A3, A4, A5, A6, A7> > {
|
||||
class InvokeHelper<R, ::testing::tuple<A1, A2, A3, A4, A5, A6, A7> > {
|
||||
public:
|
||||
template <typename Function>
|
||||
static R Invoke(Function function, const ::std::tr1::tuple<A1, A2, A3, A4,
|
||||
A5, A6, A7>& args) {
|
||||
using ::std::tr1::get;
|
||||
return function(get<0>(args), get<1>(args), get<2>(args), get<3>(args),
|
||||
get<4>(args), get<5>(args), get<6>(args));
|
||||
static R Invoke(Function function, const ::testing::tuple<A1, A2, A3, A4, A5,
|
||||
A6, A7>& args) {
|
||||
return function(get<0>(args), get<1>(args), get<2>(args),
|
||||
get<3>(args), get<4>(args), get<5>(args), get<6>(args));
|
||||
}
|
||||
|
||||
template <class Class, typename MethodPtr>
|
||||
static R InvokeMethod(Class* obj_ptr,
|
||||
MethodPtr method_ptr,
|
||||
const ::std::tr1::tuple<A1, A2, A3, A4, A5, A6,
|
||||
const ::testing::tuple<A1, A2, A3, A4, A5, A6,
|
||||
A7>& args) {
|
||||
using ::std::tr1::get;
|
||||
return (obj_ptr->*method_ptr)(get<0>(args), get<1>(args), get<2>(args),
|
||||
get<3>(args), get<4>(args), get<5>(args), get<6>(args));
|
||||
return (obj_ptr->*method_ptr)(get<0>(args), get<1>(args),
|
||||
get<2>(args), get<3>(args), get<4>(args), get<5>(args),
|
||||
get<6>(args));
|
||||
}
|
||||
};
|
||||
|
||||
template <typename R, typename A1, typename A2, typename A3, typename A4,
|
||||
typename A5, typename A6, typename A7, typename A8>
|
||||
class InvokeHelper<R, ::std::tr1::tuple<A1, A2, A3, A4, A5, A6, A7, A8> > {
|
||||
class InvokeHelper<R, ::testing::tuple<A1, A2, A3, A4, A5, A6, A7, A8> > {
|
||||
public:
|
||||
template <typename Function>
|
||||
static R Invoke(Function function, const ::std::tr1::tuple<A1, A2, A3, A4,
|
||||
A5, A6, A7, A8>& args) {
|
||||
using ::std::tr1::get;
|
||||
return function(get<0>(args), get<1>(args), get<2>(args), get<3>(args),
|
||||
get<4>(args), get<5>(args), get<6>(args), get<7>(args));
|
||||
static R Invoke(Function function, const ::testing::tuple<A1, A2, A3, A4, A5,
|
||||
A6, A7, A8>& args) {
|
||||
return function(get<0>(args), get<1>(args), get<2>(args),
|
||||
get<3>(args), get<4>(args), get<5>(args), get<6>(args),
|
||||
get<7>(args));
|
||||
}
|
||||
|
||||
template <class Class, typename MethodPtr>
|
||||
static R InvokeMethod(Class* obj_ptr,
|
||||
MethodPtr method_ptr,
|
||||
const ::std::tr1::tuple<A1, A2, A3, A4, A5, A6, A7,
|
||||
const ::testing::tuple<A1, A2, A3, A4, A5, A6, A7,
|
||||
A8>& args) {
|
||||
using ::std::tr1::get;
|
||||
return (obj_ptr->*method_ptr)(get<0>(args), get<1>(args), get<2>(args),
|
||||
get<3>(args), get<4>(args), get<5>(args), get<6>(args), get<7>(args));
|
||||
return (obj_ptr->*method_ptr)(get<0>(args), get<1>(args),
|
||||
get<2>(args), get<3>(args), get<4>(args), get<5>(args),
|
||||
get<6>(args), get<7>(args));
|
||||
}
|
||||
};
|
||||
|
||||
template <typename R, typename A1, typename A2, typename A3, typename A4,
|
||||
typename A5, typename A6, typename A7, typename A8, typename A9>
|
||||
class InvokeHelper<R, ::std::tr1::tuple<A1, A2, A3, A4, A5, A6, A7, A8, A9> > {
|
||||
class InvokeHelper<R, ::testing::tuple<A1, A2, A3, A4, A5, A6, A7, A8, A9> > {
|
||||
public:
|
||||
template <typename Function>
|
||||
static R Invoke(Function function, const ::std::tr1::tuple<A1, A2, A3, A4,
|
||||
A5, A6, A7, A8, A9>& args) {
|
||||
using ::std::tr1::get;
|
||||
return function(get<0>(args), get<1>(args), get<2>(args), get<3>(args),
|
||||
get<4>(args), get<5>(args), get<6>(args), get<7>(args), get<8>(args));
|
||||
static R Invoke(Function function, const ::testing::tuple<A1, A2, A3, A4, A5,
|
||||
A6, A7, A8, A9>& args) {
|
||||
return function(get<0>(args), get<1>(args), get<2>(args),
|
||||
get<3>(args), get<4>(args), get<5>(args), get<6>(args),
|
||||
get<7>(args), get<8>(args));
|
||||
}
|
||||
|
||||
template <class Class, typename MethodPtr>
|
||||
static R InvokeMethod(Class* obj_ptr,
|
||||
MethodPtr method_ptr,
|
||||
const ::std::tr1::tuple<A1, A2, A3, A4, A5, A6, A7, A8,
|
||||
const ::testing::tuple<A1, A2, A3, A4, A5, A6, A7, A8,
|
||||
A9>& args) {
|
||||
using ::std::tr1::get;
|
||||
return (obj_ptr->*method_ptr)(get<0>(args), get<1>(args), get<2>(args),
|
||||
get<3>(args), get<4>(args), get<5>(args), get<6>(args), get<7>(args),
|
||||
get<8>(args));
|
||||
return (obj_ptr->*method_ptr)(get<0>(args), get<1>(args),
|
||||
get<2>(args), get<3>(args), get<4>(args), get<5>(args),
|
||||
get<6>(args), get<7>(args), get<8>(args));
|
||||
}
|
||||
};
|
||||
|
||||
template <typename R, typename A1, typename A2, typename A3, typename A4,
|
||||
typename A5, typename A6, typename A7, typename A8, typename A9,
|
||||
typename A10>
|
||||
class InvokeHelper<R, ::std::tr1::tuple<A1, A2, A3, A4, A5, A6, A7, A8, A9,
|
||||
class InvokeHelper<R, ::testing::tuple<A1, A2, A3, A4, A5, A6, A7, A8, A9,
|
||||
A10> > {
|
||||
public:
|
||||
template <typename Function>
|
||||
static R Invoke(Function function, const ::std::tr1::tuple<A1, A2, A3, A4,
|
||||
A5, A6, A7, A8, A9, A10>& args) {
|
||||
using ::std::tr1::get;
|
||||
return function(get<0>(args), get<1>(args), get<2>(args), get<3>(args),
|
||||
get<4>(args), get<5>(args), get<6>(args), get<7>(args), get<8>(args),
|
||||
get<9>(args));
|
||||
static R Invoke(Function function, const ::testing::tuple<A1, A2, A3, A4, A5,
|
||||
A6, A7, A8, A9, A10>& args) {
|
||||
return function(get<0>(args), get<1>(args), get<2>(args),
|
||||
get<3>(args), get<4>(args), get<5>(args), get<6>(args),
|
||||
get<7>(args), get<8>(args), get<9>(args));
|
||||
}
|
||||
|
||||
template <class Class, typename MethodPtr>
|
||||
static R InvokeMethod(Class* obj_ptr,
|
||||
MethodPtr method_ptr,
|
||||
const ::std::tr1::tuple<A1, A2, A3, A4, A5, A6, A7, A8,
|
||||
const ::testing::tuple<A1, A2, A3, A4, A5, A6, A7, A8,
|
||||
A9, A10>& args) {
|
||||
using ::std::tr1::get;
|
||||
return (obj_ptr->*method_ptr)(get<0>(args), get<1>(args), get<2>(args),
|
||||
get<3>(args), get<4>(args), get<5>(args), get<6>(args), get<7>(args),
|
||||
get<8>(args), get<9>(args));
|
||||
return (obj_ptr->*method_ptr)(get<0>(args), get<1>(args),
|
||||
get<2>(args), get<3>(args), get<4>(args), get<5>(args),
|
||||
get<6>(args), get<7>(args), get<8>(args), get<9>(args));
|
||||
}
|
||||
};
|
||||
|
||||
// CallableHelper has static methods for invoking "callables",
|
||||
// i.e. function pointers and functors. It uses overloading to
|
||||
// provide a uniform interface for invoking different kinds of
|
||||
// callables. In particular, you can use:
|
||||
//
|
||||
// CallableHelper<R>::Call(callable, a1, a2, ..., an)
|
||||
//
|
||||
// to invoke an n-ary callable, where R is its return type. If an
|
||||
// argument, say a2, needs to be passed by reference, you should write
|
||||
// ByRef(a2) instead of a2 in the above expression.
|
||||
template <typename R>
|
||||
class CallableHelper {
|
||||
public:
|
||||
// Calls a nullary callable.
|
||||
template <typename Function>
|
||||
static R Call(Function function) { return function(); }
|
||||
|
||||
// Calls a unary callable.
|
||||
|
||||
// We deliberately pass a1 by value instead of const reference here
|
||||
// in case it is a C-string literal. If we had declared the
|
||||
// parameter as 'const A1& a1' and write Call(function, "Hi"), the
|
||||
// compiler would've thought A1 is 'char[3]', which causes trouble
|
||||
// when you need to copy a value of type A1. By declaring the
|
||||
// parameter as 'A1 a1', the compiler will correctly infer that A1
|
||||
// is 'const char*' when it sees Call(function, "Hi").
|
||||
//
|
||||
// Since this function is defined inline, the compiler can get rid
|
||||
// of the copying of the arguments. Therefore the performance won't
|
||||
// be hurt.
|
||||
template <typename Function, typename A1>
|
||||
static R Call(Function function, A1 a1) { return function(a1); }
|
||||
|
||||
// Calls a binary callable.
|
||||
template <typename Function, typename A1, typename A2>
|
||||
static R Call(Function function, A1 a1, A2 a2) {
|
||||
return function(a1, a2);
|
||||
}
|
||||
|
||||
// Calls a ternary callable.
|
||||
template <typename Function, typename A1, typename A2, typename A3>
|
||||
static R Call(Function function, A1 a1, A2 a2, A3 a3) {
|
||||
return function(a1, a2, a3);
|
||||
}
|
||||
|
||||
// Calls a 4-ary callable.
|
||||
template <typename Function, typename A1, typename A2, typename A3,
|
||||
typename A4>
|
||||
static R Call(Function function, A1 a1, A2 a2, A3 a3, A4 a4) {
|
||||
return function(a1, a2, a3, a4);
|
||||
}
|
||||
|
||||
// Calls a 5-ary callable.
|
||||
template <typename Function, typename A1, typename A2, typename A3,
|
||||
typename A4, typename A5>
|
||||
static R Call(Function function, A1 a1, A2 a2, A3 a3, A4 a4, A5 a5) {
|
||||
return function(a1, a2, a3, a4, a5);
|
||||
}
|
||||
|
||||
// Calls a 6-ary callable.
|
||||
template <typename Function, typename A1, typename A2, typename A3,
|
||||
typename A4, typename A5, typename A6>
|
||||
static R Call(Function function, A1 a1, A2 a2, A3 a3, A4 a4, A5 a5, A6 a6) {
|
||||
return function(a1, a2, a3, a4, a5, a6);
|
||||
}
|
||||
|
||||
// Calls a 7-ary callable.
|
||||
template <typename Function, typename A1, typename A2, typename A3,
|
||||
typename A4, typename A5, typename A6, typename A7>
|
||||
static R Call(Function function, A1 a1, A2 a2, A3 a3, A4 a4, A5 a5, A6 a6,
|
||||
A7 a7) {
|
||||
return function(a1, a2, a3, a4, a5, a6, a7);
|
||||
}
|
||||
|
||||
// Calls a 8-ary callable.
|
||||
template <typename Function, typename A1, typename A2, typename A3,
|
||||
typename A4, typename A5, typename A6, typename A7, typename A8>
|
||||
static R Call(Function function, A1 a1, A2 a2, A3 a3, A4 a4, A5 a5, A6 a6,
|
||||
A7 a7, A8 a8) {
|
||||
return function(a1, a2, a3, a4, a5, a6, a7, a8);
|
||||
}
|
||||
|
||||
// Calls a 9-ary callable.
|
||||
template <typename Function, typename A1, typename A2, typename A3,
|
||||
typename A4, typename A5, typename A6, typename A7, typename A8,
|
||||
typename A9>
|
||||
static R Call(Function function, A1 a1, A2 a2, A3 a3, A4 a4, A5 a5, A6 a6,
|
||||
A7 a7, A8 a8, A9 a9) {
|
||||
return function(a1, a2, a3, a4, a5, a6, a7, a8, a9);
|
||||
}
|
||||
|
||||
// Calls a 10-ary callable.
|
||||
template <typename Function, typename A1, typename A2, typename A3,
|
||||
typename A4, typename A5, typename A6, typename A7, typename A8,
|
||||
typename A9, typename A10>
|
||||
static R Call(Function function, A1 a1, A2 a2, A3 a3, A4 a4, A5 a5, A6 a6,
|
||||
A7 a7, A8 a8, A9 a9, A10 a10) {
|
||||
return function(a1, a2, a3, a4, a5, a6, a7, a8, a9, a10);
|
||||
}
|
||||
}; // class CallableHelper
|
||||
|
||||
// An INTERNAL macro for extracting the type of a tuple field. It's
|
||||
// subject to change without notice - DO NOT USE IN USER CODE!
|
||||
#define GMOCK_FIELD_(Tuple, N) \
|
||||
typename ::std::tr1::tuple_element<N, Tuple>::type
|
||||
typename ::testing::tuple_element<N, Tuple>::type
|
||||
|
||||
// SelectArgs<Result, ArgumentTuple, k1, k2, ..., k_n>::type is the
|
||||
// type of an n-ary function whose i-th (1-based) argument type is the
|
||||
// k{i}-th (0-based) field of ArgumentTuple, which must be a tuple
|
||||
// type, and whose return type is Result. For example,
|
||||
// SelectArgs<int, ::std::tr1::tuple<bool, char, double, long>, 0, 3>::type
|
||||
// SelectArgs<int, ::testing::tuple<bool, char, double, long>, 0, 3>::type
|
||||
// is int(bool, long).
|
||||
//
|
||||
// SelectArgs<Result, ArgumentTuple, k1, k2, ..., k_n>::Select(args)
|
||||
// returns the selected fields (k1, k2, ..., k_n) of args as a tuple.
|
||||
// For example,
|
||||
// SelectArgs<int, ::std::tr1::tuple<bool, char, double>, 2, 0>::Select(
|
||||
// ::std::tr1::make_tuple(true, 'a', 2.5))
|
||||
// returns ::std::tr1::tuple (2.5, true).
|
||||
// SelectArgs<int, tuple<bool, char, double>, 2, 0>::Select(
|
||||
// ::testing::make_tuple(true, 'a', 2.5))
|
||||
// returns tuple (2.5, true).
|
||||
//
|
||||
// The numbers in list k1, k2, ..., k_n must be >= 0, where n can be
|
||||
// in the range [0, 10]. Duplicates are allowed and they don't have
|
||||
@@ -418,7 +302,6 @@ class SelectArgs {
|
||||
GMOCK_FIELD_(ArgumentTuple, k10));
|
||||
typedef typename Function<type>::ArgumentTuple SelectedArgs;
|
||||
static SelectedArgs Select(const ArgumentTuple& args) {
|
||||
using ::std::tr1::get;
|
||||
return SelectedArgs(get<k1>(args), get<k2>(args), get<k3>(args),
|
||||
get<k4>(args), get<k5>(args), get<k6>(args), get<k7>(args),
|
||||
get<k8>(args), get<k9>(args), get<k10>(args));
|
||||
@@ -432,7 +315,6 @@ class SelectArgs<Result, ArgumentTuple,
|
||||
typedef Result type();
|
||||
typedef typename Function<type>::ArgumentTuple SelectedArgs;
|
||||
static SelectedArgs Select(const ArgumentTuple& /* args */) {
|
||||
using ::std::tr1::get;
|
||||
return SelectedArgs();
|
||||
}
|
||||
};
|
||||
@@ -444,7 +326,6 @@ class SelectArgs<Result, ArgumentTuple,
|
||||
typedef Result type(GMOCK_FIELD_(ArgumentTuple, k1));
|
||||
typedef typename Function<type>::ArgumentTuple SelectedArgs;
|
||||
static SelectedArgs Select(const ArgumentTuple& args) {
|
||||
using ::std::tr1::get;
|
||||
return SelectedArgs(get<k1>(args));
|
||||
}
|
||||
};
|
||||
@@ -457,7 +338,6 @@ class SelectArgs<Result, ArgumentTuple,
|
||||
GMOCK_FIELD_(ArgumentTuple, k2));
|
||||
typedef typename Function<type>::ArgumentTuple SelectedArgs;
|
||||
static SelectedArgs Select(const ArgumentTuple& args) {
|
||||
using ::std::tr1::get;
|
||||
return SelectedArgs(get<k1>(args), get<k2>(args));
|
||||
}
|
||||
};
|
||||
@@ -470,7 +350,6 @@ class SelectArgs<Result, ArgumentTuple,
|
||||
GMOCK_FIELD_(ArgumentTuple, k2), GMOCK_FIELD_(ArgumentTuple, k3));
|
||||
typedef typename Function<type>::ArgumentTuple SelectedArgs;
|
||||
static SelectedArgs Select(const ArgumentTuple& args) {
|
||||
using ::std::tr1::get;
|
||||
return SelectedArgs(get<k1>(args), get<k2>(args), get<k3>(args));
|
||||
}
|
||||
};
|
||||
@@ -485,7 +364,6 @@ class SelectArgs<Result, ArgumentTuple,
|
||||
GMOCK_FIELD_(ArgumentTuple, k4));
|
||||
typedef typename Function<type>::ArgumentTuple SelectedArgs;
|
||||
static SelectedArgs Select(const ArgumentTuple& args) {
|
||||
using ::std::tr1::get;
|
||||
return SelectedArgs(get<k1>(args), get<k2>(args), get<k3>(args),
|
||||
get<k4>(args));
|
||||
}
|
||||
@@ -501,7 +379,6 @@ class SelectArgs<Result, ArgumentTuple,
|
||||
GMOCK_FIELD_(ArgumentTuple, k4), GMOCK_FIELD_(ArgumentTuple, k5));
|
||||
typedef typename Function<type>::ArgumentTuple SelectedArgs;
|
||||
static SelectedArgs Select(const ArgumentTuple& args) {
|
||||
using ::std::tr1::get;
|
||||
return SelectedArgs(get<k1>(args), get<k2>(args), get<k3>(args),
|
||||
get<k4>(args), get<k5>(args));
|
||||
}
|
||||
@@ -518,7 +395,6 @@ class SelectArgs<Result, ArgumentTuple,
|
||||
GMOCK_FIELD_(ArgumentTuple, k6));
|
||||
typedef typename Function<type>::ArgumentTuple SelectedArgs;
|
||||
static SelectedArgs Select(const ArgumentTuple& args) {
|
||||
using ::std::tr1::get;
|
||||
return SelectedArgs(get<k1>(args), get<k2>(args), get<k3>(args),
|
||||
get<k4>(args), get<k5>(args), get<k6>(args));
|
||||
}
|
||||
@@ -535,7 +411,6 @@ class SelectArgs<Result, ArgumentTuple,
|
||||
GMOCK_FIELD_(ArgumentTuple, k6), GMOCK_FIELD_(ArgumentTuple, k7));
|
||||
typedef typename Function<type>::ArgumentTuple SelectedArgs;
|
||||
static SelectedArgs Select(const ArgumentTuple& args) {
|
||||
using ::std::tr1::get;
|
||||
return SelectedArgs(get<k1>(args), get<k2>(args), get<k3>(args),
|
||||
get<k4>(args), get<k5>(args), get<k6>(args), get<k7>(args));
|
||||
}
|
||||
@@ -553,7 +428,6 @@ class SelectArgs<Result, ArgumentTuple,
|
||||
GMOCK_FIELD_(ArgumentTuple, k8));
|
||||
typedef typename Function<type>::ArgumentTuple SelectedArgs;
|
||||
static SelectedArgs Select(const ArgumentTuple& args) {
|
||||
using ::std::tr1::get;
|
||||
return SelectedArgs(get<k1>(args), get<k2>(args), get<k3>(args),
|
||||
get<k4>(args), get<k5>(args), get<k6>(args), get<k7>(args),
|
||||
get<k8>(args));
|
||||
@@ -572,7 +446,6 @@ class SelectArgs<Result, ArgumentTuple,
|
||||
GMOCK_FIELD_(ArgumentTuple, k8), GMOCK_FIELD_(ArgumentTuple, k9));
|
||||
typedef typename Function<type>::ArgumentTuple SelectedArgs;
|
||||
static SelectedArgs Select(const ArgumentTuple& args) {
|
||||
using ::std::tr1::get;
|
||||
return SelectedArgs(get<k1>(args), get<k2>(args), get<k3>(args),
|
||||
get<k4>(args), get<k5>(args), get<k6>(args), get<k7>(args),
|
||||
get<k8>(args), get<k9>(args));
|
||||
@@ -638,8 +511,7 @@ struct ExcessiveArg {};
|
||||
template <typename Result, class Impl>
|
||||
class ActionHelper {
|
||||
public:
|
||||
static Result Perform(Impl* impl, const ::std::tr1::tuple<>& args) {
|
||||
using ::std::tr1::get;
|
||||
static Result Perform(Impl* impl, const ::testing::tuple<>& args) {
|
||||
return impl->template gmock_PerformImpl<>(args, ExcessiveArg(),
|
||||
ExcessiveArg(), ExcessiveArg(), ExcessiveArg(), ExcessiveArg(),
|
||||
ExcessiveArg(), ExcessiveArg(), ExcessiveArg(), ExcessiveArg(),
|
||||
@@ -647,8 +519,7 @@ class ActionHelper {
|
||||
}
|
||||
|
||||
template <typename A0>
|
||||
static Result Perform(Impl* impl, const ::std::tr1::tuple<A0>& args) {
|
||||
using ::std::tr1::get;
|
||||
static Result Perform(Impl* impl, const ::testing::tuple<A0>& args) {
|
||||
return impl->template gmock_PerformImpl<A0>(args, get<0>(args),
|
||||
ExcessiveArg(), ExcessiveArg(), ExcessiveArg(), ExcessiveArg(),
|
||||
ExcessiveArg(), ExcessiveArg(), ExcessiveArg(), ExcessiveArg(),
|
||||
@@ -656,8 +527,7 @@ class ActionHelper {
|
||||
}
|
||||
|
||||
template <typename A0, typename A1>
|
||||
static Result Perform(Impl* impl, const ::std::tr1::tuple<A0, A1>& args) {
|
||||
using ::std::tr1::get;
|
||||
static Result Perform(Impl* impl, const ::testing::tuple<A0, A1>& args) {
|
||||
return impl->template gmock_PerformImpl<A0, A1>(args, get<0>(args),
|
||||
get<1>(args), ExcessiveArg(), ExcessiveArg(), ExcessiveArg(),
|
||||
ExcessiveArg(), ExcessiveArg(), ExcessiveArg(), ExcessiveArg(),
|
||||
@@ -665,8 +535,7 @@ class ActionHelper {
|
||||
}
|
||||
|
||||
template <typename A0, typename A1, typename A2>
|
||||
static Result Perform(Impl* impl, const ::std::tr1::tuple<A0, A1, A2>& args) {
|
||||
using ::std::tr1::get;
|
||||
static Result Perform(Impl* impl, const ::testing::tuple<A0, A1, A2>& args) {
|
||||
return impl->template gmock_PerformImpl<A0, A1, A2>(args, get<0>(args),
|
||||
get<1>(args), get<2>(args), ExcessiveArg(), ExcessiveArg(),
|
||||
ExcessiveArg(), ExcessiveArg(), ExcessiveArg(), ExcessiveArg(),
|
||||
@@ -674,9 +543,8 @@ class ActionHelper {
|
||||
}
|
||||
|
||||
template <typename A0, typename A1, typename A2, typename A3>
|
||||
static Result Perform(Impl* impl, const ::std::tr1::tuple<A0, A1, A2,
|
||||
static Result Perform(Impl* impl, const ::testing::tuple<A0, A1, A2,
|
||||
A3>& args) {
|
||||
using ::std::tr1::get;
|
||||
return impl->template gmock_PerformImpl<A0, A1, A2, A3>(args, get<0>(args),
|
||||
get<1>(args), get<2>(args), get<3>(args), ExcessiveArg(),
|
||||
ExcessiveArg(), ExcessiveArg(), ExcessiveArg(), ExcessiveArg(),
|
||||
@@ -684,9 +552,8 @@ class ActionHelper {
|
||||
}
|
||||
|
||||
template <typename A0, typename A1, typename A2, typename A3, typename A4>
|
||||
static Result Perform(Impl* impl, const ::std::tr1::tuple<A0, A1, A2, A3,
|
||||
static Result Perform(Impl* impl, const ::testing::tuple<A0, A1, A2, A3,
|
||||
A4>& args) {
|
||||
using ::std::tr1::get;
|
||||
return impl->template gmock_PerformImpl<A0, A1, A2, A3, A4>(args,
|
||||
get<0>(args), get<1>(args), get<2>(args), get<3>(args), get<4>(args),
|
||||
ExcessiveArg(), ExcessiveArg(), ExcessiveArg(), ExcessiveArg(),
|
||||
@@ -695,9 +562,8 @@ class ActionHelper {
|
||||
|
||||
template <typename A0, typename A1, typename A2, typename A3, typename A4,
|
||||
typename A5>
|
||||
static Result Perform(Impl* impl, const ::std::tr1::tuple<A0, A1, A2, A3, A4,
|
||||
static Result Perform(Impl* impl, const ::testing::tuple<A0, A1, A2, A3, A4,
|
||||
A5>& args) {
|
||||
using ::std::tr1::get;
|
||||
return impl->template gmock_PerformImpl<A0, A1, A2, A3, A4, A5>(args,
|
||||
get<0>(args), get<1>(args), get<2>(args), get<3>(args), get<4>(args),
|
||||
get<5>(args), ExcessiveArg(), ExcessiveArg(), ExcessiveArg(),
|
||||
@@ -706,9 +572,8 @@ class ActionHelper {
|
||||
|
||||
template <typename A0, typename A1, typename A2, typename A3, typename A4,
|
||||
typename A5, typename A6>
|
||||
static Result Perform(Impl* impl, const ::std::tr1::tuple<A0, A1, A2, A3, A4,
|
||||
static Result Perform(Impl* impl, const ::testing::tuple<A0, A1, A2, A3, A4,
|
||||
A5, A6>& args) {
|
||||
using ::std::tr1::get;
|
||||
return impl->template gmock_PerformImpl<A0, A1, A2, A3, A4, A5, A6>(args,
|
||||
get<0>(args), get<1>(args), get<2>(args), get<3>(args), get<4>(args),
|
||||
get<5>(args), get<6>(args), ExcessiveArg(), ExcessiveArg(),
|
||||
@@ -717,9 +582,8 @@ class ActionHelper {
|
||||
|
||||
template <typename A0, typename A1, typename A2, typename A3, typename A4,
|
||||
typename A5, typename A6, typename A7>
|
||||
static Result Perform(Impl* impl, const ::std::tr1::tuple<A0, A1, A2, A3, A4,
|
||||
static Result Perform(Impl* impl, const ::testing::tuple<A0, A1, A2, A3, A4,
|
||||
A5, A6, A7>& args) {
|
||||
using ::std::tr1::get;
|
||||
return impl->template gmock_PerformImpl<A0, A1, A2, A3, A4, A5, A6,
|
||||
A7>(args, get<0>(args), get<1>(args), get<2>(args), get<3>(args),
|
||||
get<4>(args), get<5>(args), get<6>(args), get<7>(args), ExcessiveArg(),
|
||||
@@ -728,9 +592,8 @@ class ActionHelper {
|
||||
|
||||
template <typename A0, typename A1, typename A2, typename A3, typename A4,
|
||||
typename A5, typename A6, typename A7, typename A8>
|
||||
static Result Perform(Impl* impl, const ::std::tr1::tuple<A0, A1, A2, A3, A4,
|
||||
static Result Perform(Impl* impl, const ::testing::tuple<A0, A1, A2, A3, A4,
|
||||
A5, A6, A7, A8>& args) {
|
||||
using ::std::tr1::get;
|
||||
return impl->template gmock_PerformImpl<A0, A1, A2, A3, A4, A5, A6, A7,
|
||||
A8>(args, get<0>(args), get<1>(args), get<2>(args), get<3>(args),
|
||||
get<4>(args), get<5>(args), get<6>(args), get<7>(args), get<8>(args),
|
||||
@@ -739,9 +602,8 @@ class ActionHelper {
|
||||
|
||||
template <typename A0, typename A1, typename A2, typename A3, typename A4,
|
||||
typename A5, typename A6, typename A7, typename A8, typename A9>
|
||||
static Result Perform(Impl* impl, const ::std::tr1::tuple<A0, A1, A2, A3, A4,
|
||||
static Result Perform(Impl* impl, const ::testing::tuple<A0, A1, A2, A3, A4,
|
||||
A5, A6, A7, A8, A9>& args) {
|
||||
using ::std::tr1::get;
|
||||
return impl->template gmock_PerformImpl<A0, A1, A2, A3, A4, A5, A6, A7, A8,
|
||||
A9>(args, get<0>(args), get<1>(args), get<2>(args), get<3>(args),
|
||||
get<4>(args), get<5>(args), get<6>(args), get<7>(args), get<8>(args),
|
||||
@@ -1053,7 +915,7 @@ DoAll(Action1 a1, Action2 a2, Action3 a3, Action4 a4, Action5 a5, Action6 a6,
|
||||
// ACTION_TEMPLATE(DuplicateArg,
|
||||
// HAS_2_TEMPLATE_PARAMS(int, k, typename, T),
|
||||
// AND_1_VALUE_PARAMS(output)) {
|
||||
// *output = T(std::tr1::get<k>(args));
|
||||
// *output = T(::testing::get<k>(args));
|
||||
// }
|
||||
// ...
|
||||
// int n;
|
||||
@@ -1384,7 +1246,7 @@ DoAll(Action1 a1, Action2 a2, Action3 a3, Action4 a4, Action5 a5, Action6 a6,
|
||||
GMOCK_INTERNAL_DECL_TYPE_##value_params>\
|
||||
class GMOCK_ACTION_CLASS_(name, value_params) {\
|
||||
public:\
|
||||
GMOCK_ACTION_CLASS_(name, value_params)\
|
||||
explicit GMOCK_ACTION_CLASS_(name, value_params)\
|
||||
GMOCK_INTERNAL_INIT_##value_params {}\
|
||||
template <typename F>\
|
||||
class gmock_Impl : public ::testing::ActionInterface<F> {\
|
||||
@@ -1492,7 +1354,7 @@ DoAll(Action1 a1, Action2 a2, Action3 a3, Action4 a4, Action5 a5, Action6 a6,
|
||||
template <typename p0##_type>\
|
||||
class name##ActionP {\
|
||||
public:\
|
||||
name##ActionP(p0##_type gmock_p0) : p0(gmock_p0) {}\
|
||||
explicit name##ActionP(p0##_type gmock_p0) : p0(gmock_p0) {}\
|
||||
template <typename F>\
|
||||
class gmock_Impl : public ::testing::ActionInterface<F> {\
|
||||
public:\
|
||||
@@ -2218,6 +2080,7 @@ DoAll(Action1 a1, Action2 a2, Action3 a3, Action4 a4, Action5 a5, Action6 a6,
|
||||
|
||||
namespace testing {
|
||||
|
||||
|
||||
// The ACTION*() macros trigger warning C4100 (unreferenced formal
|
||||
// parameter) in MSVC with -W4. Unfortunately they cannot be fixed in
|
||||
// the macro definition, as the warnings are generated when the macro
|
||||
@@ -2258,81 +2121,175 @@ namespace testing {
|
||||
// InvokeArgument action from temporary values and have it performed
|
||||
// later.
|
||||
|
||||
namespace internal {
|
||||
namespace invoke_argument {
|
||||
|
||||
// Appears in InvokeArgumentAdl's argument list to help avoid
|
||||
// accidental calls to user functions of the same name.
|
||||
struct AdlTag {};
|
||||
|
||||
// InvokeArgumentAdl - a helper for InvokeArgument.
|
||||
// The basic overloads are provided here for generic functors.
|
||||
// Overloads for other custom-callables are provided in the
|
||||
// internal/custom/callback-actions.h header.
|
||||
|
||||
template <typename R, typename F>
|
||||
R InvokeArgumentAdl(AdlTag, F f) {
|
||||
return f();
|
||||
}
|
||||
template <typename R, typename F, typename A1>
|
||||
R InvokeArgumentAdl(AdlTag, F f, A1 a1) {
|
||||
return f(a1);
|
||||
}
|
||||
template <typename R, typename F, typename A1, typename A2>
|
||||
R InvokeArgumentAdl(AdlTag, F f, A1 a1, A2 a2) {
|
||||
return f(a1, a2);
|
||||
}
|
||||
template <typename R, typename F, typename A1, typename A2, typename A3>
|
||||
R InvokeArgumentAdl(AdlTag, F f, A1 a1, A2 a2, A3 a3) {
|
||||
return f(a1, a2, a3);
|
||||
}
|
||||
template <typename R, typename F, typename A1, typename A2, typename A3,
|
||||
typename A4>
|
||||
R InvokeArgumentAdl(AdlTag, F f, A1 a1, A2 a2, A3 a3, A4 a4) {
|
||||
return f(a1, a2, a3, a4);
|
||||
}
|
||||
template <typename R, typename F, typename A1, typename A2, typename A3,
|
||||
typename A4, typename A5>
|
||||
R InvokeArgumentAdl(AdlTag, F f, A1 a1, A2 a2, A3 a3, A4 a4, A5 a5) {
|
||||
return f(a1, a2, a3, a4, a5);
|
||||
}
|
||||
template <typename R, typename F, typename A1, typename A2, typename A3,
|
||||
typename A4, typename A5, typename A6>
|
||||
R InvokeArgumentAdl(AdlTag, F f, A1 a1, A2 a2, A3 a3, A4 a4, A5 a5, A6 a6) {
|
||||
return f(a1, a2, a3, a4, a5, a6);
|
||||
}
|
||||
template <typename R, typename F, typename A1, typename A2, typename A3,
|
||||
typename A4, typename A5, typename A6, typename A7>
|
||||
R InvokeArgumentAdl(AdlTag, F f, A1 a1, A2 a2, A3 a3, A4 a4, A5 a5, A6 a6,
|
||||
A7 a7) {
|
||||
return f(a1, a2, a3, a4, a5, a6, a7);
|
||||
}
|
||||
template <typename R, typename F, typename A1, typename A2, typename A3,
|
||||
typename A4, typename A5, typename A6, typename A7, typename A8>
|
||||
R InvokeArgumentAdl(AdlTag, F f, A1 a1, A2 a2, A3 a3, A4 a4, A5 a5, A6 a6,
|
||||
A7 a7, A8 a8) {
|
||||
return f(a1, a2, a3, a4, a5, a6, a7, a8);
|
||||
}
|
||||
template <typename R, typename F, typename A1, typename A2, typename A3,
|
||||
typename A4, typename A5, typename A6, typename A7, typename A8,
|
||||
typename A9>
|
||||
R InvokeArgumentAdl(AdlTag, F f, A1 a1, A2 a2, A3 a3, A4 a4, A5 a5, A6 a6,
|
||||
A7 a7, A8 a8, A9 a9) {
|
||||
return f(a1, a2, a3, a4, a5, a6, a7, a8, a9);
|
||||
}
|
||||
template <typename R, typename F, typename A1, typename A2, typename A3,
|
||||
typename A4, typename A5, typename A6, typename A7, typename A8,
|
||||
typename A9, typename A10>
|
||||
R InvokeArgumentAdl(AdlTag, F f, A1 a1, A2 a2, A3 a3, A4 a4, A5 a5, A6 a6,
|
||||
A7 a7, A8 a8, A9 a9, A10 a10) {
|
||||
return f(a1, a2, a3, a4, a5, a6, a7, a8, a9, a10);
|
||||
}
|
||||
} // namespace invoke_argument
|
||||
} // namespace internal
|
||||
|
||||
ACTION_TEMPLATE(InvokeArgument,
|
||||
HAS_1_TEMPLATE_PARAMS(int, k),
|
||||
AND_0_VALUE_PARAMS()) {
|
||||
return internal::CallableHelper<return_type>::Call(
|
||||
::std::tr1::get<k>(args));
|
||||
using internal::invoke_argument::InvokeArgumentAdl;
|
||||
return InvokeArgumentAdl<return_type>(
|
||||
internal::invoke_argument::AdlTag(),
|
||||
::testing::get<k>(args));
|
||||
}
|
||||
|
||||
ACTION_TEMPLATE(InvokeArgument,
|
||||
HAS_1_TEMPLATE_PARAMS(int, k),
|
||||
AND_1_VALUE_PARAMS(p0)) {
|
||||
return internal::CallableHelper<return_type>::Call(
|
||||
::std::tr1::get<k>(args), p0);
|
||||
using internal::invoke_argument::InvokeArgumentAdl;
|
||||
return InvokeArgumentAdl<return_type>(
|
||||
internal::invoke_argument::AdlTag(),
|
||||
::testing::get<k>(args), p0);
|
||||
}
|
||||
|
||||
ACTION_TEMPLATE(InvokeArgument,
|
||||
HAS_1_TEMPLATE_PARAMS(int, k),
|
||||
AND_2_VALUE_PARAMS(p0, p1)) {
|
||||
return internal::CallableHelper<return_type>::Call(
|
||||
::std::tr1::get<k>(args), p0, p1);
|
||||
using internal::invoke_argument::InvokeArgumentAdl;
|
||||
return InvokeArgumentAdl<return_type>(
|
||||
internal::invoke_argument::AdlTag(),
|
||||
::testing::get<k>(args), p0, p1);
|
||||
}
|
||||
|
||||
ACTION_TEMPLATE(InvokeArgument,
|
||||
HAS_1_TEMPLATE_PARAMS(int, k),
|
||||
AND_3_VALUE_PARAMS(p0, p1, p2)) {
|
||||
return internal::CallableHelper<return_type>::Call(
|
||||
::std::tr1::get<k>(args), p0, p1, p2);
|
||||
using internal::invoke_argument::InvokeArgumentAdl;
|
||||
return InvokeArgumentAdl<return_type>(
|
||||
internal::invoke_argument::AdlTag(),
|
||||
::testing::get<k>(args), p0, p1, p2);
|
||||
}
|
||||
|
||||
ACTION_TEMPLATE(InvokeArgument,
|
||||
HAS_1_TEMPLATE_PARAMS(int, k),
|
||||
AND_4_VALUE_PARAMS(p0, p1, p2, p3)) {
|
||||
return internal::CallableHelper<return_type>::Call(
|
||||
::std::tr1::get<k>(args), p0, p1, p2, p3);
|
||||
using internal::invoke_argument::InvokeArgumentAdl;
|
||||
return InvokeArgumentAdl<return_type>(
|
||||
internal::invoke_argument::AdlTag(),
|
||||
::testing::get<k>(args), p0, p1, p2, p3);
|
||||
}
|
||||
|
||||
ACTION_TEMPLATE(InvokeArgument,
|
||||
HAS_1_TEMPLATE_PARAMS(int, k),
|
||||
AND_5_VALUE_PARAMS(p0, p1, p2, p3, p4)) {
|
||||
return internal::CallableHelper<return_type>::Call(
|
||||
::std::tr1::get<k>(args), p0, p1, p2, p3, p4);
|
||||
using internal::invoke_argument::InvokeArgumentAdl;
|
||||
return InvokeArgumentAdl<return_type>(
|
||||
internal::invoke_argument::AdlTag(),
|
||||
::testing::get<k>(args), p0, p1, p2, p3, p4);
|
||||
}
|
||||
|
||||
ACTION_TEMPLATE(InvokeArgument,
|
||||
HAS_1_TEMPLATE_PARAMS(int, k),
|
||||
AND_6_VALUE_PARAMS(p0, p1, p2, p3, p4, p5)) {
|
||||
return internal::CallableHelper<return_type>::Call(
|
||||
::std::tr1::get<k>(args), p0, p1, p2, p3, p4, p5);
|
||||
using internal::invoke_argument::InvokeArgumentAdl;
|
||||
return InvokeArgumentAdl<return_type>(
|
||||
internal::invoke_argument::AdlTag(),
|
||||
::testing::get<k>(args), p0, p1, p2, p3, p4, p5);
|
||||
}
|
||||
|
||||
ACTION_TEMPLATE(InvokeArgument,
|
||||
HAS_1_TEMPLATE_PARAMS(int, k),
|
||||
AND_7_VALUE_PARAMS(p0, p1, p2, p3, p4, p5, p6)) {
|
||||
return internal::CallableHelper<return_type>::Call(
|
||||
::std::tr1::get<k>(args), p0, p1, p2, p3, p4, p5, p6);
|
||||
using internal::invoke_argument::InvokeArgumentAdl;
|
||||
return InvokeArgumentAdl<return_type>(
|
||||
internal::invoke_argument::AdlTag(),
|
||||
::testing::get<k>(args), p0, p1, p2, p3, p4, p5, p6);
|
||||
}
|
||||
|
||||
ACTION_TEMPLATE(InvokeArgument,
|
||||
HAS_1_TEMPLATE_PARAMS(int, k),
|
||||
AND_8_VALUE_PARAMS(p0, p1, p2, p3, p4, p5, p6, p7)) {
|
||||
return internal::CallableHelper<return_type>::Call(
|
||||
::std::tr1::get<k>(args), p0, p1, p2, p3, p4, p5, p6, p7);
|
||||
using internal::invoke_argument::InvokeArgumentAdl;
|
||||
return InvokeArgumentAdl<return_type>(
|
||||
internal::invoke_argument::AdlTag(),
|
||||
::testing::get<k>(args), p0, p1, p2, p3, p4, p5, p6, p7);
|
||||
}
|
||||
|
||||
ACTION_TEMPLATE(InvokeArgument,
|
||||
HAS_1_TEMPLATE_PARAMS(int, k),
|
||||
AND_9_VALUE_PARAMS(p0, p1, p2, p3, p4, p5, p6, p7, p8)) {
|
||||
return internal::CallableHelper<return_type>::Call(
|
||||
::std::tr1::get<k>(args), p0, p1, p2, p3, p4, p5, p6, p7, p8);
|
||||
using internal::invoke_argument::InvokeArgumentAdl;
|
||||
return InvokeArgumentAdl<return_type>(
|
||||
internal::invoke_argument::AdlTag(),
|
||||
::testing::get<k>(args), p0, p1, p2, p3, p4, p5, p6, p7, p8);
|
||||
}
|
||||
|
||||
ACTION_TEMPLATE(InvokeArgument,
|
||||
HAS_1_TEMPLATE_PARAMS(int, k),
|
||||
AND_10_VALUE_PARAMS(p0, p1, p2, p3, p4, p5, p6, p7, p8, p9)) {
|
||||
return internal::CallableHelper<return_type>::Call(
|
||||
::std::tr1::get<k>(args), p0, p1, p2, p3, p4, p5, p6, p7, p8, p9);
|
||||
using internal::invoke_argument::InvokeArgumentAdl;
|
||||
return InvokeArgumentAdl<return_type>(
|
||||
internal::invoke_argument::AdlTag(),
|
||||
::testing::get<k>(args), p0, p1, p2, p3, p4, p5, p6, p7, p8, p9);
|
||||
}
|
||||
|
||||
// Various overloads for ReturnNew<T>().
|
||||
@@ -2412,4 +2369,9 @@ ACTION_TEMPLATE(ReturnNew,
|
||||
|
||||
} // namespace testing
|
||||
|
||||
// Include any custom actions added by the local installation.
|
||||
// We must include this header at the end to make sure it can use the
|
||||
// declarations from this file.
|
||||
#include "gmock/internal/custom/gmock-generated-actions.h"
|
||||
|
||||
#endif // GMOCK_INCLUDE_GMOCK_GMOCK_GENERATED_ACTIONS_H_
|
||||
@@ -61,87 +61,29 @@ $range j 1..i
|
||||
$var types = [[$for j [[, typename A$j]]]]
|
||||
$var as = [[$for j, [[A$j]]]]
|
||||
$var args = [[$if i==0 [[]] $else [[ args]]]]
|
||||
$var import = [[$if i==0 [[]] $else [[
|
||||
using ::std::tr1::get;
|
||||
|
||||
]]]]
|
||||
$var gets = [[$for j, [[get<$(j - 1)>(args)]]]]
|
||||
template <typename R$types>
|
||||
class InvokeHelper<R, ::std::tr1::tuple<$as> > {
|
||||
class InvokeHelper<R, ::testing::tuple<$as> > {
|
||||
public:
|
||||
template <typename Function>
|
||||
static R Invoke(Function function, const ::std::tr1::tuple<$as>&$args) {
|
||||
$import return function($gets);
|
||||
static R Invoke(Function function, const ::testing::tuple<$as>&$args) {
|
||||
return function($gets);
|
||||
}
|
||||
|
||||
template <class Class, typename MethodPtr>
|
||||
static R InvokeMethod(Class* obj_ptr,
|
||||
MethodPtr method_ptr,
|
||||
const ::std::tr1::tuple<$as>&$args) {
|
||||
$import return (obj_ptr->*method_ptr)($gets);
|
||||
const ::testing::tuple<$as>&$args) {
|
||||
return (obj_ptr->*method_ptr)($gets);
|
||||
}
|
||||
};
|
||||
|
||||
|
||||
]]
|
||||
// CallableHelper has static methods for invoking "callables",
|
||||
// i.e. function pointers and functors. It uses overloading to
|
||||
// provide a uniform interface for invoking different kinds of
|
||||
// callables. In particular, you can use:
|
||||
//
|
||||
// CallableHelper<R>::Call(callable, a1, a2, ..., an)
|
||||
//
|
||||
// to invoke an n-ary callable, where R is its return type. If an
|
||||
// argument, say a2, needs to be passed by reference, you should write
|
||||
// ByRef(a2) instead of a2 in the above expression.
|
||||
template <typename R>
|
||||
class CallableHelper {
|
||||
public:
|
||||
// Calls a nullary callable.
|
||||
template <typename Function>
|
||||
static R Call(Function function) { return function(); }
|
||||
|
||||
// Calls a unary callable.
|
||||
|
||||
// We deliberately pass a1 by value instead of const reference here
|
||||
// in case it is a C-string literal. If we had declared the
|
||||
// parameter as 'const A1& a1' and write Call(function, "Hi"), the
|
||||
// compiler would've thought A1 is 'char[3]', which causes trouble
|
||||
// when you need to copy a value of type A1. By declaring the
|
||||
// parameter as 'A1 a1', the compiler will correctly infer that A1
|
||||
// is 'const char*' when it sees Call(function, "Hi").
|
||||
//
|
||||
// Since this function is defined inline, the compiler can get rid
|
||||
// of the copying of the arguments. Therefore the performance won't
|
||||
// be hurt.
|
||||
template <typename Function, typename A1>
|
||||
static R Call(Function function, A1 a1) { return function(a1); }
|
||||
|
||||
$range i 2..n
|
||||
$for i
|
||||
[[
|
||||
$var arity = [[$if i==2 [[binary]] $elif i==3 [[ternary]] $else [[$i-ary]]]]
|
||||
|
||||
// Calls a $arity callable.
|
||||
|
||||
$range j 1..i
|
||||
$var typename_As = [[$for j, [[typename A$j]]]]
|
||||
$var Aas = [[$for j, [[A$j a$j]]]]
|
||||
$var as = [[$for j, [[a$j]]]]
|
||||
$var typename_Ts = [[$for j, [[typename T$j]]]]
|
||||
$var Ts = [[$for j, [[T$j]]]]
|
||||
template <typename Function, $typename_As>
|
||||
static R Call(Function function, $Aas) {
|
||||
return function($as);
|
||||
}
|
||||
|
||||
]]
|
||||
}; // class CallableHelper
|
||||
|
||||
// An INTERNAL macro for extracting the type of a tuple field. It's
|
||||
// subject to change without notice - DO NOT USE IN USER CODE!
|
||||
#define GMOCK_FIELD_(Tuple, N) \
|
||||
typename ::std::tr1::tuple_element<N, Tuple>::type
|
||||
typename ::testing::tuple_element<N, Tuple>::type
|
||||
|
||||
$range i 1..n
|
||||
|
||||
@@ -149,15 +91,15 @@ $range i 1..n
|
||||
// type of an n-ary function whose i-th (1-based) argument type is the
|
||||
// k{i}-th (0-based) field of ArgumentTuple, which must be a tuple
|
||||
// type, and whose return type is Result. For example,
|
||||
// SelectArgs<int, ::std::tr1::tuple<bool, char, double, long>, 0, 3>::type
|
||||
// SelectArgs<int, ::testing::tuple<bool, char, double, long>, 0, 3>::type
|
||||
// is int(bool, long).
|
||||
//
|
||||
// SelectArgs<Result, ArgumentTuple, k1, k2, ..., k_n>::Select(args)
|
||||
// returns the selected fields (k1, k2, ..., k_n) of args as a tuple.
|
||||
// For example,
|
||||
// SelectArgs<int, ::std::tr1::tuple<bool, char, double>, 2, 0>::Select(
|
||||
// ::std::tr1::make_tuple(true, 'a', 2.5))
|
||||
// returns ::std::tr1::tuple (2.5, true).
|
||||
// SelectArgs<int, tuple<bool, char, double>, 2, 0>::Select(
|
||||
// ::testing::make_tuple(true, 'a', 2.5))
|
||||
// returns tuple (2.5, true).
|
||||
//
|
||||
// The numbers in list k1, k2, ..., k_n must be >= 0, where n can be
|
||||
// in the range [0, $n]. Duplicates are allowed and they don't have
|
||||
@@ -169,7 +111,6 @@ class SelectArgs {
|
||||
typedef Result type($for i, [[GMOCK_FIELD_(ArgumentTuple, k$i)]]);
|
||||
typedef typename Function<type>::ArgumentTuple SelectedArgs;
|
||||
static SelectedArgs Select(const ArgumentTuple& args) {
|
||||
using ::std::tr1::get;
|
||||
return SelectedArgs($for i, [[get<k$i>(args)]]);
|
||||
}
|
||||
};
|
||||
@@ -186,7 +127,6 @@ class SelectArgs<Result, ArgumentTuple,
|
||||
typedef typename Function<type>::ArgumentTuple SelectedArgs;
|
||||
static SelectedArgs Select(const ArgumentTuple& [[]]
|
||||
$if i == 1 [[/* args */]] $else [[args]]) {
|
||||
using ::std::tr1::get;
|
||||
return SelectedArgs($for j1, [[get<k$j1>(args)]]);
|
||||
}
|
||||
};
|
||||
@@ -266,8 +206,7 @@ $range k 1..n-i
|
||||
$var eas = [[$for k, [[ExcessiveArg()]]]]
|
||||
$var arg_list = [[$if (i==0) | (i==n) [[$as$eas]] $else [[$as, $eas]]]]
|
||||
$template
|
||||
static Result Perform(Impl* impl, const ::std::tr1::tuple<$As>& args) {
|
||||
using ::std::tr1::get;
|
||||
static Result Perform(Impl* impl, const ::testing::tuple<$As>& args) {
|
||||
return impl->template gmock_PerformImpl<$As>(args, $arg_list);
|
||||
}
|
||||
|
||||
@@ -454,7 +393,7 @@ $for k [[, \
|
||||
// ACTION_TEMPLATE(DuplicateArg,
|
||||
// HAS_2_TEMPLATE_PARAMS(int, k, typename, T),
|
||||
// AND_1_VALUE_PARAMS(output)) {
|
||||
// *output = T(std::tr1::get<k>(args));
|
||||
// *output = T(::testing::get<k>(args));
|
||||
// }
|
||||
// ...
|
||||
// int n;
|
||||
@@ -613,7 +552,7 @@ $range k 0..n-1
|
||||
GMOCK_INTERNAL_DECL_TYPE_##value_params>\
|
||||
class GMOCK_ACTION_CLASS_(name, value_params) {\
|
||||
public:\
|
||||
GMOCK_ACTION_CLASS_(name, value_params)\
|
||||
explicit GMOCK_ACTION_CLASS_(name, value_params)\
|
||||
GMOCK_INTERNAL_INIT_##value_params {}\
|
||||
template <typename F>\
|
||||
class gmock_Impl : public ::testing::ActionInterface<F> {\
|
||||
@@ -701,7 +640,7 @@ $var macro_name = [[$if i==0 [[ACTION]] $elif i==1 [[ACTION_P]]
|
||||
#define $macro_name(name$for j [[, p$j]])\$template
|
||||
class $class_name {\
|
||||
public:\
|
||||
$class_name($ctor_param_list)$inits {}\
|
||||
[[$if i==1 [[explicit ]]]]$class_name($ctor_param_list)$inits {}\
|
||||
template <typename F>\
|
||||
class gmock_Impl : public ::testing::ActionInterface<F> {\
|
||||
public:\
|
||||
@@ -741,6 +680,7 @@ $$ // show up in the generated code.
|
||||
|
||||
namespace testing {
|
||||
|
||||
|
||||
// The ACTION*() macros trigger warning C4100 (unreferenced formal
|
||||
// parameter) in MSVC with -W4. Unfortunately they cannot be fixed in
|
||||
// the macro definition, as the warnings are generated when the macro
|
||||
@@ -781,6 +721,32 @@ namespace testing {
|
||||
// InvokeArgument action from temporary values and have it performed
|
||||
// later.
|
||||
|
||||
namespace internal {
|
||||
namespace invoke_argument {
|
||||
|
||||
// Appears in InvokeArgumentAdl's argument list to help avoid
|
||||
// accidental calls to user functions of the same name.
|
||||
struct AdlTag {};
|
||||
|
||||
// InvokeArgumentAdl - a helper for InvokeArgument.
|
||||
// The basic overloads are provided here for generic functors.
|
||||
// Overloads for other custom-callables are provided in the
|
||||
// internal/custom/callback-actions.h header.
|
||||
|
||||
$range i 0..n
|
||||
$for i
|
||||
[[
|
||||
$range j 1..i
|
||||
|
||||
template <typename R, typename F[[$for j [[, typename A$j]]]]>
|
||||
R InvokeArgumentAdl(AdlTag, F f[[$for j [[, A$j a$j]]]]) {
|
||||
return f([[$for j, [[a$j]]]]);
|
||||
}
|
||||
]]
|
||||
|
||||
} // namespace invoke_argument
|
||||
} // namespace internal
|
||||
|
||||
$range i 0..n
|
||||
$for i [[
|
||||
$range j 0..i-1
|
||||
@@ -788,8 +754,10 @@ $range j 0..i-1
|
||||
ACTION_TEMPLATE(InvokeArgument,
|
||||
HAS_1_TEMPLATE_PARAMS(int, k),
|
||||
AND_$i[[]]_VALUE_PARAMS($for j, [[p$j]])) {
|
||||
return internal::CallableHelper<return_type>::Call(
|
||||
::std::tr1::get<k>(args)$for j [[, p$j]]);
|
||||
using internal::invoke_argument::InvokeArgumentAdl;
|
||||
return InvokeArgumentAdl<return_type>(
|
||||
internal::invoke_argument::AdlTag(),
|
||||
::testing::get<k>(args)$for j [[, p$j]]);
|
||||
}
|
||||
|
||||
]]
|
||||
@@ -818,4 +786,9 @@ ACTION_TEMPLATE(ReturnNew,
|
||||
|
||||
} // namespace testing
|
||||
|
||||
// Include any custom callback actions added by the local installation.
|
||||
// We must include this header at the end to make sure it can use the
|
||||
// declarations from this file.
|
||||
#include "gmock/internal/custom/gmock-generated-actions.h"
|
||||
|
||||
#endif // GMOCK_INCLUDE_GMOCK_GMOCK_GENERATED_ACTIONS_H_
|
||||
@@ -43,6 +43,10 @@
|
||||
#include "gmock/gmock-spec-builders.h"
|
||||
#include "gmock/internal/gmock-internal-utils.h"
|
||||
|
||||
#if GTEST_HAS_STD_FUNCTION_
|
||||
# include <functional>
|
||||
#endif
|
||||
|
||||
namespace testing {
|
||||
namespace internal {
|
||||
|
||||
@@ -85,7 +89,7 @@ class FunctionMocker<R(A1)> : public
|
||||
typedef typename internal::Function<F>::ArgumentTuple ArgumentTuple;
|
||||
|
||||
MockSpec<F>& With(const Matcher<A1>& m1) {
|
||||
this->current_spec().SetMatchers(::std::tr1::make_tuple(m1));
|
||||
this->current_spec().SetMatchers(::testing::make_tuple(m1));
|
||||
return this->current_spec();
|
||||
}
|
||||
|
||||
@@ -106,7 +110,7 @@ class FunctionMocker<R(A1, A2)> : public
|
||||
typedef typename internal::Function<F>::ArgumentTuple ArgumentTuple;
|
||||
|
||||
MockSpec<F>& With(const Matcher<A1>& m1, const Matcher<A2>& m2) {
|
||||
this->current_spec().SetMatchers(::std::tr1::make_tuple(m1, m2));
|
||||
this->current_spec().SetMatchers(::testing::make_tuple(m1, m2));
|
||||
return this->current_spec();
|
||||
}
|
||||
|
||||
@@ -128,7 +132,7 @@ class FunctionMocker<R(A1, A2, A3)> : public
|
||||
|
||||
MockSpec<F>& With(const Matcher<A1>& m1, const Matcher<A2>& m2,
|
||||
const Matcher<A3>& m3) {
|
||||
this->current_spec().SetMatchers(::std::tr1::make_tuple(m1, m2, m3));
|
||||
this->current_spec().SetMatchers(::testing::make_tuple(m1, m2, m3));
|
||||
return this->current_spec();
|
||||
}
|
||||
|
||||
@@ -150,7 +154,7 @@ class FunctionMocker<R(A1, A2, A3, A4)> : public
|
||||
|
||||
MockSpec<F>& With(const Matcher<A1>& m1, const Matcher<A2>& m2,
|
||||
const Matcher<A3>& m3, const Matcher<A4>& m4) {
|
||||
this->current_spec().SetMatchers(::std::tr1::make_tuple(m1, m2, m3, m4));
|
||||
this->current_spec().SetMatchers(::testing::make_tuple(m1, m2, m3, m4));
|
||||
return this->current_spec();
|
||||
}
|
||||
|
||||
@@ -173,8 +177,7 @@ class FunctionMocker<R(A1, A2, A3, A4, A5)> : public
|
||||
|
||||
MockSpec<F>& With(const Matcher<A1>& m1, const Matcher<A2>& m2,
|
||||
const Matcher<A3>& m3, const Matcher<A4>& m4, const Matcher<A5>& m5) {
|
||||
this->current_spec().SetMatchers(::std::tr1::make_tuple(m1, m2, m3, m4,
|
||||
m5));
|
||||
this->current_spec().SetMatchers(::testing::make_tuple(m1, m2, m3, m4, m5));
|
||||
return this->current_spec();
|
||||
}
|
||||
|
||||
@@ -198,7 +201,7 @@ class FunctionMocker<R(A1, A2, A3, A4, A5, A6)> : public
|
||||
MockSpec<F>& With(const Matcher<A1>& m1, const Matcher<A2>& m2,
|
||||
const Matcher<A3>& m3, const Matcher<A4>& m4, const Matcher<A5>& m5,
|
||||
const Matcher<A6>& m6) {
|
||||
this->current_spec().SetMatchers(::std::tr1::make_tuple(m1, m2, m3, m4, m5,
|
||||
this->current_spec().SetMatchers(::testing::make_tuple(m1, m2, m3, m4, m5,
|
||||
m6));
|
||||
return this->current_spec();
|
||||
}
|
||||
@@ -223,7 +226,7 @@ class FunctionMocker<R(A1, A2, A3, A4, A5, A6, A7)> : public
|
||||
MockSpec<F>& With(const Matcher<A1>& m1, const Matcher<A2>& m2,
|
||||
const Matcher<A3>& m3, const Matcher<A4>& m4, const Matcher<A5>& m5,
|
||||
const Matcher<A6>& m6, const Matcher<A7>& m7) {
|
||||
this->current_spec().SetMatchers(::std::tr1::make_tuple(m1, m2, m3, m4, m5,
|
||||
this->current_spec().SetMatchers(::testing::make_tuple(m1, m2, m3, m4, m5,
|
||||
m6, m7));
|
||||
return this->current_spec();
|
||||
}
|
||||
@@ -248,7 +251,7 @@ class FunctionMocker<R(A1, A2, A3, A4, A5, A6, A7, A8)> : public
|
||||
MockSpec<F>& With(const Matcher<A1>& m1, const Matcher<A2>& m2,
|
||||
const Matcher<A3>& m3, const Matcher<A4>& m4, const Matcher<A5>& m5,
|
||||
const Matcher<A6>& m6, const Matcher<A7>& m7, const Matcher<A8>& m8) {
|
||||
this->current_spec().SetMatchers(::std::tr1::make_tuple(m1, m2, m3, m4, m5,
|
||||
this->current_spec().SetMatchers(::testing::make_tuple(m1, m2, m3, m4, m5,
|
||||
m6, m7, m8));
|
||||
return this->current_spec();
|
||||
}
|
||||
@@ -274,7 +277,7 @@ class FunctionMocker<R(A1, A2, A3, A4, A5, A6, A7, A8, A9)> : public
|
||||
const Matcher<A3>& m3, const Matcher<A4>& m4, const Matcher<A5>& m5,
|
||||
const Matcher<A6>& m6, const Matcher<A7>& m7, const Matcher<A8>& m8,
|
||||
const Matcher<A9>& m9) {
|
||||
this->current_spec().SetMatchers(::std::tr1::make_tuple(m1, m2, m3, m4, m5,
|
||||
this->current_spec().SetMatchers(::testing::make_tuple(m1, m2, m3, m4, m5,
|
||||
m6, m7, m8, m9));
|
||||
return this->current_spec();
|
||||
}
|
||||
@@ -301,7 +304,7 @@ class FunctionMocker<R(A1, A2, A3, A4, A5, A6, A7, A8, A9, A10)> : public
|
||||
const Matcher<A3>& m3, const Matcher<A4>& m4, const Matcher<A5>& m5,
|
||||
const Matcher<A6>& m6, const Matcher<A7>& m7, const Matcher<A8>& m8,
|
||||
const Matcher<A9>& m9, const Matcher<A10>& m10) {
|
||||
this->current_spec().SetMatchers(::std::tr1::make_tuple(m1, m2, m3, m4, m5,
|
||||
this->current_spec().SetMatchers(::testing::make_tuple(m1, m2, m3, m4, m5,
|
||||
m6, m7, m8, m9, m10));
|
||||
return this->current_spec();
|
||||
}
|
||||
@@ -353,7 +356,7 @@ using internal::FunctionMocker;
|
||||
#define GMOCK_METHOD0_(tn, constness, ct, Method, ...) \
|
||||
GMOCK_RESULT_(tn, __VA_ARGS__) ct Method( \
|
||||
) constness { \
|
||||
GTEST_COMPILE_ASSERT_((::std::tr1::tuple_size< \
|
||||
GTEST_COMPILE_ASSERT_((::testing::tuple_size< \
|
||||
tn ::testing::internal::Function<__VA_ARGS__>::ArgumentTuple>::value \
|
||||
== 0), \
|
||||
this_method_does_not_take_0_arguments); \
|
||||
@@ -372,7 +375,7 @@ using internal::FunctionMocker;
|
||||
#define GMOCK_METHOD1_(tn, constness, ct, Method, ...) \
|
||||
GMOCK_RESULT_(tn, __VA_ARGS__) ct Method( \
|
||||
GMOCK_ARG_(tn, 1, __VA_ARGS__) gmock_a1) constness { \
|
||||
GTEST_COMPILE_ASSERT_((::std::tr1::tuple_size< \
|
||||
GTEST_COMPILE_ASSERT_((::testing::tuple_size< \
|
||||
tn ::testing::internal::Function<__VA_ARGS__>::ArgumentTuple>::value \
|
||||
== 1), \
|
||||
this_method_does_not_take_1_argument); \
|
||||
@@ -392,7 +395,7 @@ using internal::FunctionMocker;
|
||||
GMOCK_RESULT_(tn, __VA_ARGS__) ct Method( \
|
||||
GMOCK_ARG_(tn, 1, __VA_ARGS__) gmock_a1, \
|
||||
GMOCK_ARG_(tn, 2, __VA_ARGS__) gmock_a2) constness { \
|
||||
GTEST_COMPILE_ASSERT_((::std::tr1::tuple_size< \
|
||||
GTEST_COMPILE_ASSERT_((::testing::tuple_size< \
|
||||
tn ::testing::internal::Function<__VA_ARGS__>::ArgumentTuple>::value \
|
||||
== 2), \
|
||||
this_method_does_not_take_2_arguments); \
|
||||
@@ -414,7 +417,7 @@ using internal::FunctionMocker;
|
||||
GMOCK_ARG_(tn, 1, __VA_ARGS__) gmock_a1, \
|
||||
GMOCK_ARG_(tn, 2, __VA_ARGS__) gmock_a2, \
|
||||
GMOCK_ARG_(tn, 3, __VA_ARGS__) gmock_a3) constness { \
|
||||
GTEST_COMPILE_ASSERT_((::std::tr1::tuple_size< \
|
||||
GTEST_COMPILE_ASSERT_((::testing::tuple_size< \
|
||||
tn ::testing::internal::Function<__VA_ARGS__>::ArgumentTuple>::value \
|
||||
== 3), \
|
||||
this_method_does_not_take_3_arguments); \
|
||||
@@ -440,7 +443,7 @@ using internal::FunctionMocker;
|
||||
GMOCK_ARG_(tn, 2, __VA_ARGS__) gmock_a2, \
|
||||
GMOCK_ARG_(tn, 3, __VA_ARGS__) gmock_a3, \
|
||||
GMOCK_ARG_(tn, 4, __VA_ARGS__) gmock_a4) constness { \
|
||||
GTEST_COMPILE_ASSERT_((::std::tr1::tuple_size< \
|
||||
GTEST_COMPILE_ASSERT_((::testing::tuple_size< \
|
||||
tn ::testing::internal::Function<__VA_ARGS__>::ArgumentTuple>::value \
|
||||
== 4), \
|
||||
this_method_does_not_take_4_arguments); \
|
||||
@@ -468,7 +471,7 @@ using internal::FunctionMocker;
|
||||
GMOCK_ARG_(tn, 3, __VA_ARGS__) gmock_a3, \
|
||||
GMOCK_ARG_(tn, 4, __VA_ARGS__) gmock_a4, \
|
||||
GMOCK_ARG_(tn, 5, __VA_ARGS__) gmock_a5) constness { \
|
||||
GTEST_COMPILE_ASSERT_((::std::tr1::tuple_size< \
|
||||
GTEST_COMPILE_ASSERT_((::testing::tuple_size< \
|
||||
tn ::testing::internal::Function<__VA_ARGS__>::ArgumentTuple>::value \
|
||||
== 5), \
|
||||
this_method_does_not_take_5_arguments); \
|
||||
@@ -498,7 +501,7 @@ using internal::FunctionMocker;
|
||||
GMOCK_ARG_(tn, 4, __VA_ARGS__) gmock_a4, \
|
||||
GMOCK_ARG_(tn, 5, __VA_ARGS__) gmock_a5, \
|
||||
GMOCK_ARG_(tn, 6, __VA_ARGS__) gmock_a6) constness { \
|
||||
GTEST_COMPILE_ASSERT_((::std::tr1::tuple_size< \
|
||||
GTEST_COMPILE_ASSERT_((::testing::tuple_size< \
|
||||
tn ::testing::internal::Function<__VA_ARGS__>::ArgumentTuple>::value \
|
||||
== 6), \
|
||||
this_method_does_not_take_6_arguments); \
|
||||
@@ -530,7 +533,7 @@ using internal::FunctionMocker;
|
||||
GMOCK_ARG_(tn, 5, __VA_ARGS__) gmock_a5, \
|
||||
GMOCK_ARG_(tn, 6, __VA_ARGS__) gmock_a6, \
|
||||
GMOCK_ARG_(tn, 7, __VA_ARGS__) gmock_a7) constness { \
|
||||
GTEST_COMPILE_ASSERT_((::std::tr1::tuple_size< \
|
||||
GTEST_COMPILE_ASSERT_((::testing::tuple_size< \
|
||||
tn ::testing::internal::Function<__VA_ARGS__>::ArgumentTuple>::value \
|
||||
== 7), \
|
||||
this_method_does_not_take_7_arguments); \
|
||||
@@ -564,7 +567,7 @@ using internal::FunctionMocker;
|
||||
GMOCK_ARG_(tn, 6, __VA_ARGS__) gmock_a6, \
|
||||
GMOCK_ARG_(tn, 7, __VA_ARGS__) gmock_a7, \
|
||||
GMOCK_ARG_(tn, 8, __VA_ARGS__) gmock_a8) constness { \
|
||||
GTEST_COMPILE_ASSERT_((::std::tr1::tuple_size< \
|
||||
GTEST_COMPILE_ASSERT_((::testing::tuple_size< \
|
||||
tn ::testing::internal::Function<__VA_ARGS__>::ArgumentTuple>::value \
|
||||
== 8), \
|
||||
this_method_does_not_take_8_arguments); \
|
||||
@@ -600,7 +603,7 @@ using internal::FunctionMocker;
|
||||
GMOCK_ARG_(tn, 7, __VA_ARGS__) gmock_a7, \
|
||||
GMOCK_ARG_(tn, 8, __VA_ARGS__) gmock_a8, \
|
||||
GMOCK_ARG_(tn, 9, __VA_ARGS__) gmock_a9) constness { \
|
||||
GTEST_COMPILE_ASSERT_((::std::tr1::tuple_size< \
|
||||
GTEST_COMPILE_ASSERT_((::testing::tuple_size< \
|
||||
tn ::testing::internal::Function<__VA_ARGS__>::ArgumentTuple>::value \
|
||||
== 9), \
|
||||
this_method_does_not_take_9_arguments); \
|
||||
@@ -640,7 +643,7 @@ using internal::FunctionMocker;
|
||||
GMOCK_ARG_(tn, 8, __VA_ARGS__) gmock_a8, \
|
||||
GMOCK_ARG_(tn, 9, __VA_ARGS__) gmock_a9, \
|
||||
GMOCK_ARG_(tn, 10, __VA_ARGS__) gmock_a10) constness { \
|
||||
GTEST_COMPILE_ASSERT_((::std::tr1::tuple_size< \
|
||||
GTEST_COMPILE_ASSERT_((::testing::tuple_size< \
|
||||
tn ::testing::internal::Function<__VA_ARGS__>::ArgumentTuple>::value \
|
||||
== 10), \
|
||||
this_method_does_not_take_10_arguments); \
|
||||
@@ -855,6 +858,17 @@ using internal::FunctionMocker;
|
||||
// point "2", and nothing should happen between the two check
|
||||
// points. The explicit check points make it easy to tell which
|
||||
// Bar("a") is called by which call to Foo().
|
||||
//
|
||||
// MockFunction<F> can also be used to exercise code that accepts
|
||||
// std::function<F> callbacks. To do so, use AsStdFunction() method
|
||||
// to create std::function proxy forwarding to original object's Call.
|
||||
// Example:
|
||||
//
|
||||
// TEST(FooTest, RunsCallbackWithBarArgument) {
|
||||
// MockFunction<int(string)> callback;
|
||||
// EXPECT_CALL(callback, Call("bar")).WillOnce(Return(1));
|
||||
// Foo(callback.AsStdFunction());
|
||||
// }
|
||||
template <typename F>
|
||||
class MockFunction;
|
||||
|
||||
@@ -865,6 +879,14 @@ class MockFunction<R()> {
|
||||
|
||||
MOCK_METHOD0_T(Call, R());
|
||||
|
||||
#if GTEST_HAS_STD_FUNCTION_
|
||||
std::function<R()> AsStdFunction() {
|
||||
return [this]() -> R {
|
||||
return this->Call();
|
||||
};
|
||||
}
|
||||
#endif // GTEST_HAS_STD_FUNCTION_
|
||||
|
||||
private:
|
||||
GTEST_DISALLOW_COPY_AND_ASSIGN_(MockFunction);
|
||||
};
|
||||
@@ -876,6 +898,14 @@ class MockFunction<R(A0)> {
|
||||
|
||||
MOCK_METHOD1_T(Call, R(A0));
|
||||
|
||||
#if GTEST_HAS_STD_FUNCTION_
|
||||
std::function<R(A0)> AsStdFunction() {
|
||||
return [this](A0 a0) -> R {
|
||||
return this->Call(a0);
|
||||
};
|
||||
}
|
||||
#endif // GTEST_HAS_STD_FUNCTION_
|
||||
|
||||
private:
|
||||
GTEST_DISALLOW_COPY_AND_ASSIGN_(MockFunction);
|
||||
};
|
||||
@@ -887,6 +917,14 @@ class MockFunction<R(A0, A1)> {
|
||||
|
||||
MOCK_METHOD2_T(Call, R(A0, A1));
|
||||
|
||||
#if GTEST_HAS_STD_FUNCTION_
|
||||
std::function<R(A0, A1)> AsStdFunction() {
|
||||
return [this](A0 a0, A1 a1) -> R {
|
||||
return this->Call(a0, a1);
|
||||
};
|
||||
}
|
||||
#endif // GTEST_HAS_STD_FUNCTION_
|
||||
|
||||
private:
|
||||
GTEST_DISALLOW_COPY_AND_ASSIGN_(MockFunction);
|
||||
};
|
||||
@@ -898,6 +936,14 @@ class MockFunction<R(A0, A1, A2)> {
|
||||
|
||||
MOCK_METHOD3_T(Call, R(A0, A1, A2));
|
||||
|
||||
#if GTEST_HAS_STD_FUNCTION_
|
||||
std::function<R(A0, A1, A2)> AsStdFunction() {
|
||||
return [this](A0 a0, A1 a1, A2 a2) -> R {
|
||||
return this->Call(a0, a1, a2);
|
||||
};
|
||||
}
|
||||
#endif // GTEST_HAS_STD_FUNCTION_
|
||||
|
||||
private:
|
||||
GTEST_DISALLOW_COPY_AND_ASSIGN_(MockFunction);
|
||||
};
|
||||
@@ -909,6 +955,14 @@ class MockFunction<R(A0, A1, A2, A3)> {
|
||||
|
||||
MOCK_METHOD4_T(Call, R(A0, A1, A2, A3));
|
||||
|
||||
#if GTEST_HAS_STD_FUNCTION_
|
||||
std::function<R(A0, A1, A2, A3)> AsStdFunction() {
|
||||
return [this](A0 a0, A1 a1, A2 a2, A3 a3) -> R {
|
||||
return this->Call(a0, a1, a2, a3);
|
||||
};
|
||||
}
|
||||
#endif // GTEST_HAS_STD_FUNCTION_
|
||||
|
||||
private:
|
||||
GTEST_DISALLOW_COPY_AND_ASSIGN_(MockFunction);
|
||||
};
|
||||
@@ -921,6 +975,14 @@ class MockFunction<R(A0, A1, A2, A3, A4)> {
|
||||
|
||||
MOCK_METHOD5_T(Call, R(A0, A1, A2, A3, A4));
|
||||
|
||||
#if GTEST_HAS_STD_FUNCTION_
|
||||
std::function<R(A0, A1, A2, A3, A4)> AsStdFunction() {
|
||||
return [this](A0 a0, A1 a1, A2 a2, A3 a3, A4 a4) -> R {
|
||||
return this->Call(a0, a1, a2, a3, a4);
|
||||
};
|
||||
}
|
||||
#endif // GTEST_HAS_STD_FUNCTION_
|
||||
|
||||
private:
|
||||
GTEST_DISALLOW_COPY_AND_ASSIGN_(MockFunction);
|
||||
};
|
||||
@@ -933,6 +995,14 @@ class MockFunction<R(A0, A1, A2, A3, A4, A5)> {
|
||||
|
||||
MOCK_METHOD6_T(Call, R(A0, A1, A2, A3, A4, A5));
|
||||
|
||||
#if GTEST_HAS_STD_FUNCTION_
|
||||
std::function<R(A0, A1, A2, A3, A4, A5)> AsStdFunction() {
|
||||
return [this](A0 a0, A1 a1, A2 a2, A3 a3, A4 a4, A5 a5) -> R {
|
||||
return this->Call(a0, a1, a2, a3, a4, a5);
|
||||
};
|
||||
}
|
||||
#endif // GTEST_HAS_STD_FUNCTION_
|
||||
|
||||
private:
|
||||
GTEST_DISALLOW_COPY_AND_ASSIGN_(MockFunction);
|
||||
};
|
||||
@@ -945,6 +1015,14 @@ class MockFunction<R(A0, A1, A2, A3, A4, A5, A6)> {
|
||||
|
||||
MOCK_METHOD7_T(Call, R(A0, A1, A2, A3, A4, A5, A6));
|
||||
|
||||
#if GTEST_HAS_STD_FUNCTION_
|
||||
std::function<R(A0, A1, A2, A3, A4, A5, A6)> AsStdFunction() {
|
||||
return [this](A0 a0, A1 a1, A2 a2, A3 a3, A4 a4, A5 a5, A6 a6) -> R {
|
||||
return this->Call(a0, a1, a2, a3, a4, a5, a6);
|
||||
};
|
||||
}
|
||||
#endif // GTEST_HAS_STD_FUNCTION_
|
||||
|
||||
private:
|
||||
GTEST_DISALLOW_COPY_AND_ASSIGN_(MockFunction);
|
||||
};
|
||||
@@ -957,6 +1035,14 @@ class MockFunction<R(A0, A1, A2, A3, A4, A5, A6, A7)> {
|
||||
|
||||
MOCK_METHOD8_T(Call, R(A0, A1, A2, A3, A4, A5, A6, A7));
|
||||
|
||||
#if GTEST_HAS_STD_FUNCTION_
|
||||
std::function<R(A0, A1, A2, A3, A4, A5, A6, A7)> AsStdFunction() {
|
||||
return [this](A0 a0, A1 a1, A2 a2, A3 a3, A4 a4, A5 a5, A6 a6, A7 a7) -> R {
|
||||
return this->Call(a0, a1, a2, a3, a4, a5, a6, a7);
|
||||
};
|
||||
}
|
||||
#endif // GTEST_HAS_STD_FUNCTION_
|
||||
|
||||
private:
|
||||
GTEST_DISALLOW_COPY_AND_ASSIGN_(MockFunction);
|
||||
};
|
||||
@@ -969,6 +1055,15 @@ class MockFunction<R(A0, A1, A2, A3, A4, A5, A6, A7, A8)> {
|
||||
|
||||
MOCK_METHOD9_T(Call, R(A0, A1, A2, A3, A4, A5, A6, A7, A8));
|
||||
|
||||
#if GTEST_HAS_STD_FUNCTION_
|
||||
std::function<R(A0, A1, A2, A3, A4, A5, A6, A7, A8)> AsStdFunction() {
|
||||
return [this](A0 a0, A1 a1, A2 a2, A3 a3, A4 a4, A5 a5, A6 a6, A7 a7,
|
||||
A8 a8) -> R {
|
||||
return this->Call(a0, a1, a2, a3, a4, a5, a6, a7, a8);
|
||||
};
|
||||
}
|
||||
#endif // GTEST_HAS_STD_FUNCTION_
|
||||
|
||||
private:
|
||||
GTEST_DISALLOW_COPY_AND_ASSIGN_(MockFunction);
|
||||
};
|
||||
@@ -982,6 +1077,15 @@ class MockFunction<R(A0, A1, A2, A3, A4, A5, A6, A7, A8, A9)> {
|
||||
|
||||
MOCK_METHOD10_T(Call, R(A0, A1, A2, A3, A4, A5, A6, A7, A8, A9));
|
||||
|
||||
#if GTEST_HAS_STD_FUNCTION_
|
||||
std::function<R(A0, A1, A2, A3, A4, A5, A6, A7, A8, A9)> AsStdFunction() {
|
||||
return [this](A0 a0, A1 a1, A2 a2, A3 a3, A4 a4, A5 a5, A6 a6, A7 a7,
|
||||
A8 a8, A9 a9) -> R {
|
||||
return this->Call(a0, a1, a2, a3, a4, a5, a6, a7, a8, a9);
|
||||
};
|
||||
}
|
||||
#endif // GTEST_HAS_STD_FUNCTION_
|
||||
|
||||
private:
|
||||
GTEST_DISALLOW_COPY_AND_ASSIGN_(MockFunction);
|
||||
};
|
||||
@@ -44,6 +44,10 @@ $var n = 10 $$ The maximum arity we support.
|
||||
#include "gmock/gmock-spec-builders.h"
|
||||
#include "gmock/internal/gmock-internal-utils.h"
|
||||
|
||||
#if GTEST_HAS_STD_FUNCTION_
|
||||
# include <functional>
|
||||
#endif
|
||||
|
||||
namespace testing {
|
||||
namespace internal {
|
||||
|
||||
@@ -78,7 +82,7 @@ class FunctionMocker<R($As)> : public
|
||||
MockSpec<F>& With($matchers) {
|
||||
|
||||
$if i >= 1 [[
|
||||
this->current_spec().SetMatchers(::std::tr1::make_tuple($ms));
|
||||
this->current_spec().SetMatchers(::testing::make_tuple($ms));
|
||||
|
||||
]]
|
||||
return this->current_spec();
|
||||
@@ -139,7 +143,7 @@ $var matcher_as = [[$for j, \
|
||||
#define GMOCK_METHOD$i[[]]_(tn, constness, ct, Method, ...) \
|
||||
GMOCK_RESULT_(tn, __VA_ARGS__) ct Method( \
|
||||
$arg_as) constness { \
|
||||
GTEST_COMPILE_ASSERT_((::std::tr1::tuple_size< \
|
||||
GTEST_COMPILE_ASSERT_((::testing::tuple_size< \
|
||||
tn ::testing::internal::Function<__VA_ARGS__>::ArgumentTuple>::value == $i), \
|
||||
this_method_does_not_take_$i[[]]_argument[[$if i != 1 [[s]]]]); \
|
||||
GMOCK_MOCKER_($i, constness, Method).SetOwnerAndName(this, #Method); \
|
||||
@@ -241,18 +245,40 @@ $for i [[
|
||||
// point "2", and nothing should happen between the two check
|
||||
// points. The explicit check points make it easy to tell which
|
||||
// Bar("a") is called by which call to Foo().
|
||||
//
|
||||
// MockFunction<F> can also be used to exercise code that accepts
|
||||
// std::function<F> callbacks. To do so, use AsStdFunction() method
|
||||
// to create std::function proxy forwarding to original object's Call.
|
||||
// Example:
|
||||
//
|
||||
// TEST(FooTest, RunsCallbackWithBarArgument) {
|
||||
// MockFunction<int(string)> callback;
|
||||
// EXPECT_CALL(callback, Call("bar")).WillOnce(Return(1));
|
||||
// Foo(callback.AsStdFunction());
|
||||
// }
|
||||
template <typename F>
|
||||
class MockFunction;
|
||||
|
||||
|
||||
$for i [[
|
||||
$range j 0..i-1
|
||||
$var ArgTypes = [[$for j, [[A$j]]]]
|
||||
$var ArgNames = [[$for j, [[a$j]]]]
|
||||
$var ArgDecls = [[$for j, [[A$j a$j]]]]
|
||||
template <typename R$for j [[, typename A$j]]>
|
||||
class MockFunction<R($for j, [[A$j]])> {
|
||||
class MockFunction<R($ArgTypes)> {
|
||||
public:
|
||||
MockFunction() {}
|
||||
|
||||
MOCK_METHOD$i[[]]_T(Call, R($for j, [[A$j]]));
|
||||
MOCK_METHOD$i[[]]_T(Call, R($ArgTypes));
|
||||
|
||||
#if GTEST_HAS_STD_FUNCTION_
|
||||
std::function<R($ArgTypes)> AsStdFunction() {
|
||||
return [this]($ArgDecls) -> R {
|
||||
return this->Call($ArgNames);
|
||||
};
|
||||
}
|
||||
#endif // GTEST_HAS_STD_FUNCTION_
|
||||
|
||||
private:
|
||||
GTEST_DISALLOW_COPY_AND_ASSIGN_(MockFunction);
|
||||
@@ -49,7 +49,7 @@ namespace internal {
|
||||
|
||||
// The type of the i-th (0-based) field of Tuple.
|
||||
#define GMOCK_FIELD_TYPE_(Tuple, i) \
|
||||
typename ::std::tr1::tuple_element<i, Tuple>::type
|
||||
typename ::testing::tuple_element<i, Tuple>::type
|
||||
|
||||
// TupleFields<Tuple, k0, ..., kn> is for selecting fields from a
|
||||
// tuple of type Tuple. It has two members:
|
||||
@@ -72,14 +72,13 @@ template <class Tuple, int k0, int k1, int k2, int k3, int k4, int k5, int k6,
|
||||
int k7, int k8, int k9>
|
||||
class TupleFields {
|
||||
public:
|
||||
typedef ::std::tr1::tuple<GMOCK_FIELD_TYPE_(Tuple, k0),
|
||||
typedef ::testing::tuple<GMOCK_FIELD_TYPE_(Tuple, k0),
|
||||
GMOCK_FIELD_TYPE_(Tuple, k1), GMOCK_FIELD_TYPE_(Tuple, k2),
|
||||
GMOCK_FIELD_TYPE_(Tuple, k3), GMOCK_FIELD_TYPE_(Tuple, k4),
|
||||
GMOCK_FIELD_TYPE_(Tuple, k5), GMOCK_FIELD_TYPE_(Tuple, k6),
|
||||
GMOCK_FIELD_TYPE_(Tuple, k7), GMOCK_FIELD_TYPE_(Tuple, k8),
|
||||
GMOCK_FIELD_TYPE_(Tuple, k9)> type;
|
||||
static type GetSelectedFields(const Tuple& t) {
|
||||
using ::std::tr1::get;
|
||||
return type(get<k0>(t), get<k1>(t), get<k2>(t), get<k3>(t), get<k4>(t),
|
||||
get<k5>(t), get<k6>(t), get<k7>(t), get<k8>(t), get<k9>(t));
|
||||
}
|
||||
@@ -90,9 +89,8 @@ class TupleFields {
|
||||
template <class Tuple>
|
||||
class TupleFields<Tuple, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1> {
|
||||
public:
|
||||
typedef ::std::tr1::tuple<> type;
|
||||
typedef ::testing::tuple<> type;
|
||||
static type GetSelectedFields(const Tuple& /* t */) {
|
||||
using ::std::tr1::get;
|
||||
return type();
|
||||
}
|
||||
};
|
||||
@@ -100,9 +98,8 @@ class TupleFields<Tuple, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1> {
|
||||
template <class Tuple, int k0>
|
||||
class TupleFields<Tuple, k0, -1, -1, -1, -1, -1, -1, -1, -1, -1> {
|
||||
public:
|
||||
typedef ::std::tr1::tuple<GMOCK_FIELD_TYPE_(Tuple, k0)> type;
|
||||
typedef ::testing::tuple<GMOCK_FIELD_TYPE_(Tuple, k0)> type;
|
||||
static type GetSelectedFields(const Tuple& t) {
|
||||
using ::std::tr1::get;
|
||||
return type(get<k0>(t));
|
||||
}
|
||||
};
|
||||
@@ -110,10 +107,9 @@ class TupleFields<Tuple, k0, -1, -1, -1, -1, -1, -1, -1, -1, -1> {
|
||||
template <class Tuple, int k0, int k1>
|
||||
class TupleFields<Tuple, k0, k1, -1, -1, -1, -1, -1, -1, -1, -1> {
|
||||
public:
|
||||
typedef ::std::tr1::tuple<GMOCK_FIELD_TYPE_(Tuple, k0),
|
||||
typedef ::testing::tuple<GMOCK_FIELD_TYPE_(Tuple, k0),
|
||||
GMOCK_FIELD_TYPE_(Tuple, k1)> type;
|
||||
static type GetSelectedFields(const Tuple& t) {
|
||||
using ::std::tr1::get;
|
||||
return type(get<k0>(t), get<k1>(t));
|
||||
}
|
||||
};
|
||||
@@ -121,10 +117,9 @@ class TupleFields<Tuple, k0, k1, -1, -1, -1, -1, -1, -1, -1, -1> {
|
||||
template <class Tuple, int k0, int k1, int k2>
|
||||
class TupleFields<Tuple, k0, k1, k2, -1, -1, -1, -1, -1, -1, -1> {
|
||||
public:
|
||||
typedef ::std::tr1::tuple<GMOCK_FIELD_TYPE_(Tuple, k0),
|
||||
typedef ::testing::tuple<GMOCK_FIELD_TYPE_(Tuple, k0),
|
||||
GMOCK_FIELD_TYPE_(Tuple, k1), GMOCK_FIELD_TYPE_(Tuple, k2)> type;
|
||||
static type GetSelectedFields(const Tuple& t) {
|
||||
using ::std::tr1::get;
|
||||
return type(get<k0>(t), get<k1>(t), get<k2>(t));
|
||||
}
|
||||
};
|
||||
@@ -132,11 +127,10 @@ class TupleFields<Tuple, k0, k1, k2, -1, -1, -1, -1, -1, -1, -1> {
|
||||
template <class Tuple, int k0, int k1, int k2, int k3>
|
||||
class TupleFields<Tuple, k0, k1, k2, k3, -1, -1, -1, -1, -1, -1> {
|
||||
public:
|
||||
typedef ::std::tr1::tuple<GMOCK_FIELD_TYPE_(Tuple, k0),
|
||||
typedef ::testing::tuple<GMOCK_FIELD_TYPE_(Tuple, k0),
|
||||
GMOCK_FIELD_TYPE_(Tuple, k1), GMOCK_FIELD_TYPE_(Tuple, k2),
|
||||
GMOCK_FIELD_TYPE_(Tuple, k3)> type;
|
||||
static type GetSelectedFields(const Tuple& t) {
|
||||
using ::std::tr1::get;
|
||||
return type(get<k0>(t), get<k1>(t), get<k2>(t), get<k3>(t));
|
||||
}
|
||||
};
|
||||
@@ -144,11 +138,10 @@ class TupleFields<Tuple, k0, k1, k2, k3, -1, -1, -1, -1, -1, -1> {
|
||||
template <class Tuple, int k0, int k1, int k2, int k3, int k4>
|
||||
class TupleFields<Tuple, k0, k1, k2, k3, k4, -1, -1, -1, -1, -1> {
|
||||
public:
|
||||
typedef ::std::tr1::tuple<GMOCK_FIELD_TYPE_(Tuple, k0),
|
||||
typedef ::testing::tuple<GMOCK_FIELD_TYPE_(Tuple, k0),
|
||||
GMOCK_FIELD_TYPE_(Tuple, k1), GMOCK_FIELD_TYPE_(Tuple, k2),
|
||||
GMOCK_FIELD_TYPE_(Tuple, k3), GMOCK_FIELD_TYPE_(Tuple, k4)> type;
|
||||
static type GetSelectedFields(const Tuple& t) {
|
||||
using ::std::tr1::get;
|
||||
return type(get<k0>(t), get<k1>(t), get<k2>(t), get<k3>(t), get<k4>(t));
|
||||
}
|
||||
};
|
||||
@@ -156,12 +149,11 @@ class TupleFields<Tuple, k0, k1, k2, k3, k4, -1, -1, -1, -1, -1> {
|
||||
template <class Tuple, int k0, int k1, int k2, int k3, int k4, int k5>
|
||||
class TupleFields<Tuple, k0, k1, k2, k3, k4, k5, -1, -1, -1, -1> {
|
||||
public:
|
||||
typedef ::std::tr1::tuple<GMOCK_FIELD_TYPE_(Tuple, k0),
|
||||
typedef ::testing::tuple<GMOCK_FIELD_TYPE_(Tuple, k0),
|
||||
GMOCK_FIELD_TYPE_(Tuple, k1), GMOCK_FIELD_TYPE_(Tuple, k2),
|
||||
GMOCK_FIELD_TYPE_(Tuple, k3), GMOCK_FIELD_TYPE_(Tuple, k4),
|
||||
GMOCK_FIELD_TYPE_(Tuple, k5)> type;
|
||||
static type GetSelectedFields(const Tuple& t) {
|
||||
using ::std::tr1::get;
|
||||
return type(get<k0>(t), get<k1>(t), get<k2>(t), get<k3>(t), get<k4>(t),
|
||||
get<k5>(t));
|
||||
}
|
||||
@@ -170,12 +162,11 @@ class TupleFields<Tuple, k0, k1, k2, k3, k4, k5, -1, -1, -1, -1> {
|
||||
template <class Tuple, int k0, int k1, int k2, int k3, int k4, int k5, int k6>
|
||||
class TupleFields<Tuple, k0, k1, k2, k3, k4, k5, k6, -1, -1, -1> {
|
||||
public:
|
||||
typedef ::std::tr1::tuple<GMOCK_FIELD_TYPE_(Tuple, k0),
|
||||
typedef ::testing::tuple<GMOCK_FIELD_TYPE_(Tuple, k0),
|
||||
GMOCK_FIELD_TYPE_(Tuple, k1), GMOCK_FIELD_TYPE_(Tuple, k2),
|
||||
GMOCK_FIELD_TYPE_(Tuple, k3), GMOCK_FIELD_TYPE_(Tuple, k4),
|
||||
GMOCK_FIELD_TYPE_(Tuple, k5), GMOCK_FIELD_TYPE_(Tuple, k6)> type;
|
||||
static type GetSelectedFields(const Tuple& t) {
|
||||
using ::std::tr1::get;
|
||||
return type(get<k0>(t), get<k1>(t), get<k2>(t), get<k3>(t), get<k4>(t),
|
||||
get<k5>(t), get<k6>(t));
|
||||
}
|
||||
@@ -185,13 +176,12 @@ template <class Tuple, int k0, int k1, int k2, int k3, int k4, int k5, int k6,
|
||||
int k7>
|
||||
class TupleFields<Tuple, k0, k1, k2, k3, k4, k5, k6, k7, -1, -1> {
|
||||
public:
|
||||
typedef ::std::tr1::tuple<GMOCK_FIELD_TYPE_(Tuple, k0),
|
||||
typedef ::testing::tuple<GMOCK_FIELD_TYPE_(Tuple, k0),
|
||||
GMOCK_FIELD_TYPE_(Tuple, k1), GMOCK_FIELD_TYPE_(Tuple, k2),
|
||||
GMOCK_FIELD_TYPE_(Tuple, k3), GMOCK_FIELD_TYPE_(Tuple, k4),
|
||||
GMOCK_FIELD_TYPE_(Tuple, k5), GMOCK_FIELD_TYPE_(Tuple, k6),
|
||||
GMOCK_FIELD_TYPE_(Tuple, k7)> type;
|
||||
static type GetSelectedFields(const Tuple& t) {
|
||||
using ::std::tr1::get;
|
||||
return type(get<k0>(t), get<k1>(t), get<k2>(t), get<k3>(t), get<k4>(t),
|
||||
get<k5>(t), get<k6>(t), get<k7>(t));
|
||||
}
|
||||
@@ -201,13 +191,12 @@ template <class Tuple, int k0, int k1, int k2, int k3, int k4, int k5, int k6,
|
||||
int k7, int k8>
|
||||
class TupleFields<Tuple, k0, k1, k2, k3, k4, k5, k6, k7, k8, -1> {
|
||||
public:
|
||||
typedef ::std::tr1::tuple<GMOCK_FIELD_TYPE_(Tuple, k0),
|
||||
typedef ::testing::tuple<GMOCK_FIELD_TYPE_(Tuple, k0),
|
||||
GMOCK_FIELD_TYPE_(Tuple, k1), GMOCK_FIELD_TYPE_(Tuple, k2),
|
||||
GMOCK_FIELD_TYPE_(Tuple, k3), GMOCK_FIELD_TYPE_(Tuple, k4),
|
||||
GMOCK_FIELD_TYPE_(Tuple, k5), GMOCK_FIELD_TYPE_(Tuple, k6),
|
||||
GMOCK_FIELD_TYPE_(Tuple, k7), GMOCK_FIELD_TYPE_(Tuple, k8)> type;
|
||||
static type GetSelectedFields(const Tuple& t) {
|
||||
using ::std::tr1::get;
|
||||
return type(get<k0>(t), get<k1>(t), get<k2>(t), get<k3>(t), get<k4>(t),
|
||||
get<k5>(t), get<k6>(t), get<k7>(t), get<k8>(t));
|
||||
}
|
||||
@@ -577,29 +566,29 @@ Args(const InnerMatcher& matcher) {
|
||||
// undefined (e.g. hash_map).
|
||||
|
||||
inline internal::ElementsAreMatcher<
|
||||
std::tr1::tuple<> >
|
||||
::testing::tuple<> >
|
||||
ElementsAre() {
|
||||
typedef std::tr1::tuple<> Args;
|
||||
typedef ::testing::tuple<> Args;
|
||||
return internal::ElementsAreMatcher<Args>(Args());
|
||||
}
|
||||
|
||||
template <typename T1>
|
||||
inline internal::ElementsAreMatcher<
|
||||
std::tr1::tuple<
|
||||
::testing::tuple<
|
||||
typename internal::DecayArray<T1>::type> >
|
||||
ElementsAre(const T1& e1) {
|
||||
typedef std::tr1::tuple<
|
||||
typedef ::testing::tuple<
|
||||
typename internal::DecayArray<T1>::type> Args;
|
||||
return internal::ElementsAreMatcher<Args>(Args(e1));
|
||||
}
|
||||
|
||||
template <typename T1, typename T2>
|
||||
inline internal::ElementsAreMatcher<
|
||||
std::tr1::tuple<
|
||||
::testing::tuple<
|
||||
typename internal::DecayArray<T1>::type,
|
||||
typename internal::DecayArray<T2>::type> >
|
||||
ElementsAre(const T1& e1, const T2& e2) {
|
||||
typedef std::tr1::tuple<
|
||||
typedef ::testing::tuple<
|
||||
typename internal::DecayArray<T1>::type,
|
||||
typename internal::DecayArray<T2>::type> Args;
|
||||
return internal::ElementsAreMatcher<Args>(Args(e1, e2));
|
||||
@@ -607,12 +596,12 @@ ElementsAre(const T1& e1, const T2& e2) {
|
||||
|
||||
template <typename T1, typename T2, typename T3>
|
||||
inline internal::ElementsAreMatcher<
|
||||
std::tr1::tuple<
|
||||
::testing::tuple<
|
||||
typename internal::DecayArray<T1>::type,
|
||||
typename internal::DecayArray<T2>::type,
|
||||
typename internal::DecayArray<T3>::type> >
|
||||
ElementsAre(const T1& e1, const T2& e2, const T3& e3) {
|
||||
typedef std::tr1::tuple<
|
||||
typedef ::testing::tuple<
|
||||
typename internal::DecayArray<T1>::type,
|
||||
typename internal::DecayArray<T2>::type,
|
||||
typename internal::DecayArray<T3>::type> Args;
|
||||
@@ -621,13 +610,13 @@ ElementsAre(const T1& e1, const T2& e2, const T3& e3) {
|
||||
|
||||
template <typename T1, typename T2, typename T3, typename T4>
|
||||
inline internal::ElementsAreMatcher<
|
||||
std::tr1::tuple<
|
||||
::testing::tuple<
|
||||
typename internal::DecayArray<T1>::type,
|
||||
typename internal::DecayArray<T2>::type,
|
||||
typename internal::DecayArray<T3>::type,
|
||||
typename internal::DecayArray<T4>::type> >
|
||||
ElementsAre(const T1& e1, const T2& e2, const T3& e3, const T4& e4) {
|
||||
typedef std::tr1::tuple<
|
||||
typedef ::testing::tuple<
|
||||
typename internal::DecayArray<T1>::type,
|
||||
typename internal::DecayArray<T2>::type,
|
||||
typename internal::DecayArray<T3>::type,
|
||||
@@ -637,7 +626,7 @@ ElementsAre(const T1& e1, const T2& e2, const T3& e3, const T4& e4) {
|
||||
|
||||
template <typename T1, typename T2, typename T3, typename T4, typename T5>
|
||||
inline internal::ElementsAreMatcher<
|
||||
std::tr1::tuple<
|
||||
::testing::tuple<
|
||||
typename internal::DecayArray<T1>::type,
|
||||
typename internal::DecayArray<T2>::type,
|
||||
typename internal::DecayArray<T3>::type,
|
||||
@@ -645,7 +634,7 @@ inline internal::ElementsAreMatcher<
|
||||
typename internal::DecayArray<T5>::type> >
|
||||
ElementsAre(const T1& e1, const T2& e2, const T3& e3, const T4& e4,
|
||||
const T5& e5) {
|
||||
typedef std::tr1::tuple<
|
||||
typedef ::testing::tuple<
|
||||
typename internal::DecayArray<T1>::type,
|
||||
typename internal::DecayArray<T2>::type,
|
||||
typename internal::DecayArray<T3>::type,
|
||||
@@ -657,7 +646,7 @@ ElementsAre(const T1& e1, const T2& e2, const T3& e3, const T4& e4,
|
||||
template <typename T1, typename T2, typename T3, typename T4, typename T5,
|
||||
typename T6>
|
||||
inline internal::ElementsAreMatcher<
|
||||
std::tr1::tuple<
|
||||
::testing::tuple<
|
||||
typename internal::DecayArray<T1>::type,
|
||||
typename internal::DecayArray<T2>::type,
|
||||
typename internal::DecayArray<T3>::type,
|
||||
@@ -666,7 +655,7 @@ inline internal::ElementsAreMatcher<
|
||||
typename internal::DecayArray<T6>::type> >
|
||||
ElementsAre(const T1& e1, const T2& e2, const T3& e3, const T4& e4,
|
||||
const T5& e5, const T6& e6) {
|
||||
typedef std::tr1::tuple<
|
||||
typedef ::testing::tuple<
|
||||
typename internal::DecayArray<T1>::type,
|
||||
typename internal::DecayArray<T2>::type,
|
||||
typename internal::DecayArray<T3>::type,
|
||||
@@ -679,7 +668,7 @@ ElementsAre(const T1& e1, const T2& e2, const T3& e3, const T4& e4,
|
||||
template <typename T1, typename T2, typename T3, typename T4, typename T5,
|
||||
typename T6, typename T7>
|
||||
inline internal::ElementsAreMatcher<
|
||||
std::tr1::tuple<
|
||||
::testing::tuple<
|
||||
typename internal::DecayArray<T1>::type,
|
||||
typename internal::DecayArray<T2>::type,
|
||||
typename internal::DecayArray<T3>::type,
|
||||
@@ -689,7 +678,7 @@ inline internal::ElementsAreMatcher<
|
||||
typename internal::DecayArray<T7>::type> >
|
||||
ElementsAre(const T1& e1, const T2& e2, const T3& e3, const T4& e4,
|
||||
const T5& e5, const T6& e6, const T7& e7) {
|
||||
typedef std::tr1::tuple<
|
||||
typedef ::testing::tuple<
|
||||
typename internal::DecayArray<T1>::type,
|
||||
typename internal::DecayArray<T2>::type,
|
||||
typename internal::DecayArray<T3>::type,
|
||||
@@ -703,7 +692,7 @@ ElementsAre(const T1& e1, const T2& e2, const T3& e3, const T4& e4,
|
||||
template <typename T1, typename T2, typename T3, typename T4, typename T5,
|
||||
typename T6, typename T7, typename T8>
|
||||
inline internal::ElementsAreMatcher<
|
||||
std::tr1::tuple<
|
||||
::testing::tuple<
|
||||
typename internal::DecayArray<T1>::type,
|
||||
typename internal::DecayArray<T2>::type,
|
||||
typename internal::DecayArray<T3>::type,
|
||||
@@ -714,7 +703,7 @@ inline internal::ElementsAreMatcher<
|
||||
typename internal::DecayArray<T8>::type> >
|
||||
ElementsAre(const T1& e1, const T2& e2, const T3& e3, const T4& e4,
|
||||
const T5& e5, const T6& e6, const T7& e7, const T8& e8) {
|
||||
typedef std::tr1::tuple<
|
||||
typedef ::testing::tuple<
|
||||
typename internal::DecayArray<T1>::type,
|
||||
typename internal::DecayArray<T2>::type,
|
||||
typename internal::DecayArray<T3>::type,
|
||||
@@ -730,7 +719,7 @@ ElementsAre(const T1& e1, const T2& e2, const T3& e3, const T4& e4,
|
||||
template <typename T1, typename T2, typename T3, typename T4, typename T5,
|
||||
typename T6, typename T7, typename T8, typename T9>
|
||||
inline internal::ElementsAreMatcher<
|
||||
std::tr1::tuple<
|
||||
::testing::tuple<
|
||||
typename internal::DecayArray<T1>::type,
|
||||
typename internal::DecayArray<T2>::type,
|
||||
typename internal::DecayArray<T3>::type,
|
||||
@@ -742,7 +731,7 @@ inline internal::ElementsAreMatcher<
|
||||
typename internal::DecayArray<T9>::type> >
|
||||
ElementsAre(const T1& e1, const T2& e2, const T3& e3, const T4& e4,
|
||||
const T5& e5, const T6& e6, const T7& e7, const T8& e8, const T9& e9) {
|
||||
typedef std::tr1::tuple<
|
||||
typedef ::testing::tuple<
|
||||
typename internal::DecayArray<T1>::type,
|
||||
typename internal::DecayArray<T2>::type,
|
||||
typename internal::DecayArray<T3>::type,
|
||||
@@ -759,7 +748,7 @@ ElementsAre(const T1& e1, const T2& e2, const T3& e3, const T4& e4,
|
||||
template <typename T1, typename T2, typename T3, typename T4, typename T5,
|
||||
typename T6, typename T7, typename T8, typename T9, typename T10>
|
||||
inline internal::ElementsAreMatcher<
|
||||
std::tr1::tuple<
|
||||
::testing::tuple<
|
||||
typename internal::DecayArray<T1>::type,
|
||||
typename internal::DecayArray<T2>::type,
|
||||
typename internal::DecayArray<T3>::type,
|
||||
@@ -773,7 +762,7 @@ inline internal::ElementsAreMatcher<
|
||||
ElementsAre(const T1& e1, const T2& e2, const T3& e3, const T4& e4,
|
||||
const T5& e5, const T6& e6, const T7& e7, const T8& e8, const T9& e9,
|
||||
const T10& e10) {
|
||||
typedef std::tr1::tuple<
|
||||
typedef ::testing::tuple<
|
||||
typename internal::DecayArray<T1>::type,
|
||||
typename internal::DecayArray<T2>::type,
|
||||
typename internal::DecayArray<T3>::type,
|
||||
@@ -792,29 +781,29 @@ ElementsAre(const T1& e1, const T2& e2, const T3& e3, const T4& e4,
|
||||
// that matches n elements in any order. We support up to n=10 arguments.
|
||||
|
||||
inline internal::UnorderedElementsAreMatcher<
|
||||
std::tr1::tuple<> >
|
||||
::testing::tuple<> >
|
||||
UnorderedElementsAre() {
|
||||
typedef std::tr1::tuple<> Args;
|
||||
typedef ::testing::tuple<> Args;
|
||||
return internal::UnorderedElementsAreMatcher<Args>(Args());
|
||||
}
|
||||
|
||||
template <typename T1>
|
||||
inline internal::UnorderedElementsAreMatcher<
|
||||
std::tr1::tuple<
|
||||
::testing::tuple<
|
||||
typename internal::DecayArray<T1>::type> >
|
||||
UnorderedElementsAre(const T1& e1) {
|
||||
typedef std::tr1::tuple<
|
||||
typedef ::testing::tuple<
|
||||
typename internal::DecayArray<T1>::type> Args;
|
||||
return internal::UnorderedElementsAreMatcher<Args>(Args(e1));
|
||||
}
|
||||
|
||||
template <typename T1, typename T2>
|
||||
inline internal::UnorderedElementsAreMatcher<
|
||||
std::tr1::tuple<
|
||||
::testing::tuple<
|
||||
typename internal::DecayArray<T1>::type,
|
||||
typename internal::DecayArray<T2>::type> >
|
||||
UnorderedElementsAre(const T1& e1, const T2& e2) {
|
||||
typedef std::tr1::tuple<
|
||||
typedef ::testing::tuple<
|
||||
typename internal::DecayArray<T1>::type,
|
||||
typename internal::DecayArray<T2>::type> Args;
|
||||
return internal::UnorderedElementsAreMatcher<Args>(Args(e1, e2));
|
||||
@@ -822,12 +811,12 @@ UnorderedElementsAre(const T1& e1, const T2& e2) {
|
||||
|
||||
template <typename T1, typename T2, typename T3>
|
||||
inline internal::UnorderedElementsAreMatcher<
|
||||
std::tr1::tuple<
|
||||
::testing::tuple<
|
||||
typename internal::DecayArray<T1>::type,
|
||||
typename internal::DecayArray<T2>::type,
|
||||
typename internal::DecayArray<T3>::type> >
|
||||
UnorderedElementsAre(const T1& e1, const T2& e2, const T3& e3) {
|
||||
typedef std::tr1::tuple<
|
||||
typedef ::testing::tuple<
|
||||
typename internal::DecayArray<T1>::type,
|
||||
typename internal::DecayArray<T2>::type,
|
||||
typename internal::DecayArray<T3>::type> Args;
|
||||
@@ -836,13 +825,13 @@ UnorderedElementsAre(const T1& e1, const T2& e2, const T3& e3) {
|
||||
|
||||
template <typename T1, typename T2, typename T3, typename T4>
|
||||
inline internal::UnorderedElementsAreMatcher<
|
||||
std::tr1::tuple<
|
||||
::testing::tuple<
|
||||
typename internal::DecayArray<T1>::type,
|
||||
typename internal::DecayArray<T2>::type,
|
||||
typename internal::DecayArray<T3>::type,
|
||||
typename internal::DecayArray<T4>::type> >
|
||||
UnorderedElementsAre(const T1& e1, const T2& e2, const T3& e3, const T4& e4) {
|
||||
typedef std::tr1::tuple<
|
||||
typedef ::testing::tuple<
|
||||
typename internal::DecayArray<T1>::type,
|
||||
typename internal::DecayArray<T2>::type,
|
||||
typename internal::DecayArray<T3>::type,
|
||||
@@ -852,7 +841,7 @@ UnorderedElementsAre(const T1& e1, const T2& e2, const T3& e3, const T4& e4) {
|
||||
|
||||
template <typename T1, typename T2, typename T3, typename T4, typename T5>
|
||||
inline internal::UnorderedElementsAreMatcher<
|
||||
std::tr1::tuple<
|
||||
::testing::tuple<
|
||||
typename internal::DecayArray<T1>::type,
|
||||
typename internal::DecayArray<T2>::type,
|
||||
typename internal::DecayArray<T3>::type,
|
||||
@@ -860,7 +849,7 @@ inline internal::UnorderedElementsAreMatcher<
|
||||
typename internal::DecayArray<T5>::type> >
|
||||
UnorderedElementsAre(const T1& e1, const T2& e2, const T3& e3, const T4& e4,
|
||||
const T5& e5) {
|
||||
typedef std::tr1::tuple<
|
||||
typedef ::testing::tuple<
|
||||
typename internal::DecayArray<T1>::type,
|
||||
typename internal::DecayArray<T2>::type,
|
||||
typename internal::DecayArray<T3>::type,
|
||||
@@ -872,7 +861,7 @@ UnorderedElementsAre(const T1& e1, const T2& e2, const T3& e3, const T4& e4,
|
||||
template <typename T1, typename T2, typename T3, typename T4, typename T5,
|
||||
typename T6>
|
||||
inline internal::UnorderedElementsAreMatcher<
|
||||
std::tr1::tuple<
|
||||
::testing::tuple<
|
||||
typename internal::DecayArray<T1>::type,
|
||||
typename internal::DecayArray<T2>::type,
|
||||
typename internal::DecayArray<T3>::type,
|
||||
@@ -881,7 +870,7 @@ inline internal::UnorderedElementsAreMatcher<
|
||||
typename internal::DecayArray<T6>::type> >
|
||||
UnorderedElementsAre(const T1& e1, const T2& e2, const T3& e3, const T4& e4,
|
||||
const T5& e5, const T6& e6) {
|
||||
typedef std::tr1::tuple<
|
||||
typedef ::testing::tuple<
|
||||
typename internal::DecayArray<T1>::type,
|
||||
typename internal::DecayArray<T2>::type,
|
||||
typename internal::DecayArray<T3>::type,
|
||||
@@ -895,7 +884,7 @@ UnorderedElementsAre(const T1& e1, const T2& e2, const T3& e3, const T4& e4,
|
||||
template <typename T1, typename T2, typename T3, typename T4, typename T5,
|
||||
typename T6, typename T7>
|
||||
inline internal::UnorderedElementsAreMatcher<
|
||||
std::tr1::tuple<
|
||||
::testing::tuple<
|
||||
typename internal::DecayArray<T1>::type,
|
||||
typename internal::DecayArray<T2>::type,
|
||||
typename internal::DecayArray<T3>::type,
|
||||
@@ -905,7 +894,7 @@ inline internal::UnorderedElementsAreMatcher<
|
||||
typename internal::DecayArray<T7>::type> >
|
||||
UnorderedElementsAre(const T1& e1, const T2& e2, const T3& e3, const T4& e4,
|
||||
const T5& e5, const T6& e6, const T7& e7) {
|
||||
typedef std::tr1::tuple<
|
||||
typedef ::testing::tuple<
|
||||
typename internal::DecayArray<T1>::type,
|
||||
typename internal::DecayArray<T2>::type,
|
||||
typename internal::DecayArray<T3>::type,
|
||||
@@ -920,7 +909,7 @@ UnorderedElementsAre(const T1& e1, const T2& e2, const T3& e3, const T4& e4,
|
||||
template <typename T1, typename T2, typename T3, typename T4, typename T5,
|
||||
typename T6, typename T7, typename T8>
|
||||
inline internal::UnorderedElementsAreMatcher<
|
||||
std::tr1::tuple<
|
||||
::testing::tuple<
|
||||
typename internal::DecayArray<T1>::type,
|
||||
typename internal::DecayArray<T2>::type,
|
||||
typename internal::DecayArray<T3>::type,
|
||||
@@ -931,7 +920,7 @@ inline internal::UnorderedElementsAreMatcher<
|
||||
typename internal::DecayArray<T8>::type> >
|
||||
UnorderedElementsAre(const T1& e1, const T2& e2, const T3& e3, const T4& e4,
|
||||
const T5& e5, const T6& e6, const T7& e7, const T8& e8) {
|
||||
typedef std::tr1::tuple<
|
||||
typedef ::testing::tuple<
|
||||
typename internal::DecayArray<T1>::type,
|
||||
typename internal::DecayArray<T2>::type,
|
||||
typename internal::DecayArray<T3>::type,
|
||||
@@ -947,7 +936,7 @@ UnorderedElementsAre(const T1& e1, const T2& e2, const T3& e3, const T4& e4,
|
||||
template <typename T1, typename T2, typename T3, typename T4, typename T5,
|
||||
typename T6, typename T7, typename T8, typename T9>
|
||||
inline internal::UnorderedElementsAreMatcher<
|
||||
std::tr1::tuple<
|
||||
::testing::tuple<
|
||||
typename internal::DecayArray<T1>::type,
|
||||
typename internal::DecayArray<T2>::type,
|
||||
typename internal::DecayArray<T3>::type,
|
||||
@@ -959,7 +948,7 @@ inline internal::UnorderedElementsAreMatcher<
|
||||
typename internal::DecayArray<T9>::type> >
|
||||
UnorderedElementsAre(const T1& e1, const T2& e2, const T3& e3, const T4& e4,
|
||||
const T5& e5, const T6& e6, const T7& e7, const T8& e8, const T9& e9) {
|
||||
typedef std::tr1::tuple<
|
||||
typedef ::testing::tuple<
|
||||
typename internal::DecayArray<T1>::type,
|
||||
typename internal::DecayArray<T2>::type,
|
||||
typename internal::DecayArray<T3>::type,
|
||||
@@ -976,7 +965,7 @@ UnorderedElementsAre(const T1& e1, const T2& e2, const T3& e3, const T4& e4,
|
||||
template <typename T1, typename T2, typename T3, typename T4, typename T5,
|
||||
typename T6, typename T7, typename T8, typename T9, typename T10>
|
||||
inline internal::UnorderedElementsAreMatcher<
|
||||
std::tr1::tuple<
|
||||
::testing::tuple<
|
||||
typename internal::DecayArray<T1>::type,
|
||||
typename internal::DecayArray<T2>::type,
|
||||
typename internal::DecayArray<T3>::type,
|
||||
@@ -990,7 +979,7 @@ inline internal::UnorderedElementsAreMatcher<
|
||||
UnorderedElementsAre(const T1& e1, const T2& e2, const T3& e3, const T4& e4,
|
||||
const T5& e5, const T6& e6, const T7& e7, const T8& e8, const T9& e9,
|
||||
const T10& e10) {
|
||||
typedef std::tr1::tuple<
|
||||
typedef ::testing::tuple<
|
||||
typename internal::DecayArray<T1>::type,
|
||||
typename internal::DecayArray<T2>::type,
|
||||
typename internal::DecayArray<T3>::type,
|
||||
@@ -1413,7 +1402,7 @@ AnyOf(M1 m1, M2 m2, M3 m3, M4 m4, M5 m5, M6 m6, M7 m7, M8 m8, M9 m9, M10 m10) {
|
||||
return ::testing::internal::FormatMatcherDescription(\
|
||||
negation, #name, \
|
||||
::testing::internal::UniversalTersePrintTupleFieldsToStrings(\
|
||||
::std::tr1::tuple<>()));\
|
||||
::testing::tuple<>()));\
|
||||
}\
|
||||
GTEST_DISALLOW_ASSIGN_(gmock_Impl);\
|
||||
};\
|
||||
@@ -1462,7 +1451,7 @@ AnyOf(M1 m1, M2 m2, M3 m3, M4 m4, M5 m5, M6 m6, M7 m7, M8 m8, M9 m9, M10 m10) {
|
||||
return ::testing::internal::FormatMatcherDescription(\
|
||||
negation, #name, \
|
||||
::testing::internal::UniversalTersePrintTupleFieldsToStrings(\
|
||||
::std::tr1::tuple<p0##_type>(p0)));\
|
||||
::testing::tuple<p0##_type>(p0)));\
|
||||
}\
|
||||
GTEST_DISALLOW_ASSIGN_(gmock_Impl);\
|
||||
};\
|
||||
@@ -1471,7 +1460,7 @@ AnyOf(M1 m1, M2 m2, M3 m3, M4 m4, M5 m5, M6 m6, M7 m7, M8 m8, M9 m9, M10 m10) {
|
||||
return ::testing::Matcher<arg_type>(\
|
||||
new gmock_Impl<arg_type>(p0));\
|
||||
}\
|
||||
name##MatcherP(p0##_type gmock_p0) : p0(gmock_p0) {\
|
||||
explicit name##MatcherP(p0##_type gmock_p0) : p0(gmock_p0) {\
|
||||
}\
|
||||
p0##_type p0;\
|
||||
private:\
|
||||
@@ -1515,7 +1504,7 @@ AnyOf(M1 m1, M2 m2, M3 m3, M4 m4, M5 m5, M6 m6, M7 m7, M8 m8, M9 m9, M10 m10) {
|
||||
return ::testing::internal::FormatMatcherDescription(\
|
||||
negation, #name, \
|
||||
::testing::internal::UniversalTersePrintTupleFieldsToStrings(\
|
||||
::std::tr1::tuple<p0##_type, p1##_type>(p0, p1)));\
|
||||
::testing::tuple<p0##_type, p1##_type>(p0, p1)));\
|
||||
}\
|
||||
GTEST_DISALLOW_ASSIGN_(gmock_Impl);\
|
||||
};\
|
||||
@@ -1573,7 +1562,7 @@ AnyOf(M1 m1, M2 m2, M3 m3, M4 m4, M5 m5, M6 m6, M7 m7, M8 m8, M9 m9, M10 m10) {
|
||||
return ::testing::internal::FormatMatcherDescription(\
|
||||
negation, #name, \
|
||||
::testing::internal::UniversalTersePrintTupleFieldsToStrings(\
|
||||
::std::tr1::tuple<p0##_type, p1##_type, p2##_type>(p0, p1, \
|
||||
::testing::tuple<p0##_type, p1##_type, p2##_type>(p0, p1, \
|
||||
p2)));\
|
||||
}\
|
||||
GTEST_DISALLOW_ASSIGN_(gmock_Impl);\
|
||||
@@ -1636,7 +1625,7 @@ AnyOf(M1 m1, M2 m2, M3 m3, M4 m4, M5 m5, M6 m6, M7 m7, M8 m8, M9 m9, M10 m10) {
|
||||
return ::testing::internal::FormatMatcherDescription(\
|
||||
negation, #name, \
|
||||
::testing::internal::UniversalTersePrintTupleFieldsToStrings(\
|
||||
::std::tr1::tuple<p0##_type, p1##_type, p2##_type, \
|
||||
::testing::tuple<p0##_type, p1##_type, p2##_type, \
|
||||
p3##_type>(p0, p1, p2, p3)));\
|
||||
}\
|
||||
GTEST_DISALLOW_ASSIGN_(gmock_Impl);\
|
||||
@@ -1707,7 +1696,7 @@ AnyOf(M1 m1, M2 m2, M3 m3, M4 m4, M5 m5, M6 m6, M7 m7, M8 m8, M9 m9, M10 m10) {
|
||||
return ::testing::internal::FormatMatcherDescription(\
|
||||
negation, #name, \
|
||||
::testing::internal::UniversalTersePrintTupleFieldsToStrings(\
|
||||
::std::tr1::tuple<p0##_type, p1##_type, p2##_type, p3##_type, \
|
||||
::testing::tuple<p0##_type, p1##_type, p2##_type, p3##_type, \
|
||||
p4##_type>(p0, p1, p2, p3, p4)));\
|
||||
}\
|
||||
GTEST_DISALLOW_ASSIGN_(gmock_Impl);\
|
||||
@@ -1781,7 +1770,7 @@ AnyOf(M1 m1, M2 m2, M3 m3, M4 m4, M5 m5, M6 m6, M7 m7, M8 m8, M9 m9, M10 m10) {
|
||||
return ::testing::internal::FormatMatcherDescription(\
|
||||
negation, #name, \
|
||||
::testing::internal::UniversalTersePrintTupleFieldsToStrings(\
|
||||
::std::tr1::tuple<p0##_type, p1##_type, p2##_type, p3##_type, \
|
||||
::testing::tuple<p0##_type, p1##_type, p2##_type, p3##_type, \
|
||||
p4##_type, p5##_type>(p0, p1, p2, p3, p4, p5)));\
|
||||
}\
|
||||
GTEST_DISALLOW_ASSIGN_(gmock_Impl);\
|
||||
@@ -1859,7 +1848,7 @@ AnyOf(M1 m1, M2 m2, M3 m3, M4 m4, M5 m5, M6 m6, M7 m7, M8 m8, M9 m9, M10 m10) {
|
||||
return ::testing::internal::FormatMatcherDescription(\
|
||||
negation, #name, \
|
||||
::testing::internal::UniversalTersePrintTupleFieldsToStrings(\
|
||||
::std::tr1::tuple<p0##_type, p1##_type, p2##_type, p3##_type, \
|
||||
::testing::tuple<p0##_type, p1##_type, p2##_type, p3##_type, \
|
||||
p4##_type, p5##_type, p6##_type>(p0, p1, p2, p3, p4, p5, \
|
||||
p6)));\
|
||||
}\
|
||||
@@ -1944,7 +1933,7 @@ AnyOf(M1 m1, M2 m2, M3 m3, M4 m4, M5 m5, M6 m6, M7 m7, M8 m8, M9 m9, M10 m10) {
|
||||
return ::testing::internal::FormatMatcherDescription(\
|
||||
negation, #name, \
|
||||
::testing::internal::UniversalTersePrintTupleFieldsToStrings(\
|
||||
::std::tr1::tuple<p0##_type, p1##_type, p2##_type, p3##_type, \
|
||||
::testing::tuple<p0##_type, p1##_type, p2##_type, p3##_type, \
|
||||
p4##_type, p5##_type, p6##_type, p7##_type>(p0, p1, p2, \
|
||||
p3, p4, p5, p6, p7)));\
|
||||
}\
|
||||
@@ -2035,7 +2024,7 @@ AnyOf(M1 m1, M2 m2, M3 m3, M4 m4, M5 m5, M6 m6, M7 m7, M8 m8, M9 m9, M10 m10) {
|
||||
return ::testing::internal::FormatMatcherDescription(\
|
||||
negation, #name, \
|
||||
::testing::internal::UniversalTersePrintTupleFieldsToStrings(\
|
||||
::std::tr1::tuple<p0##_type, p1##_type, p2##_type, p3##_type, \
|
||||
::testing::tuple<p0##_type, p1##_type, p2##_type, p3##_type, \
|
||||
p4##_type, p5##_type, p6##_type, p7##_type, \
|
||||
p8##_type>(p0, p1, p2, p3, p4, p5, p6, p7, p8)));\
|
||||
}\
|
||||
@@ -2131,7 +2120,7 @@ AnyOf(M1 m1, M2 m2, M3 m3, M4 m4, M5 m5, M6 m6, M7 m7, M8 m8, M9 m9, M10 m10) {
|
||||
return ::testing::internal::FormatMatcherDescription(\
|
||||
negation, #name, \
|
||||
::testing::internal::UniversalTersePrintTupleFieldsToStrings(\
|
||||
::std::tr1::tuple<p0##_type, p1##_type, p2##_type, p3##_type, \
|
||||
::testing::tuple<p0##_type, p1##_type, p2##_type, p3##_type, \
|
||||
p4##_type, p5##_type, p6##_type, p7##_type, p8##_type, \
|
||||
p9##_type>(p0, p1, p2, p3, p4, p5, p6, p7, p8, p9)));\
|
||||
}\
|
||||
@@ -53,7 +53,7 @@ $range i 0..n-1
|
||||
|
||||
// The type of the i-th (0-based) field of Tuple.
|
||||
#define GMOCK_FIELD_TYPE_(Tuple, i) \
|
||||
typename ::std::tr1::tuple_element<i, Tuple>::type
|
||||
typename ::testing::tuple_element<i, Tuple>::type
|
||||
|
||||
// TupleFields<Tuple, k0, ..., kn> is for selecting fields from a
|
||||
// tuple of type Tuple. It has two members:
|
||||
@@ -73,9 +73,8 @@ class TupleFields;
|
||||
template <class Tuple$for i [[, int k$i]]>
|
||||
class TupleFields {
|
||||
public:
|
||||
typedef ::std::tr1::tuple<$for i, [[GMOCK_FIELD_TYPE_(Tuple, k$i)]]> type;
|
||||
typedef ::testing::tuple<$for i, [[GMOCK_FIELD_TYPE_(Tuple, k$i)]]> type;
|
||||
static type GetSelectedFields(const Tuple& t) {
|
||||
using ::std::tr1::get;
|
||||
return type($for i, [[get<k$i>(t)]]);
|
||||
}
|
||||
};
|
||||
@@ -90,9 +89,8 @@ $range k 0..n-1
|
||||
template <class Tuple$for j [[, int k$j]]>
|
||||
class TupleFields<Tuple, $for k, [[$if k < i [[k$k]] $else [[-1]]]]> {
|
||||
public:
|
||||
typedef ::std::tr1::tuple<$for j, [[GMOCK_FIELD_TYPE_(Tuple, k$j)]]> type;
|
||||
typedef ::testing::tuple<$for j, [[GMOCK_FIELD_TYPE_(Tuple, k$j)]]> type;
|
||||
static type GetSelectedFields(const Tuple& $if i==0 [[/* t */]] $else [[t]]) {
|
||||
using ::std::tr1::get;
|
||||
return type($for j, [[get<k$j>(t)]]);
|
||||
}
|
||||
};
|
||||
@@ -289,12 +287,12 @@ template <$for j, [[typename T$j]]>
|
||||
]]
|
||||
|
||||
inline internal::ElementsAreMatcher<
|
||||
std::tr1::tuple<
|
||||
::testing::tuple<
|
||||
$for j, [[
|
||||
|
||||
typename internal::DecayArray<T$j[[]]>::type]]> >
|
||||
ElementsAre($for j, [[const T$j& e$j]]) {
|
||||
typedef std::tr1::tuple<
|
||||
typedef ::testing::tuple<
|
||||
$for j, [[
|
||||
|
||||
typename internal::DecayArray<T$j[[]]>::type]]> Args;
|
||||
@@ -317,12 +315,12 @@ template <$for j, [[typename T$j]]>
|
||||
]]
|
||||
|
||||
inline internal::UnorderedElementsAreMatcher<
|
||||
std::tr1::tuple<
|
||||
::testing::tuple<
|
||||
$for j, [[
|
||||
|
||||
typename internal::DecayArray<T$j[[]]>::type]]> >
|
||||
UnorderedElementsAre($for j, [[const T$j& e$j]]) {
|
||||
typedef std::tr1::tuple<
|
||||
typedef ::testing::tuple<
|
||||
$for j, [[
|
||||
|
||||
typename internal::DecayArray<T$j[[]]>::type]]> Args;
|
||||
@@ -646,7 +644,7 @@ $var param_field_decls2 = [[$for j
|
||||
return ::testing::internal::FormatMatcherDescription(\
|
||||
negation, #name, \
|
||||
::testing::internal::UniversalTersePrintTupleFieldsToStrings(\
|
||||
::std::tr1::tuple<$for j, [[p$j##_type]]>($for j, [[p$j]])));\
|
||||
::testing::tuple<$for j, [[p$j##_type]]>($for j, [[p$j]])));\
|
||||
}\
|
||||
GTEST_DISALLOW_ASSIGN_(gmock_Impl);\
|
||||
};\
|
||||
@@ -655,7 +653,7 @@ $var param_field_decls2 = [[$for j
|
||||
return ::testing::Matcher<arg_type>(\
|
||||
new gmock_Impl<arg_type>($params));\
|
||||
}\
|
||||
$class_name($ctor_param_list)$inits {\
|
||||
[[$if i==1 [[explicit ]]]]$class_name($ctor_param_list)$inits {\
|
||||
}\$param_field_decls2
|
||||
private:\
|
||||
GTEST_DISALLOW_ASSIGN_($class_name);\
|
||||
File diff suppressed because it is too large
Load Diff
@@ -72,7 +72,7 @@ template <class Class, typename MethodPtr>
|
||||
class InvokeMethodAction {
|
||||
public:
|
||||
InvokeMethodAction(Class* obj_ptr, MethodPtr method_ptr)
|
||||
: obj_ptr_(obj_ptr), method_ptr_(method_ptr) {}
|
||||
: method_ptr_(method_ptr), obj_ptr_(obj_ptr) {}
|
||||
|
||||
template <typename Result, typename ArgumentTuple>
|
||||
Result Perform(const ArgumentTuple& args) const {
|
||||
@@ -81,12 +81,29 @@ class InvokeMethodAction {
|
||||
}
|
||||
|
||||
private:
|
||||
Class* const obj_ptr_;
|
||||
// The order of these members matters. Reversing the order can trigger
|
||||
// warning C4121 in MSVC (see
|
||||
// http://computer-programming-forum.com/7-vc.net/6fbc30265f860ad1.htm ).
|
||||
const MethodPtr method_ptr_;
|
||||
Class* const obj_ptr_;
|
||||
|
||||
GTEST_DISALLOW_ASSIGN_(InvokeMethodAction);
|
||||
};
|
||||
|
||||
// An internal replacement for std::copy which mimics its behavior. This is
|
||||
// necessary because Visual Studio deprecates ::std::copy, issuing warning 4996.
|
||||
// However Visual Studio 2010 and later do not honor #pragmas which disable that
|
||||
// warning.
|
||||
template<typename InputIterator, typename OutputIterator>
|
||||
inline OutputIterator CopyElements(InputIterator first,
|
||||
InputIterator last,
|
||||
OutputIterator output) {
|
||||
for (; first != last; ++first, ++output) {
|
||||
*output = *first;
|
||||
}
|
||||
return output;
|
||||
}
|
||||
|
||||
} // namespace internal
|
||||
|
||||
// Various overloads for Invoke().
|
||||
@@ -144,7 +161,7 @@ WithArg(const InnerAction& action) {
|
||||
ACTION_TEMPLATE(ReturnArg,
|
||||
HAS_1_TEMPLATE_PARAMS(int, k),
|
||||
AND_0_VALUE_PARAMS()) {
|
||||
return std::tr1::get<k>(args);
|
||||
return ::testing::get<k>(args);
|
||||
}
|
||||
|
||||
// Action SaveArg<k>(pointer) saves the k-th (0-based) argument of the
|
||||
@@ -152,7 +169,7 @@ ACTION_TEMPLATE(ReturnArg,
|
||||
ACTION_TEMPLATE(SaveArg,
|
||||
HAS_1_TEMPLATE_PARAMS(int, k),
|
||||
AND_1_VALUE_PARAMS(pointer)) {
|
||||
*pointer = ::std::tr1::get<k>(args);
|
||||
*pointer = ::testing::get<k>(args);
|
||||
}
|
||||
|
||||
// Action SaveArgPointee<k>(pointer) saves the value pointed to
|
||||
@@ -160,7 +177,7 @@ ACTION_TEMPLATE(SaveArg,
|
||||
ACTION_TEMPLATE(SaveArgPointee,
|
||||
HAS_1_TEMPLATE_PARAMS(int, k),
|
||||
AND_1_VALUE_PARAMS(pointer)) {
|
||||
*pointer = *::std::tr1::get<k>(args);
|
||||
*pointer = *::testing::get<k>(args);
|
||||
}
|
||||
|
||||
// Action SetArgReferee<k>(value) assigns 'value' to the variable
|
||||
@@ -168,13 +185,13 @@ ACTION_TEMPLATE(SaveArgPointee,
|
||||
ACTION_TEMPLATE(SetArgReferee,
|
||||
HAS_1_TEMPLATE_PARAMS(int, k),
|
||||
AND_1_VALUE_PARAMS(value)) {
|
||||
typedef typename ::std::tr1::tuple_element<k, args_type>::type argk_type;
|
||||
typedef typename ::testing::tuple_element<k, args_type>::type argk_type;
|
||||
// Ensures that argument #k is a reference. If you get a compiler
|
||||
// error on the next line, you are using SetArgReferee<k>(value) in
|
||||
// a mock function whose k-th (0-based) argument is not a reference.
|
||||
GTEST_COMPILE_ASSERT_(internal::is_reference<argk_type>::value,
|
||||
SetArgReferee_must_be_used_with_a_reference_argument);
|
||||
::std::tr1::get<k>(args) = value;
|
||||
::testing::get<k>(args) = value;
|
||||
}
|
||||
|
||||
// Action SetArrayArgument<k>(first, last) copies the elements in
|
||||
@@ -185,15 +202,11 @@ ACTION_TEMPLATE(SetArgReferee,
|
||||
ACTION_TEMPLATE(SetArrayArgument,
|
||||
HAS_1_TEMPLATE_PARAMS(int, k),
|
||||
AND_2_VALUE_PARAMS(first, last)) {
|
||||
// Microsoft compiler deprecates ::std::copy, so we want to suppress warning
|
||||
// 4996 (Function call with parameters that may be unsafe) there.
|
||||
// Visual Studio deprecates ::std::copy, so we use our own copy in that case.
|
||||
#ifdef _MSC_VER
|
||||
# pragma warning(push) // Saves the current warning state.
|
||||
# pragma warning(disable:4996) // Temporarily disables warning 4996.
|
||||
#endif
|
||||
::std::copy(first, last, ::std::tr1::get<k>(args));
|
||||
#ifdef _MSC_VER
|
||||
# pragma warning(pop) // Restores the warning state.
|
||||
internal::CopyElements(first, last, ::testing::get<k>(args));
|
||||
#else
|
||||
::std::copy(first, last, ::testing::get<k>(args));
|
||||
#endif
|
||||
}
|
||||
|
||||
@@ -202,7 +215,7 @@ ACTION_TEMPLATE(SetArrayArgument,
|
||||
ACTION_TEMPLATE(DeleteArg,
|
||||
HAS_1_TEMPLATE_PARAMS(int, k),
|
||||
AND_0_VALUE_PARAMS()) {
|
||||
delete ::std::tr1::get<k>(args);
|
||||
delete ::testing::get<k>(args);
|
||||
}
|
||||
|
||||
// This action returns the value pointed to by 'pointer'.
|
||||
@@ -211,7 +211,7 @@ class GTEST_API_ UntypedFunctionMockerBase {
|
||||
// arguments. This function can be safely called from multiple
|
||||
// threads concurrently. The caller is responsible for deleting the
|
||||
// result.
|
||||
const UntypedActionResultHolderBase* UntypedInvokeWith(
|
||||
UntypedActionResultHolderBase* UntypedInvokeWith(
|
||||
const void* untyped_args)
|
||||
GTEST_LOCK_EXCLUDED_(g_gmock_mutex);
|
||||
|
||||
@@ -1289,6 +1289,57 @@ class MockSpec {
|
||||
GTEST_DISALLOW_ASSIGN_(MockSpec);
|
||||
}; // class MockSpec
|
||||
|
||||
// Wrapper type for generically holding an ordinary value or lvalue reference.
|
||||
// If T is not a reference type, it must be copyable or movable.
|
||||
// ReferenceOrValueWrapper<T> is movable, and will also be copyable unless
|
||||
// T is a move-only value type (which means that it will always be copyable
|
||||
// if the current platform does not support move semantics).
|
||||
//
|
||||
// The primary template defines handling for values, but function header
|
||||
// comments describe the contract for the whole template (including
|
||||
// specializations).
|
||||
template <typename T>
|
||||
class ReferenceOrValueWrapper {
|
||||
public:
|
||||
// Constructs a wrapper from the given value/reference.
|
||||
explicit ReferenceOrValueWrapper(T value)
|
||||
: value_(::testing::internal::move(value)) {
|
||||
}
|
||||
|
||||
// Unwraps and returns the underlying value/reference, exactly as
|
||||
// originally passed. The behavior of calling this more than once on
|
||||
// the same object is unspecified.
|
||||
T Unwrap() { return ::testing::internal::move(value_); }
|
||||
|
||||
// Provides nondestructive access to the underlying value/reference.
|
||||
// Always returns a const reference (more precisely,
|
||||
// const RemoveReference<T>&). The behavior of calling this after
|
||||
// calling Unwrap on the same object is unspecified.
|
||||
const T& Peek() const {
|
||||
return value_;
|
||||
}
|
||||
|
||||
private:
|
||||
T value_;
|
||||
};
|
||||
|
||||
// Specialization for lvalue reference types. See primary template
|
||||
// for documentation.
|
||||
template <typename T>
|
||||
class ReferenceOrValueWrapper<T&> {
|
||||
public:
|
||||
// Workaround for debatable pass-by-reference lint warning (c-library-team
|
||||
// policy precludes NOLINT in this context)
|
||||
typedef T& reference;
|
||||
explicit ReferenceOrValueWrapper(reference ref)
|
||||
: value_ptr_(&ref) {}
|
||||
T& Unwrap() { return *value_ptr_; }
|
||||
const T& Peek() const { return *value_ptr_; }
|
||||
|
||||
private:
|
||||
T* value_ptr_;
|
||||
};
|
||||
|
||||
// MSVC warns about using 'this' in base member initializer list, so
|
||||
// we need to temporarily disable the warning. We have to do it for
|
||||
// the entire class to suppress the warning, even though it's about
|
||||
@@ -1320,23 +1371,16 @@ class UntypedActionResultHolderBase {
|
||||
template <typename T>
|
||||
class ActionResultHolder : public UntypedActionResultHolderBase {
|
||||
public:
|
||||
explicit ActionResultHolder(T a_value) : value_(a_value) {}
|
||||
|
||||
// The compiler-generated copy constructor and assignment operator
|
||||
// are exactly what we need, so we don't need to define them.
|
||||
|
||||
// Returns the held value and deletes this object.
|
||||
T GetValueAndDelete() const {
|
||||
T retval(value_);
|
||||
delete this;
|
||||
return retval;
|
||||
// Returns the held value. Must not be called more than once.
|
||||
T Unwrap() {
|
||||
return result_.Unwrap();
|
||||
}
|
||||
|
||||
// Prints the held value as an action's result to os.
|
||||
virtual void PrintAsActionResult(::std::ostream* os) const {
|
||||
*os << "\n Returns: ";
|
||||
// T may be a reference type, so we don't use UniversalPrint().
|
||||
UniversalPrinter<T>::Print(value_, os);
|
||||
UniversalPrinter<T>::Print(result_.Peek(), os);
|
||||
}
|
||||
|
||||
// Performs the given mock function's default action and returns the
|
||||
@@ -1346,8 +1390,8 @@ class ActionResultHolder : public UntypedActionResultHolderBase {
|
||||
const FunctionMockerBase<F>* func_mocker,
|
||||
const typename Function<F>::ArgumentTuple& args,
|
||||
const string& call_description) {
|
||||
return new ActionResultHolder(
|
||||
func_mocker->PerformDefaultAction(args, call_description));
|
||||
return new ActionResultHolder(Wrapper(
|
||||
func_mocker->PerformDefaultAction(args, call_description)));
|
||||
}
|
||||
|
||||
// Performs the given action and returns the result in a new-ed
|
||||
@@ -1356,44 +1400,53 @@ class ActionResultHolder : public UntypedActionResultHolderBase {
|
||||
static ActionResultHolder*
|
||||
PerformAction(const Action<F>& action,
|
||||
const typename Function<F>::ArgumentTuple& args) {
|
||||
return new ActionResultHolder(action.Perform(args));
|
||||
return new ActionResultHolder(Wrapper(action.Perform(args)));
|
||||
}
|
||||
|
||||
private:
|
||||
T value_;
|
||||
typedef ReferenceOrValueWrapper<T> Wrapper;
|
||||
|
||||
// T could be a reference type, so = isn't supported.
|
||||
GTEST_DISALLOW_ASSIGN_(ActionResultHolder);
|
||||
explicit ActionResultHolder(Wrapper result)
|
||||
: result_(::testing::internal::move(result)) {
|
||||
}
|
||||
|
||||
Wrapper result_;
|
||||
|
||||
GTEST_DISALLOW_COPY_AND_ASSIGN_(ActionResultHolder);
|
||||
};
|
||||
|
||||
// Specialization for T = void.
|
||||
template <>
|
||||
class ActionResultHolder<void> : public UntypedActionResultHolderBase {
|
||||
public:
|
||||
explicit ActionResultHolder() {}
|
||||
|
||||
void GetValueAndDelete() const { delete this; }
|
||||
void Unwrap() { }
|
||||
|
||||
virtual void PrintAsActionResult(::std::ostream* /* os */) const {}
|
||||
|
||||
// Performs the given mock function's default action and returns NULL;
|
||||
// Performs the given mock function's default action and returns ownership
|
||||
// of an empty ActionResultHolder*.
|
||||
template <typename F>
|
||||
static ActionResultHolder* PerformDefaultAction(
|
||||
const FunctionMockerBase<F>* func_mocker,
|
||||
const typename Function<F>::ArgumentTuple& args,
|
||||
const string& call_description) {
|
||||
func_mocker->PerformDefaultAction(args, call_description);
|
||||
return new ActionResultHolder();
|
||||
return new ActionResultHolder;
|
||||
}
|
||||
|
||||
// Performs the given action and returns NULL.
|
||||
// Performs the given action and returns ownership of an empty
|
||||
// ActionResultHolder*.
|
||||
template <typename F>
|
||||
static ActionResultHolder* PerformAction(
|
||||
const Action<F>& action,
|
||||
const typename Function<F>::ArgumentTuple& args) {
|
||||
action.Perform(args);
|
||||
return new ActionResultHolder();
|
||||
return new ActionResultHolder;
|
||||
}
|
||||
|
||||
private:
|
||||
ActionResultHolder() {}
|
||||
GTEST_DISALLOW_COPY_AND_ASSIGN_(ActionResultHolder);
|
||||
};
|
||||
|
||||
// The base of the function mocker class for the given function type.
|
||||
@@ -1528,8 +1581,9 @@ class FunctionMockerBase : public UntypedFunctionMockerBase {
|
||||
// threads concurrently.
|
||||
Result InvokeWith(const ArgumentTuple& args)
|
||||
GTEST_LOCK_EXCLUDED_(g_gmock_mutex) {
|
||||
return static_cast<const ResultHolder*>(
|
||||
this->UntypedInvokeWith(&args))->GetValueAndDelete();
|
||||
scoped_ptr<ResultHolder> holder(
|
||||
DownCast_<ResultHolder*>(this->UntypedInvokeWith(&args)));
|
||||
return holder->Unwrap();
|
||||
}
|
||||
|
||||
// Adds and returns a default action spec for this mock function.
|
||||
@@ -0,0 +1,8 @@
|
||||
// This file was GENERATED by command:
|
||||
// pump.py gmock-generated-actions.h.pump
|
||||
// DO NOT EDIT BY HAND!!!
|
||||
|
||||
#ifndef GMOCK_INCLUDE_GMOCK_INTERNAL_CUSTOM_GMOCK_GENERATED_ACTIONS_H_
|
||||
#define GMOCK_INCLUDE_GMOCK_INTERNAL_CUSTOM_GMOCK_GENERATED_ACTIONS_H_
|
||||
|
||||
#endif // GMOCK_INCLUDE_GMOCK_INTERNAL_CUSTOM_GMOCK_GENERATED_ACTIONS_H_
|
||||
@@ -0,0 +1,10 @@
|
||||
$$ -*- mode: c++; -*-
|
||||
$$ This is a Pump source file (http://go/pump). Please use Pump to convert
|
||||
$$ it to callback-actions.h.
|
||||
$$
|
||||
$var max_callback_arity = 5
|
||||
$$}} This meta comment fixes auto-indentation in editors.
|
||||
#ifndef GMOCK_INCLUDE_GMOCK_INTERNAL_CUSTOM_GMOCK_GENERATED_ACTIONS_H_
|
||||
#define GMOCK_INCLUDE_GMOCK_INTERNAL_CUSTOM_GMOCK_GENERATED_ACTIONS_H_
|
||||
|
||||
#endif // GMOCK_INCLUDE_GMOCK_INTERNAL_CUSTOM_GMOCK_GENERATED_ACTIONS_H_
|
||||
@@ -1,4 +1,4 @@
|
||||
// Copyright 2008, Google Inc.
|
||||
// Copyright 2015, Google Inc.
|
||||
// All rights reserved.
|
||||
//
|
||||
// Redistribution and use in source and binary forms, with or without
|
||||
@@ -27,28 +27,13 @@
|
||||
// (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
|
||||
// OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
|
||||
//
|
||||
// Author: wan@google.com (Zhanyong Wan)
|
||||
// ============================================================
|
||||
// An installation-specific extension point for gmock-matchers.h.
|
||||
// ============================================================
|
||||
//
|
||||
// Adds google3 callback support to CallableTraits.
|
||||
//
|
||||
#ifndef GMOCK_INCLUDE_GMOCK_INTERNAL_CUSTOM_CALLBACK_MATCHERS_H_
|
||||
#define GMOCK_INCLUDE_GMOCK_INTERNAL_CUSTOM_CALLBACK_MATCHERS_H_
|
||||
|
||||
#include <iostream>
|
||||
#include "gmock/gmock.h"
|
||||
#include "gtest/gtest.h"
|
||||
|
||||
// MS C++ compiler/linker has a bug on Windows (not on Windows CE), which
|
||||
// causes a link error when _tmain is defined in a static library and UNICODE
|
||||
// is enabled. For this reason instead of _tmain, main function is used on
|
||||
// Windows. See the following link to track the current status of this bug:
|
||||
// http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=394464 // NOLINT
|
||||
#if GTEST_OS_WINDOWS_MOBILE
|
||||
# include <tchar.h> // NOLINT
|
||||
|
||||
GTEST_API_ int _tmain(int argc, TCHAR** argv) {
|
||||
#else
|
||||
GTEST_API_ int main(int argc, char** argv) {
|
||||
#endif // GTEST_OS_WINDOWS_MOBILE
|
||||
std::cout << "Running main() from gmock_main.cc\n";
|
||||
// Since Google Mock depends on Google Test, InitGoogleMock() is
|
||||
// also responsible for initializing Google Test. Therefore there's
|
||||
// no need for calling testing::InitGoogleTest() separately.
|
||||
testing::InitGoogleMock(&argc, argv);
|
||||
return RUN_ALL_TESTS();
|
||||
}
|
||||
#endif // GMOCK_INCLUDE_GMOCK_INTERNAL_CUSTOM_CALLBACK_MATCHERS_H_
|
||||
@@ -0,0 +1,46 @@
|
||||
// Copyright 2015, Google Inc.
|
||||
// All rights reserved.
|
||||
//
|
||||
// Redistribution and use in source and binary forms, with or without
|
||||
// modification, are permitted provided that the following conditions are
|
||||
// met:
|
||||
//
|
||||
// * Redistributions of source code must retain the above copyright
|
||||
// notice, this list of conditions and the following disclaimer.
|
||||
// * Redistributions in binary form must reproduce the above
|
||||
// copyright notice, this list of conditions and the following disclaimer
|
||||
// in the documentation and/or other materials provided with the
|
||||
// distribution.
|
||||
// * Neither the name of Google Inc. nor the names of its
|
||||
// contributors may be used to endorse or promote products derived from
|
||||
// this software without specific prior written permission.
|
||||
//
|
||||
// THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
|
||||
// "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
|
||||
// LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
|
||||
// A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
|
||||
// OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
|
||||
// SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
|
||||
// LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
|
||||
// DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
|
||||
// THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
|
||||
// (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
|
||||
// OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
|
||||
//
|
||||
// Injection point for custom user configurations.
|
||||
// The following macros can be defined:
|
||||
//
|
||||
// Flag related macros:
|
||||
// GMOCK_DECLARE_bool_(name)
|
||||
// GMOCK_DECLARE_int32_(name)
|
||||
// GMOCK_DECLARE_string_(name)
|
||||
// GMOCK_DEFINE_bool_(name, default_val, doc)
|
||||
// GMOCK_DEFINE_int32_(name, default_val, doc)
|
||||
// GMOCK_DEFINE_string_(name, default_val, doc)
|
||||
//
|
||||
// ** Custom implementation starts here **
|
||||
|
||||
#ifndef GMOCK_INCLUDE_GMOCK_INTERNAL_CUSTOM_GMOCK_PORT_H_
|
||||
#define GMOCK_INCLUDE_GMOCK_INTERNAL_CUSTOM_GMOCK_PORT_H_
|
||||
|
||||
#endif // GMOCK_INCLUDE_GMOCK_INTERNAL_CUSTOM_GMOCK_PORT_H_
|
||||
@@ -69,70 +69,70 @@ template <typename Tuple>
|
||||
struct MatcherTuple;
|
||||
|
||||
template <>
|
||||
struct MatcherTuple< ::std::tr1::tuple<> > {
|
||||
typedef ::std::tr1::tuple< > type;
|
||||
struct MatcherTuple< ::testing::tuple<> > {
|
||||
typedef ::testing::tuple< > type;
|
||||
};
|
||||
|
||||
template <typename A1>
|
||||
struct MatcherTuple< ::std::tr1::tuple<A1> > {
|
||||
typedef ::std::tr1::tuple<Matcher<A1> > type;
|
||||
struct MatcherTuple< ::testing::tuple<A1> > {
|
||||
typedef ::testing::tuple<Matcher<A1> > type;
|
||||
};
|
||||
|
||||
template <typename A1, typename A2>
|
||||
struct MatcherTuple< ::std::tr1::tuple<A1, A2> > {
|
||||
typedef ::std::tr1::tuple<Matcher<A1>, Matcher<A2> > type;
|
||||
struct MatcherTuple< ::testing::tuple<A1, A2> > {
|
||||
typedef ::testing::tuple<Matcher<A1>, Matcher<A2> > type;
|
||||
};
|
||||
|
||||
template <typename A1, typename A2, typename A3>
|
||||
struct MatcherTuple< ::std::tr1::tuple<A1, A2, A3> > {
|
||||
typedef ::std::tr1::tuple<Matcher<A1>, Matcher<A2>, Matcher<A3> > type;
|
||||
struct MatcherTuple< ::testing::tuple<A1, A2, A3> > {
|
||||
typedef ::testing::tuple<Matcher<A1>, Matcher<A2>, Matcher<A3> > type;
|
||||
};
|
||||
|
||||
template <typename A1, typename A2, typename A3, typename A4>
|
||||
struct MatcherTuple< ::std::tr1::tuple<A1, A2, A3, A4> > {
|
||||
typedef ::std::tr1::tuple<Matcher<A1>, Matcher<A2>, Matcher<A3>,
|
||||
struct MatcherTuple< ::testing::tuple<A1, A2, A3, A4> > {
|
||||
typedef ::testing::tuple<Matcher<A1>, Matcher<A2>, Matcher<A3>,
|
||||
Matcher<A4> > type;
|
||||
};
|
||||
|
||||
template <typename A1, typename A2, typename A3, typename A4, typename A5>
|
||||
struct MatcherTuple< ::std::tr1::tuple<A1, A2, A3, A4, A5> > {
|
||||
typedef ::std::tr1::tuple<Matcher<A1>, Matcher<A2>, Matcher<A3>, Matcher<A4>,
|
||||
struct MatcherTuple< ::testing::tuple<A1, A2, A3, A4, A5> > {
|
||||
typedef ::testing::tuple<Matcher<A1>, Matcher<A2>, Matcher<A3>, Matcher<A4>,
|
||||
Matcher<A5> > type;
|
||||
};
|
||||
|
||||
template <typename A1, typename A2, typename A3, typename A4, typename A5,
|
||||
typename A6>
|
||||
struct MatcherTuple< ::std::tr1::tuple<A1, A2, A3, A4, A5, A6> > {
|
||||
typedef ::std::tr1::tuple<Matcher<A1>, Matcher<A2>, Matcher<A3>, Matcher<A4>,
|
||||
struct MatcherTuple< ::testing::tuple<A1, A2, A3, A4, A5, A6> > {
|
||||
typedef ::testing::tuple<Matcher<A1>, Matcher<A2>, Matcher<A3>, Matcher<A4>,
|
||||
Matcher<A5>, Matcher<A6> > type;
|
||||
};
|
||||
|
||||
template <typename A1, typename A2, typename A3, typename A4, typename A5,
|
||||
typename A6, typename A7>
|
||||
struct MatcherTuple< ::std::tr1::tuple<A1, A2, A3, A4, A5, A6, A7> > {
|
||||
typedef ::std::tr1::tuple<Matcher<A1>, Matcher<A2>, Matcher<A3>, Matcher<A4>,
|
||||
struct MatcherTuple< ::testing::tuple<A1, A2, A3, A4, A5, A6, A7> > {
|
||||
typedef ::testing::tuple<Matcher<A1>, Matcher<A2>, Matcher<A3>, Matcher<A4>,
|
||||
Matcher<A5>, Matcher<A6>, Matcher<A7> > type;
|
||||
};
|
||||
|
||||
template <typename A1, typename A2, typename A3, typename A4, typename A5,
|
||||
typename A6, typename A7, typename A8>
|
||||
struct MatcherTuple< ::std::tr1::tuple<A1, A2, A3, A4, A5, A6, A7, A8> > {
|
||||
typedef ::std::tr1::tuple<Matcher<A1>, Matcher<A2>, Matcher<A3>, Matcher<A4>,
|
||||
struct MatcherTuple< ::testing::tuple<A1, A2, A3, A4, A5, A6, A7, A8> > {
|
||||
typedef ::testing::tuple<Matcher<A1>, Matcher<A2>, Matcher<A3>, Matcher<A4>,
|
||||
Matcher<A5>, Matcher<A6>, Matcher<A7>, Matcher<A8> > type;
|
||||
};
|
||||
|
||||
template <typename A1, typename A2, typename A3, typename A4, typename A5,
|
||||
typename A6, typename A7, typename A8, typename A9>
|
||||
struct MatcherTuple< ::std::tr1::tuple<A1, A2, A3, A4, A5, A6, A7, A8, A9> > {
|
||||
typedef ::std::tr1::tuple<Matcher<A1>, Matcher<A2>, Matcher<A3>, Matcher<A4>,
|
||||
struct MatcherTuple< ::testing::tuple<A1, A2, A3, A4, A5, A6, A7, A8, A9> > {
|
||||
typedef ::testing::tuple<Matcher<A1>, Matcher<A2>, Matcher<A3>, Matcher<A4>,
|
||||
Matcher<A5>, Matcher<A6>, Matcher<A7>, Matcher<A8>, Matcher<A9> > type;
|
||||
};
|
||||
|
||||
template <typename A1, typename A2, typename A3, typename A4, typename A5,
|
||||
typename A6, typename A7, typename A8, typename A9, typename A10>
|
||||
struct MatcherTuple< ::std::tr1::tuple<A1, A2, A3, A4, A5, A6, A7, A8, A9,
|
||||
struct MatcherTuple< ::testing::tuple<A1, A2, A3, A4, A5, A6, A7, A8, A9,
|
||||
A10> > {
|
||||
typedef ::std::tr1::tuple<Matcher<A1>, Matcher<A2>, Matcher<A3>, Matcher<A4>,
|
||||
typedef ::testing::tuple<Matcher<A1>, Matcher<A2>, Matcher<A3>, Matcher<A4>,
|
||||
Matcher<A5>, Matcher<A6>, Matcher<A7>, Matcher<A8>, Matcher<A9>,
|
||||
Matcher<A10> > type;
|
||||
};
|
||||
@@ -156,7 +156,7 @@ struct Function;
|
||||
template <typename R>
|
||||
struct Function<R()> {
|
||||
typedef R Result;
|
||||
typedef ::std::tr1::tuple<> ArgumentTuple;
|
||||
typedef ::testing::tuple<> ArgumentTuple;
|
||||
typedef typename MatcherTuple<ArgumentTuple>::type ArgumentMatcherTuple;
|
||||
typedef void MakeResultVoid();
|
||||
typedef IgnoredValue MakeResultIgnoredValue();
|
||||
@@ -166,7 +166,7 @@ template <typename R, typename A1>
|
||||
struct Function<R(A1)>
|
||||
: Function<R()> {
|
||||
typedef A1 Argument1;
|
||||
typedef ::std::tr1::tuple<A1> ArgumentTuple;
|
||||
typedef ::testing::tuple<A1> ArgumentTuple;
|
||||
typedef typename MatcherTuple<ArgumentTuple>::type ArgumentMatcherTuple;
|
||||
typedef void MakeResultVoid(A1);
|
||||
typedef IgnoredValue MakeResultIgnoredValue(A1);
|
||||
@@ -176,7 +176,7 @@ template <typename R, typename A1, typename A2>
|
||||
struct Function<R(A1, A2)>
|
||||
: Function<R(A1)> {
|
||||
typedef A2 Argument2;
|
||||
typedef ::std::tr1::tuple<A1, A2> ArgumentTuple;
|
||||
typedef ::testing::tuple<A1, A2> ArgumentTuple;
|
||||
typedef typename MatcherTuple<ArgumentTuple>::type ArgumentMatcherTuple;
|
||||
typedef void MakeResultVoid(A1, A2);
|
||||
typedef IgnoredValue MakeResultIgnoredValue(A1, A2);
|
||||
@@ -186,7 +186,7 @@ template <typename R, typename A1, typename A2, typename A3>
|
||||
struct Function<R(A1, A2, A3)>
|
||||
: Function<R(A1, A2)> {
|
||||
typedef A3 Argument3;
|
||||
typedef ::std::tr1::tuple<A1, A2, A3> ArgumentTuple;
|
||||
typedef ::testing::tuple<A1, A2, A3> ArgumentTuple;
|
||||
typedef typename MatcherTuple<ArgumentTuple>::type ArgumentMatcherTuple;
|
||||
typedef void MakeResultVoid(A1, A2, A3);
|
||||
typedef IgnoredValue MakeResultIgnoredValue(A1, A2, A3);
|
||||
@@ -196,7 +196,7 @@ template <typename R, typename A1, typename A2, typename A3, typename A4>
|
||||
struct Function<R(A1, A2, A3, A4)>
|
||||
: Function<R(A1, A2, A3)> {
|
||||
typedef A4 Argument4;
|
||||
typedef ::std::tr1::tuple<A1, A2, A3, A4> ArgumentTuple;
|
||||
typedef ::testing::tuple<A1, A2, A3, A4> ArgumentTuple;
|
||||
typedef typename MatcherTuple<ArgumentTuple>::type ArgumentMatcherTuple;
|
||||
typedef void MakeResultVoid(A1, A2, A3, A4);
|
||||
typedef IgnoredValue MakeResultIgnoredValue(A1, A2, A3, A4);
|
||||
@@ -207,7 +207,7 @@ template <typename R, typename A1, typename A2, typename A3, typename A4,
|
||||
struct Function<R(A1, A2, A3, A4, A5)>
|
||||
: Function<R(A1, A2, A3, A4)> {
|
||||
typedef A5 Argument5;
|
||||
typedef ::std::tr1::tuple<A1, A2, A3, A4, A5> ArgumentTuple;
|
||||
typedef ::testing::tuple<A1, A2, A3, A4, A5> ArgumentTuple;
|
||||
typedef typename MatcherTuple<ArgumentTuple>::type ArgumentMatcherTuple;
|
||||
typedef void MakeResultVoid(A1, A2, A3, A4, A5);
|
||||
typedef IgnoredValue MakeResultIgnoredValue(A1, A2, A3, A4, A5);
|
||||
@@ -218,7 +218,7 @@ template <typename R, typename A1, typename A2, typename A3, typename A4,
|
||||
struct Function<R(A1, A2, A3, A4, A5, A6)>
|
||||
: Function<R(A1, A2, A3, A4, A5)> {
|
||||
typedef A6 Argument6;
|
||||
typedef ::std::tr1::tuple<A1, A2, A3, A4, A5, A6> ArgumentTuple;
|
||||
typedef ::testing::tuple<A1, A2, A3, A4, A5, A6> ArgumentTuple;
|
||||
typedef typename MatcherTuple<ArgumentTuple>::type ArgumentMatcherTuple;
|
||||
typedef void MakeResultVoid(A1, A2, A3, A4, A5, A6);
|
||||
typedef IgnoredValue MakeResultIgnoredValue(A1, A2, A3, A4, A5, A6);
|
||||
@@ -229,7 +229,7 @@ template <typename R, typename A1, typename A2, typename A3, typename A4,
|
||||
struct Function<R(A1, A2, A3, A4, A5, A6, A7)>
|
||||
: Function<R(A1, A2, A3, A4, A5, A6)> {
|
||||
typedef A7 Argument7;
|
||||
typedef ::std::tr1::tuple<A1, A2, A3, A4, A5, A6, A7> ArgumentTuple;
|
||||
typedef ::testing::tuple<A1, A2, A3, A4, A5, A6, A7> ArgumentTuple;
|
||||
typedef typename MatcherTuple<ArgumentTuple>::type ArgumentMatcherTuple;
|
||||
typedef void MakeResultVoid(A1, A2, A3, A4, A5, A6, A7);
|
||||
typedef IgnoredValue MakeResultIgnoredValue(A1, A2, A3, A4, A5, A6, A7);
|
||||
@@ -240,7 +240,7 @@ template <typename R, typename A1, typename A2, typename A3, typename A4,
|
||||
struct Function<R(A1, A2, A3, A4, A5, A6, A7, A8)>
|
||||
: Function<R(A1, A2, A3, A4, A5, A6, A7)> {
|
||||
typedef A8 Argument8;
|
||||
typedef ::std::tr1::tuple<A1, A2, A3, A4, A5, A6, A7, A8> ArgumentTuple;
|
||||
typedef ::testing::tuple<A1, A2, A3, A4, A5, A6, A7, A8> ArgumentTuple;
|
||||
typedef typename MatcherTuple<ArgumentTuple>::type ArgumentMatcherTuple;
|
||||
typedef void MakeResultVoid(A1, A2, A3, A4, A5, A6, A7, A8);
|
||||
typedef IgnoredValue MakeResultIgnoredValue(A1, A2, A3, A4, A5, A6, A7, A8);
|
||||
@@ -251,7 +251,7 @@ template <typename R, typename A1, typename A2, typename A3, typename A4,
|
||||
struct Function<R(A1, A2, A3, A4, A5, A6, A7, A8, A9)>
|
||||
: Function<R(A1, A2, A3, A4, A5, A6, A7, A8)> {
|
||||
typedef A9 Argument9;
|
||||
typedef ::std::tr1::tuple<A1, A2, A3, A4, A5, A6, A7, A8, A9> ArgumentTuple;
|
||||
typedef ::testing::tuple<A1, A2, A3, A4, A5, A6, A7, A8, A9> ArgumentTuple;
|
||||
typedef typename MatcherTuple<ArgumentTuple>::type ArgumentMatcherTuple;
|
||||
typedef void MakeResultVoid(A1, A2, A3, A4, A5, A6, A7, A8, A9);
|
||||
typedef IgnoredValue MakeResultIgnoredValue(A1, A2, A3, A4, A5, A6, A7, A8,
|
||||
@@ -264,7 +264,7 @@ template <typename R, typename A1, typename A2, typename A3, typename A4,
|
||||
struct Function<R(A1, A2, A3, A4, A5, A6, A7, A8, A9, A10)>
|
||||
: Function<R(A1, A2, A3, A4, A5, A6, A7, A8, A9)> {
|
||||
typedef A10 Argument10;
|
||||
typedef ::std::tr1::tuple<A1, A2, A3, A4, A5, A6, A7, A8, A9,
|
||||
typedef ::testing::tuple<A1, A2, A3, A4, A5, A6, A7, A8, A9,
|
||||
A10> ArgumentTuple;
|
||||
typedef typename MatcherTuple<ArgumentTuple>::type ArgumentMatcherTuple;
|
||||
typedef void MakeResultVoid(A1, A2, A3, A4, A5, A6, A7, A8, A9, A10);
|
||||
@@ -77,8 +77,8 @@ $var typename_As = [[$for j, [[typename A$j]]]]
|
||||
$var As = [[$for j, [[A$j]]]]
|
||||
$var matcher_As = [[$for j, [[Matcher<A$j>]]]]
|
||||
template <$typename_As>
|
||||
struct MatcherTuple< ::std::tr1::tuple<$As> > {
|
||||
typedef ::std::tr1::tuple<$matcher_As > type;
|
||||
struct MatcherTuple< ::testing::tuple<$As> > {
|
||||
typedef ::testing::tuple<$matcher_As > type;
|
||||
};
|
||||
|
||||
|
||||
@@ -102,7 +102,7 @@ struct Function;
|
||||
template <typename R>
|
||||
struct Function<R()> {
|
||||
typedef R Result;
|
||||
typedef ::std::tr1::tuple<> ArgumentTuple;
|
||||
typedef ::testing::tuple<> ArgumentTuple;
|
||||
typedef typename MatcherTuple<ArgumentTuple>::type ArgumentMatcherTuple;
|
||||
typedef void MakeResultVoid();
|
||||
typedef IgnoredValue MakeResultIgnoredValue();
|
||||
@@ -121,7 +121,7 @@ template <typename R$typename_As>
|
||||
struct Function<R($As)>
|
||||
: Function<R($prev_As)> {
|
||||
typedef A$i Argument$i;
|
||||
typedef ::std::tr1::tuple<$As> ArgumentTuple;
|
||||
typedef ::testing::tuple<$As> ArgumentTuple;
|
||||
typedef typename MatcherTuple<ArgumentTuple>::type ArgumentMatcherTuple;
|
||||
typedef void MakeResultVoid($As);
|
||||
typedef IgnoredValue MakeResultIgnoredValue($As);
|
||||
@@ -361,17 +361,30 @@ template <typename T> struct DecayArray<T[]> {
|
||||
typedef const T* type;
|
||||
};
|
||||
|
||||
// Invalid<T>() returns an invalid value of type T. This is useful
|
||||
// Disable MSVC warnings for infinite recursion, since in this case the
|
||||
// the recursion is unreachable.
|
||||
#ifdef _MSC_VER
|
||||
# pragma warning(push)
|
||||
# pragma warning(disable:4717)
|
||||
#endif
|
||||
|
||||
// Invalid<T>() is usable as an expression of type T, but will terminate
|
||||
// the program with an assertion failure if actually run. This is useful
|
||||
// when a value of type T is needed for compilation, but the statement
|
||||
// will not really be executed (or we don't care if the statement
|
||||
// crashes).
|
||||
template <typename T>
|
||||
inline T Invalid() {
|
||||
return const_cast<typename remove_reference<T>::type&>(
|
||||
*static_cast<volatile typename remove_reference<T>::type*>(NULL));
|
||||
Assert(false, "", -1, "Internal error: attempt to return invalid value");
|
||||
// This statement is unreachable, and would never terminate even if it
|
||||
// could be reached. It is provided only to placate compiler warnings
|
||||
// about missing return statements.
|
||||
return Invalid<T>();
|
||||
}
|
||||
template <>
|
||||
inline void Invalid<void>() {}
|
||||
|
||||
#ifdef _MSC_VER
|
||||
# pragma warning(pop)
|
||||
#endif
|
||||
|
||||
// Given a raw type (i.e. having no top-level reference or const
|
||||
// modifier) RawContainer that's either an STL-style container or a
|
||||
@@ -434,16 +447,17 @@ class StlContainerView<Element[N]> {
|
||||
// ConstReference(const char * (&)[4])')
|
||||
// (and though the N parameter type is mismatched in the above explicit
|
||||
// conversion of it doesn't help - only the conversion of the array).
|
||||
return type(const_cast<Element*>(&array[0]), N, kReference);
|
||||
return type(const_cast<Element*>(&array[0]), N,
|
||||
RelationToSourceReference());
|
||||
#else
|
||||
return type(array, N, kReference);
|
||||
return type(array, N, RelationToSourceReference());
|
||||
#endif // GTEST_OS_SYMBIAN
|
||||
}
|
||||
static type Copy(const Element (&array)[N]) {
|
||||
#if GTEST_OS_SYMBIAN
|
||||
return type(const_cast<Element*>(&array[0]), N, kCopy);
|
||||
return type(const_cast<Element*>(&array[0]), N, RelationToSourceCopy());
|
||||
#else
|
||||
return type(array, N, kCopy);
|
||||
return type(array, N, RelationToSourceCopy());
|
||||
#endif // GTEST_OS_SYMBIAN
|
||||
}
|
||||
};
|
||||
@@ -451,7 +465,7 @@ class StlContainerView<Element[N]> {
|
||||
// This specialization is used when RawContainer is a native array
|
||||
// represented as a (pointer, size) tuple.
|
||||
template <typename ElementPointer, typename Size>
|
||||
class StlContainerView< ::std::tr1::tuple<ElementPointer, Size> > {
|
||||
class StlContainerView< ::testing::tuple<ElementPointer, Size> > {
|
||||
public:
|
||||
typedef GTEST_REMOVE_CONST_(
|
||||
typename internal::PointeeOf<ElementPointer>::type) RawElement;
|
||||
@@ -459,13 +473,11 @@ class StlContainerView< ::std::tr1::tuple<ElementPointer, Size> > {
|
||||
typedef const type const_reference;
|
||||
|
||||
static const_reference ConstReference(
|
||||
const ::std::tr1::tuple<ElementPointer, Size>& array) {
|
||||
using ::std::tr1::get;
|
||||
return type(get<0>(array), get<1>(array), kReference);
|
||||
const ::testing::tuple<ElementPointer, Size>& array) {
|
||||
return type(get<0>(array), get<1>(array), RelationToSourceReference());
|
||||
}
|
||||
static type Copy(const ::std::tr1::tuple<ElementPointer, Size>& array) {
|
||||
using ::std::tr1::get;
|
||||
return type(get<0>(array), get<1>(array), kCopy);
|
||||
static type Copy(const ::testing::tuple<ElementPointer, Size>& array) {
|
||||
return type(get<0>(array), get<1>(array), RelationToSourceCopy());
|
||||
}
|
||||
};
|
||||
|
||||
@@ -496,3 +508,4 @@ struct BooleanConstant {};
|
||||
} // namespace testing
|
||||
|
||||
#endif // GMOCK_INCLUDE_GMOCK_INTERNAL_GMOCK_INTERNAL_UTILS_H_
|
||||
|
||||
@@ -30,8 +30,11 @@
|
||||
// Author: vadimb@google.com (Vadim Berman)
|
||||
//
|
||||
// Low-level types and utilities for porting Google Mock to various
|
||||
// platforms. They are subject to change without notice. DO NOT USE
|
||||
// THEM IN USER CODE.
|
||||
// platforms. All macros ending with _ and symbols defined in an
|
||||
// internal namespace are subject to change without notice. Code
|
||||
// outside Google Mock MUST NOT USE THEM DIRECTLY. Macros that don't
|
||||
// end with _ are part of Google Mock's public API and can be used by
|
||||
// code outside Google Mock.
|
||||
|
||||
#ifndef GMOCK_INCLUDE_GMOCK_INTERNAL_GMOCK_PORT_H_
|
||||
#define GMOCK_INCLUDE_GMOCK_INTERNAL_GMOCK_PORT_H_
|
||||
@@ -40,10 +43,16 @@
|
||||
#include <stdlib.h>
|
||||
#include <iostream>
|
||||
|
||||
// Most of the types needed for porting Google Mock are also required
|
||||
// for Google Test and are defined in gtest-port.h.
|
||||
// Most of the utilities needed for porting Google Mock are also
|
||||
// required for Google Test and are defined in gtest-port.h.
|
||||
//
|
||||
// Note to maintainers: to reduce code duplication, prefer adding
|
||||
// portability utilities to Google Test's gtest-port.h instead of
|
||||
// here, as Google Mock depends on Google Test. Only add a utility
|
||||
// here if it's truly specific to Google Mock.
|
||||
#include "gtest/internal/gtest-linked_ptr.h"
|
||||
#include "gtest/internal/gtest-port.h"
|
||||
#include "gmock/internal/custom/gmock-port.h"
|
||||
|
||||
// To avoid conditional compilation everywhere, we make it
|
||||
// gmock-port.h's responsibility to #include the header implementing
|
||||
@@ -60,6 +69,8 @@
|
||||
// use this syntax to reference Google Mock flags.
|
||||
#define GMOCK_FLAG(name) FLAGS_gmock_##name
|
||||
|
||||
#if !defined(GMOCK_DECLARE_bool_)
|
||||
|
||||
// Macros for declaring flags.
|
||||
#define GMOCK_DECLARE_bool_(name) extern GTEST_API_ bool GMOCK_FLAG(name)
|
||||
#define GMOCK_DECLARE_int32_(name) \
|
||||
@@ -75,4 +86,6 @@
|
||||
#define GMOCK_DEFINE_string_(name, default_val, doc) \
|
||||
GTEST_API_ ::std::string GMOCK_FLAG(name) = (default_val)
|
||||
|
||||
#endif // !defined(GMOCK_DECLARE_bool_)
|
||||
|
||||
#endif // GMOCK_INCLUDE_GMOCK_INTERNAL_GMOCK_PORT_H_
|
||||
@@ -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 = ../gtest
|
||||
GTEST_DIR = ../../googletest
|
||||
|
||||
# Points to the root of Google Mock, relative to where this file is.
|
||||
# Remember to tweak this if you move this file.
|
||||
@@ -10,6 +10,6 @@
|
||||
/>
|
||||
<UserMacro
|
||||
Name="GTestDir"
|
||||
Value="../../gtest"
|
||||
Value="../../../googletest"
|
||||
/>
|
||||
</VisualStudioPropertySheet>
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user