Commit 6c093a23 authored by Scott Slack-Smith's avatar Scott Slack-Smith
Browse files

Merge branch 'master' of https://github.com/google/googletest

parents c958e26f d175c8bf
# Ignore CI build directory
build/
xcuserdata
cmake-build-debug/
.idea/
bazel-bin
bazel-genfiles
bazel-googletest
bazel-out
bazel-testlogs
# python
*.pyc
# Visual Studio files
*.sdf
*.opensdf
*.VC.opendb
*.suo
*.user
_ReSharper.Caches/
Win32-Debug/
Win32-Release/
x64-Debug/
x64-Release/
......@@ -7,7 +7,11 @@ install:
# /usr/bin/gcc is 4.6 always, but gcc-X.Y is available.
- if [ "$CXX" = "g++" ]; then export CXX="g++-4.9" CC="gcc-4.9"; fi
# /usr/bin/clang is 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
- if [ "$CXX" = "clang++" ] && [ "$TRAVIS_OS_NAME" = "linux" ]; then export CXX="clang++-3.7" CC="clang-3.7"; ln -sf /usr/bin/ccache /$HOME/bin/$CXX; ln -sf /usr/bin/ccache /$HOME/bin/$CC; fi
# ccache on OS X needs installation first
- if [ "$TRAVIS_OS_NAME" = "osx" ]; then brew update; brew install ccache; export PATH="/usr/local/opt/ccache/libexec:$PATH"; fi
# reset ccache statistics
- ccache --zero-stats
- echo ${PATH}
- echo ${CXX}
- ${CXX} --version
......@@ -22,25 +26,24 @@ addons:
- 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
cache: ccache
before_cache:
# print statistics before uploading new cache
- ccache --show-stats
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
- BUILD_TYPE=Debug VERBOSE=1
- BUILD_TYPE=Release VERBOSE=1 CXX_FLAGS=-std=c++11
notifications:
email: false
sudo: false
# Copyright 2017 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.
#
# Author: misterg@google.com (Gennadiy Civil)
#
# Bazel Build for Google C++ Testing Framework(Google Test)
package(default_visibility = ["//visibility:public"])
licenses(["notice"])
config_setting(
name = "win",
values = {"cpu": "x64_windows_msvc"},
)
# Google Test including Google Mock
cc_library(
name = "gtest",
srcs = glob(
include = [
"googletest/src/*.cc",
"googletest/src/*.h",
"googletest/include/gtest/**/*.h",
"googlemock/src/*.cc",
"googlemock/include/gmock/**/*.h",
],
exclude = [
"googletest/src/gtest-all.cc",
"googletest/src/gtest_main.cc",
"googlemock/src/gmock-all.cc",
"googlemock/src/gmock_main.cc",
],
),
hdrs =glob([
"googletest/include/gtest/*.h",
"googlemock/include/gmock/*.h",
]),
copts = select(
{
":win": [],
"//conditions:default": ["-pthread"],
},
),
includes = [
"googlemock",
"googlemock/include",
"googletest",
"googletest/include",
],
linkopts = select({
":win": [],
"//conditions:default": [
"-pthread",
],
}),
)
cc_library(
name = "gtest_main",
srcs = [
"googlemock/src/gmock_main.cc",
],
deps = ["//:gtest"],
)
# The following rules build samples of how to use gTest.
cc_library(
name = "gtest_sample_lib",
srcs = [
"googletest/samples/sample1.cc",
"googletest/samples/sample2.cc",
"googletest/samples/sample4.cc",
],
hdrs = [
"googletest/samples/prime_tables.h",
"googletest/samples/sample1.h",
"googletest/samples/sample2.h",
"googletest/samples/sample3-inl.h",
"googletest/samples/sample4.h",
],
)
cc_test(
name = "gtest_samples",
size = "small",
#All Samples except:
#sample9 ( main )
#sample10 (main and takes a command line option and needs to be separate)
srcs = [
"googletest/samples/sample1_unittest.cc",
"googletest/samples/sample2_unittest.cc",
"googletest/samples/sample3_unittest.cc",
"googletest/samples/sample4_unittest.cc",
"googletest/samples/sample5_unittest.cc",
"googletest/samples/sample6_unittest.cc",
"googletest/samples/sample7_unittest.cc",
"googletest/samples/sample8_unittest.cc",
],
deps = [
"gtest_sample_lib",
":gtest_main",
],
)
cc_test(
name = "sample9_unittest",
size = "small",
srcs = ["googletest/samples/sample9_unittest.cc"],
deps = [":gtest"],
)
cc_test(
name = "sample10_unittest",
size = "small",
srcs = ["googletest/samples/sample10_unittest.cc"],
deps = [
":gtest",
],
)
cmake_minimum_required(VERSION 2.6.4)
if (POLICY CMP0048)
cmake_policy(SET CMP0048 NEW)
endif (POLICY CMP0048)
project( googletest-distribution )
enable_testing()
include(CMakeDependentOption)
if (CMAKE_VERSION VERSION_LESS 2.8.5)
set(CMAKE_INSTALL_BINDIR "bin" CACHE STRING "User executables (bin)")
set(CMAKE_INSTALL_LIBDIR "lib${LIB_SUFFIX}" CACHE STRING "Object code libraries (lib)")
set(CMAKE_INSTALL_INCLUDEDIR "include" CACHE STRING "C header files (include)")
mark_as_advanced(CMAKE_INSTALL_BINDIR CMAKE_INSTALL_LIBDIR CMAKE_INSTALL_INCLUDEDIR)
else()
include(GNUInstallDirs)
endif()
option(BUILD_GTEST "Builds the googletest subproject" OFF)
#Note that googlemock target already builds googletest
option(BUILD_GMOCK "Builds the googlemock subproject" ON)
cmake_dependent_option(INSTALL_GTEST "Enable installation of googletest. (Projects embedding googletest may want to turn this OFF.)" ON "BUILD_GTEST OR BUILD_GMOCK" OFF)
cmake_dependent_option(INSTALL_GMOCK "Enable installation of googlemock. (Projects embedding googlemock may want to turn this OFF.)" ON "BUILD_GMOCK" OFF)
if(BUILD_GMOCK)
add_subdirectory( googlemock )
elseif(BUILD_GTEST)
......
......@@ -2,7 +2,7 @@
# Google Test #
[![Build Status](https://travis-ci.org/google/googletest.svg?branch=master)](https://travis-ci.org/google/googletest)
[![Build status](https://ci.appveyor.com/api/projects/status/4o38plt0xbo1ubc8/branch/master?svg=true)](https://ci.appveyor.com/project/BillyDonahue/googletest/branch/master)
[![Build status](https://ci.appveyor.com/api/projects/status/4o38plt0xbo1ubc8/branch/master?svg=true)](https://ci.appveyor.com/project/GoogleTestAppVeyor/googletest/branch/master)
Welcome to **Google Test**, Google's C++ test framework!
......@@ -12,7 +12,7 @@ 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
also an IRC channel on [OFTC](https://webchat.oftc.net/) (irc.oftc.net) #gtest available. Please
join us!
Getting started information for **Google Test** is available in the
......@@ -26,7 +26,7 @@ in its interior [googletest/README.md](googletest/README.md) file.
## Features ##
* An [XUnit](https://en.wikipedia.org/wiki/XUnit) test framework.
* An [xUnit](https://en.wikipedia.org/wiki/XUnit) test framework.
* Test discovery.
* A rich set of assertions.
* User-defined assertions.
......@@ -60,9 +60,12 @@ the following notable projects:
* [Protocol Buffers](https://github.com/google/protobuf), Google's data
interchange format.
* The [OpenCV](http://opencv.org/) computer vision library.
* [tiny-dnn](https://github.com/tiny-dnn/tiny-dnn): header only, dependency-free deep learning framework in C++11.
## Related Open Source Projects ##
[GTest Runner](https://github.com/nholthaus/gtest-runner) is a Qt5 based automated test-runner and Graphical User Interface with powerful features for Windows and Linux platforms.
[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
......@@ -73,6 +76,9 @@ 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.
[gtest-parallel](https://github.com/google/gtest-parallel) is a test runner that
runs tests from your binary in parallel to provide significant speed-up.
## Requirements ##
Google Test is designed to have fairly minimal requirements to build
......@@ -82,7 +88,7 @@ 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
[googletestframework@googlegroups.com](https://groups.google.com/forum/#!forum/googletestframework). Patches for fixing them are
even more welcome!
### Linux Requirements ###
......@@ -97,7 +103,7 @@ package (as described below):
### Windows Requirements ###
* Microsoft Visual C++ v7.1 or newer
* Microsoft Visual C++ 2010 or newer
### Cygwin Requirements ###
......
workspace(name = "com_google_googletest")
......@@ -4,68 +4,93 @@ os: Visual Studio 2015
environment:
matrix:
- Toolset: v140
- Toolset: v120
- Toolset: v110
- Toolset: v100
- compiler: msvc-15-seh
generator: "Visual Studio 15 2017"
APPVEYOR_BUILD_WORKER_IMAGE: Visual Studio 2017
platform:
- Win32
- x64
- compiler: msvc-15-seh
generator: "Visual Studio 15 2017 Win64"
APPVEYOR_BUILD_WORKER_IMAGE: Visual Studio 2017
- compiler: msvc-14-seh
generator: "Visual Studio 14 2015"
- compiler: msvc-14-seh
generator: "Visual Studio 14 2015 Win64"
- compiler: msvc-12-seh
generator: "Visual Studio 12 2013"
- compiler: msvc-12-seh
generator: "Visual Studio 12 2013 Win64"
- compiler: msvc-11-seh
generator: "Visual Studio 11 2012"
- compiler: msvc-11-seh
generator: "Visual Studio 11 2012 Win64"
- compiler: msvc-10-seh
generator: "Visual Studio 10 2010"
- compiler: gcc-5.3.0-posix
generator: "MinGW Makefiles"
cxx_path: 'C:\mingw-w64\i686-5.3.0-posix-dwarf-rt_v4-rev0\mingw32\bin'
- compiler: gcc-6.3.0-posix
generator: "MinGW Makefiles"
cxx_path: 'C:\mingw-w64\i686-6.3.0-posix-dwarf-rt_v5-rev1\mingw32\bin'
configuration:
# - Release
- Debug
#- Release
build:
verbosity: minimal
artifacts:
- path: '_build/Testing/Temporary/*'
name: test_results
before_build:
install:
- 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"
Write-Output "Compiler: $env:compiler"
Write-Output "Generator: $env:generator"
# git bash conflicts with MinGW makefiles
if ($env:generator -eq "MinGW Makefiles") {
$env:path = $env:path.replace("C:\Program Files\Git\usr\bin;", "")
if ($env:cxx_path -ne "") {
$env:path += ";$env:cxx_path"
}
}
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 ..
$conf = if ($env:generator -eq "MinGW Makefiles") {"-DCMAKE_BUILD_TYPE=$env:configuration"} else {"-DCMAKE_CONFIGURATION_TYPES=Debug;Release"}
# Disable test for MinGW (gtest tests fail, gmock tests can not build)
$gtest_build_tests = if ($env:generator -eq "MinGW Makefiles") {"-Dgtest_build_tests=OFF"} else {"-Dgtest_build_tests=ON"}
$gmock_build_tests = if ($env:generator -eq "MinGW Makefiles") {"-Dgmock_build_tests=OFF"} else {"-Dgmock_build_tests=ON"}
& cmake -G "$env:generator" $conf -Dgtest_build_samples=ON $gtest_build_tests $gmock_build_tests ..
if ($LastExitCode -ne 0) {
throw "Exec: $ErrorMessage"
}
& cmake --build . --config $env:CONFIGURATION
& 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
if ($env:generator -eq "MinGW Makefiles") {
return # No test available for MinGW
}
& ctest -C $env:CONFIGURATION --output-on-failure
& ctest -C $env:configuration --timeout 300 --output-on-failure
if ($LastExitCode -ne 0) {
throw "Exec: $ErrorMessage"
}
artifacts:
- path: '_build/CMakeFiles/*.log'
name: logs
- path: '_build/Testing/**/*.xml'
name: test_results
......@@ -94,7 +94,7 @@ Google Test):
* New feature: --gmock_catch_leaked_mocks for detecting leaked mocks.
* New feature: ACTION_TEMPLATE for defining templatized actions.
* New feature: the .After() clause for specifying expectation order.
* New feature: the .With() clause for for specifying inter-argument
* New feature: the .With() clause for specifying inter-argument
constraints.
* New feature: actions ReturnArg<k>(), ReturnNew<T>(...), and
DeleteArg<k>().
......
......@@ -37,7 +37,12 @@ endif()
# as ${gmock_SOURCE_DIR} and to the root binary directory as
# ${gmock_BINARY_DIR}.
# Language "C" is required for find_package(Threads).
project(gmock CXX C)
if (CMAKE_VERSION VERSION_LESS 3.0)
project(gmock CXX C)
else()
cmake_policy(SET CMP0048 NEW)
project(gmock VERSION 1.9.0 LANGUAGES CXX C)
endif()
cmake_minimum_required(VERSION 2.6.4)
if (COMMAND set_up_hermetic_build)
......@@ -103,10 +108,26 @@ endif()
########################################################################
#
# Install rules
install(TARGETS gmock gmock_main
DESTINATION lib)
install(DIRECTORY ${gmock_SOURCE_DIR}/include/gmock
DESTINATION include)
if(INSTALL_GMOCK)
install(TARGETS gmock gmock_main
RUNTIME DESTINATION ${CMAKE_INSTALL_BINDIR}
LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR}
ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR})
install(DIRECTORY ${gmock_SOURCE_DIR}/include/gmock
DESTINATION ${CMAKE_INSTALL_INCLUDEDIR})
# configure and install pkgconfig files
configure_file(
cmake/gmock.pc.in
"${CMAKE_BINARY_DIR}/gmock.pc"
@ONLY)
configure_file(
cmake/gmock_main.pc.in
"${CMAKE_BINARY_DIR}/gmock_main.pc"
@ONLY)
install(FILES "${CMAKE_BINARY_DIR}/gmock.pc" "${CMAKE_BINARY_DIR}/gmock_main.pc"
DESTINATION "${CMAKE_INSTALL_LIBDIR}/pkgconfig")
endif()
########################################################################
#
......@@ -143,7 +164,7 @@ if (gmock_build_tests)
cxx_test(gmock_link_test gmock_main test/gmock_link2_test.cc)
cxx_test(gmock_test gmock_main)
if (CMAKE_USE_PTHREADS_INIT)
if (DEFINED GTEST_HAS_PTHREAD)
cxx_test(gmock_stress_test gmock)
endif()
......
......@@ -35,7 +35,7 @@ We hope you find it useful!
* 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.
* Lets an user extend it by defining new matchers and actions.
* Does not use exceptions.
* Is easy to learn and use.
......@@ -78,7 +78,7 @@ posting a question on the
Google Mock is not a testing framework itself. Instead, it needs a
testing framework for writing tests. Google Mock works seamlessly
with [Google Test](http://code.google.com/p/googletest/), but
with [Google Test](https://github.com/google/googletest), but
you can also use it with [any C++ testing framework](../../master/googlemock/docs/ForDummies.md#using-google-mock-with-any-testing-framework).
### Requirements for End Users ###
......@@ -125,13 +125,46 @@ build Google Mock and its tests, which has further requirements:
### Building Google Mock ###
#### Using CMake ####
If you have CMake available, it is recommended that you follow the
[build instructions][gtest_cmakebuild]
as described for Google Test. If are using Google Mock with an
as described for Google Test.
If are using Google Mock with an
existing CMake project, the section
[Incorporating Into An Existing CMake Project][gtest_incorpcmake]
may be of particular interest. Otherwise, the following sections
detail how to build Google Mock without CMake.
may be of particular interest.
To make it work for Google Mock you will need to change
target_link_libraries(example gtest_main)
to
target_link_libraries(example gmock_main)
This works because `gmock_main` library is compiled with Google Test.
However, it does not automatically add Google Test includes.
Therefore you will also have to change
if (CMAKE_VERSION VERSION_LESS 2.8.11)
include_directories("${gtest_SOURCE_DIR}/include")
endif()
to
if (CMAKE_VERSION VERSION_LESS 2.8.11)
include_directories(BEFORE SYSTEM
"${gtest_SOURCE_DIR}/include" "${gmock_SOURCE_DIR}/include")
else()
target_include_directories(gmock_main SYSTEM BEFORE INTERFACE
"${gtest_SOURCE_DIR}/include" "${gmock_SOURCE_DIR}/include")
endif()
This will addtionally mark Google Mock includes as system, which will
silence compiler warnings when compiling your tests using clang with
`-Wpedantic -Wall -Wextra -Wconversion`.
#### Preparing to Build (Unix only) ####
......@@ -300,8 +333,8 @@ may need to tweak your compiler and/or linker flags. Please see the
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)).
[monomorphic](./docs/CookBook.md#writing-new-monomorphic-matchers),
[polymorphic](./docs/CookBook.md#writing-new-polymorphic-matchers)).
Matchers defined using `MATCHER()` or `MATCHER_P*()` aren't affected.
### Developing Google Mock ###
......
libdir=@CMAKE_INSTALL_FULL_LIBDIR@
includedir=@CMAKE_INSTALL_FULL_INCLUDEDIR@
Name: gmock
Description: GoogleMock (without main() function)
Version: @PROJECT_VERSION@
URL: https://github.com/google/googletest
Libs: -L${libdir} -lgmock @CMAKE_THREAD_LIBS_INIT@
Cflags: -I${includedir} @GTEST_HAS_PTHREAD_MACRO@ @CMAKE_THREAD_LIBS_INIT@
libdir=@CMAKE_INSTALL_FULL_LIBDIR@
includedir=@CMAKE_INSTALL_FULL_INCLUDEDIR@
Name: gmock_main
Description: GoogleMock (with main() function)
Version: @PROJECT_VERSION@
URL: https://github.com/google/googletest
Libs: -L${libdir} -lgmock_main @CMAKE_THREAD_LIBS_INIT@
Cflags: -I${includedir} @GTEST_HAS_PTHREAD_MACRO@ @CMAKE_THREAD_LIBS_INIT@
m4_include(../googletest/m4/acx_pthread.m4)
AC_INIT([Google C++ Mocking Framework],
[1.7.0],
[1.8.0],
[googlemock@googlegroups.com],
[gmock])
......@@ -101,7 +101,7 @@ AC_ARG_VAR([GTEST_VERSION],
[The version of Google Test available.])
HAVE_BUILT_GTEST="no"
GTEST_MIN_VERSION="1.7.0"
GTEST_MIN_VERSION="1.8.0"
AS_IF([test "x${enable_external_gtest}" = "xyes"],
[# Begin filling in variables as we are able.
......@@ -130,7 +130,7 @@ AS_IF([test "x${HAVE_BUILT_GTEST}" = "xyes"],
GTEST_LIBS=`${GTEST_CONFIG} --libs`
GTEST_VERSION=`${GTEST_CONFIG} --version`],
[AC_CONFIG_SUBDIRS([../googletest])
# GTEST_CONFIG needs to be executable both in a Makefile environmont and
# GTEST_CONFIG needs to be executable both in a Makefile environment and
# in a shell script environment, so resolve an absolute path for it here.
GTEST_CONFIG="`pwd -P`/../googletest/scripts/gtest-config"
GTEST_CPPFLAGS='-I$(top_srcdir)/../googletest/include'
......
......@@ -65,7 +65,7 @@ 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_METHOD1_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.
......@@ -249,7 +249,7 @@ match them more flexibly, or get more informative messages, you can use:
| `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. |
| `WhenSorted(m)` | When `argument` is sorted using the `<` operator, it matches container matcher `m`. E.g. `WhenSorted(ElementsAre(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:
......
......@@ -18,8 +18,9 @@ You must always put a mock method definition (`MOCK_METHOD*`) in a
`public:` section of the mock class, regardless of the method being
mocked being `public`, `protected`, or `private` in the base class.
This allows `ON_CALL` and `EXPECT_CALL` to reference the mock function
from outside of the mock class. (Yes, C++ allows a subclass to change
the access level of a virtual function in the base class.) Example:
from outside of the mock class. (Yes, C++ allows a subclass to specify
a different access level than the base class on a virtual function.)
Example:
```
class Foo {
......@@ -147,7 +148,7 @@ Note that the mock class doesn't define `AppendPacket()`, unlike the
real class. That's fine as long as the test doesn't need to call it.
Next, you need a way to say that you want to use
`ConcretePacketStream` in production code, and use `MockPacketStream`
`ConcretePacketStream` in production code and to use `MockPacketStream`
in tests. Since the functions are not virtual and the two classes are
unrelated, you must specify your choice at _compile time_ (as opposed
to run time).
......@@ -226,7 +227,7 @@ If a mock method has no `EXPECT_CALL` spec but is called, Google Mock
will print a warning about the "uninteresting call". The rationale is:
* New methods may be added to an interface after a test is written. We shouldn't fail a test just because a method it doesn't know about is called.
* However, this may also mean there's a bug in the test, so Google Mock shouldn't be silent either. If the user believes these calls are harmless, he can add an `EXPECT_CALL()` to suppress the warning.
* However, this may also mean there's a bug in the test, so Google Mock shouldn't be silent either. If the user believes these calls are harmless, they can add an `EXPECT_CALL()` to suppress the warning.
However, sometimes you may want to suppress all "uninteresting call"
warnings, while sometimes you may want the opposite, i.e. to treat all
......@@ -294,7 +295,7 @@ There are some caveats though (I don't like them just as much as the
next guy, but sadly they are side effects of C++'s limitations):
1. `NiceMock<MockFoo>` and `StrictMock<MockFoo>` only work for mock methods defined using the `MOCK_METHOD*` family of macros **directly** in the `MockFoo` class. If a mock method is defined in a **base class** of `MockFoo`, the "nice" or "strict" modifier may not affect it, depending on the compiler. In particular, nesting `NiceMock` and `StrictMock` (e.g. `NiceMock<StrictMock<MockFoo> >`) is **not** supported.
1. The constructors of the base mock (`MockFoo`) cannot have arguments passed by non-const reference, which happens to be banned by the [Google C++ style guide](http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml).
1. The constructors of the base mock (`MockFoo`) cannot have arguments passed by non-const reference, which happens to be banned by the [Google C++ style guide](https://google.github.io/styleguide/cppguide.html).
1. During the constructor or destructor of `MockFoo`, the mock object is _not_ nice or strict. This may cause surprises if the constructor or destructor calls a mock method on `this` object. (This behavior, however, is consistent with C++'s general rule: if a constructor or destructor calls a virtual method of `this` object, that method is treated as non-virtual. In other words, to the base class's constructor or destructor, `this` object behaves like an instance of the base class, not the derived class. This rule is required for safety. Otherwise a base constructor may use members of a derived class before they are initialized, or a base destructor may use members of a derived class after they have been destroyed.)
Finally, you should be **very cautious** about when to use naggy or strict mocks, as they tend to make tests more brittle and harder to maintain. When you refactor your code without changing its externally visible behavior, ideally you should't need to update any tests. If your code interacts with a naggy mock, however, you may start to get spammed with warnings as the result of your change. Worse, if your code interacts with a strict mock, your tests may start to fail and you'll be forced to fix them. Our general recommendation is to use nice mocks (not yet the default) most of the time, use naggy mocks (the current default) when developing or debugging tests, and use strict mocks only as the last resort.
......@@ -705,7 +706,7 @@ type `m` accepts):
1. When both `T` and `U` are built-in arithmetic types (`bool`, integers, and floating-point numbers), the conversion from `T` to `U` is not lossy (in other words, any value representable by `T` can also be represented by `U`); and
1. When `U` is a reference, `T` must also be a reference (as the underlying matcher may be interested in the address of the `U` value).
The code won't compile if any of these conditions isn't met.
The code won't compile if any of these conditions aren't met.
Here's one example:
......@@ -1029,9 +1030,10 @@ a value that satisfies matcher `m`.
For example:
> | `Field(&Foo::number, Ge(3))` | Matches `x` where `x.number >= 3`. |
| Expression | Description |
|:-----------------------------|:-----------------------------------|
> | `Property(&Foo::name, StartsWith("John "))` | Matches `x` where `x.name()` starts with `"John "`. |
| `Field(&Foo::number, Ge(3))` | Matches `x` where `x.number >= 3`. |
| `Property(&Foo::name, StartsWith("John "))` | Matches `x` where `x.name()` starts with `"John "`. |
Note that in `Property(&Foo::baz, ...)`, method `baz()` must take no
argument and be declared as `const`.
......@@ -1680,7 +1682,7 @@ This also works when the argument is an output iterator:
```
using ::testing::_;
using ::testing::SeArrayArgument;
using ::testing::SetArrayArgument;
class MockRolodex : public Rolodex {
public:
......@@ -1919,9 +1921,9 @@ using ::testing::_;
// second argument DoThis() receives.
```
Arghh, you need to refer to a mock function argument but C++ has no
lambda (yet), so you have to define your own action. :-( Or do you
really?
Arghh, you need to refer to a mock function argument but your version
of C++ has no lambdas, so you have to define your own action. :-(
Or do you really?
Well, Google Mock has an action to solve _exactly_ this problem:
......@@ -2365,7 +2367,7 @@ Now there’s one topic we haven’t covered: how do you set expectations on `Sh
// When one calls ShareBuzz() on the MockBuzzer like this, the call is
// forwarded to DoShareBuzz(), which is mocked. Therefore this statement
// will trigger the above EXPECT_CALL.
mock_buzzer_.ShareBuzz(MakeUnique&lt;Buzz&gt;(AccessLevel::kInternal),
mock_buzzer_.ShareBuzz(MakeUnique<Buzz>(AccessLevel::kInternal),
::base::Now());
```
......@@ -2404,7 +2406,7 @@ Now, the mock `DoShareBuzz()` method is free to save the buzz argument for later
```
std::unique_ptr<Buzz> intercepted_buzz;
EXPECT_CALL(mock_buzzer_, DoShareBuzz(NotNull(), _))
.WillOnce(Invoke([&amp;intercepted_buzz](Buzz* buzz, Time timestamp) {
.WillOnce(Invoke([&intercepted_buzz](Buzz* buzz, Time timestamp) {
// Save buzz in intercepted_buzz for analysis later.
intercepted_buzz.reset(buzz);
return false;
......@@ -2482,12 +2484,12 @@ MockFoo::~MockFoo() {}
## Forcing a Verification ##
When it's being destoyed, your friendly mock object will automatically
When it's being destroyed, your friendly mock object will automatically
verify that all expectations on it have been satisfied, and will
generate [Google Test](../../googletest/) failures
if not. This is convenient as it leaves you with one less thing to
worry about. That is, unless you are not sure if your mock object will
be destoyed.
be destroyed.
How could it be that your mock object won't eventually be destroyed?
Well, it might be created on the heap and owned by the code you are
......@@ -3347,6 +3349,7 @@ 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` |
......@@ -3508,6 +3511,7 @@ is asked to infer the type of `x`?
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` |
......@@ -3515,7 +3519,7 @@ the action and the parameter types. The rule is relatively simple:
| `ACTION_P(Bar, param)` | `Bar(int_value)` | `BarActionP<int>` |
| `ACTION_TEMPLATE(Bar, HAS_m_TEMPLATE_PARAMS(...), AND_1_VALUE_PARAMS(p1))` | `Bar<t1, ..., t_m>(int_value)` | `FooActionP<t1, ..., t_m, int>` |
| `ACTION_P2(Baz, p1, p2)` | `Baz(bool_value, int_value)` | `BazActionP2<bool, int>` |
| `ACTION_TEMPLATE(Baz, HAS_m_TEMPLATE_PARAMS(...), AND_2_VALUE_PARAMS(p1, p2))` | `Baz<t1, ..., t_m>(bool_value, int_value)` | `FooActionP2<t1, ..., t_m, bool, int>` |
| `ACTION_TEMPLATE(Baz, HAS_m_TEMPLATE_PARAMS(...), AND_2_VALUE_PARAMS(p1, p2))`| `Baz<t1, ..., t_m>(bool_value, int_value)` | `FooActionP2<t1, ..., t_m, bool, int>` |
| ... | ... | ... |
Note that we have to pick different suffixes (`Action`, `ActionP`,
......
......@@ -64,7 +64,7 @@ compile it in the [README](../README.md) file.
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
review. To perform the tests, follow the instructions in [README](../README.md) and
verify that there are no failures.
# Contributing Code #
......@@ -91,14 +91,14 @@ instructions for how to sign and return it.
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).
to conform to the style outlined [here](https://google.github.io/styleguide/cppguide.html).
## 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. 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](https://github.com/google/googletest/issues). Please don't mix more than one logical change per submittal, because it makes the history hard to follow. If you want to make a change that doesn't have a corresponding issue in the issue tracker, please create one.
1. Also, coordinate with team members that are listed on the issue in question. This ensures that work isn't being duplicated and communicating your plan early also generally leads to better patches.
1. Ensure that your code adheres to the [Google Mock source code style](#Coding_Style.md).
1. Ensure that there are unit tests for your code.
......
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.**
This page lists all documentation markdown files for Google Mock **(the
current git version)**
-- **if you use a former version of Google Mock, please read the
documentation for that specific version instead (e.g. by checking out
the respective git branch/tag).**
* [ForDummies](ForDummies.md) -- start here if you are new to Google Mock.
* [CheatSheet](CheatSheet.md) -- a quick reference.
......@@ -9,4 +12,4 @@ This page lists all documentation wiki pages for Google Mock **(the SVN trunk ve
To contribute code to Google Mock, read:
* [DevGuide](DevGuide.md) -- read this _before_ writing your first patch.
* [Pump Manual](../googletest/docs/PumpManual.md) -- how we generate some of Google Mock's source files.
* [Pump Manual](../../googletest/docs/PumpManual.md) -- how we generate some of Google Mock's source files.
......@@ -23,8 +23,8 @@ Using Google Mock involves three basic steps:
# 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.
* Someone has to implement the mocks. The job is usually tedious and error-prone. No wonder people go great distances 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.
......@@ -217,7 +217,8 @@ The macro can be followed by some optional _clauses_ that provide more informati
This syntax is designed to make an expectation read like English. For example, you can probably guess that
```
using ::testing::Return;...
using ::testing::Return;
...
EXPECT_CALL(turtle, GetX())
.Times(5)
.WillOnce(Return(100))
......@@ -251,7 +252,8 @@ EXPECT_CALL(turtle, Forward(_));
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;...
using ::testing::Ge;
...
EXPECT_CALL(turtle, Forward(Ge(100)));
```
......@@ -280,7 +282,8 @@ First, if the return type of a mock function is a built-in type or a pointer, th
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;...
using ::testing::Return;
...
EXPECT_CALL(turtle, GetX())
.WillOnce(Return(100))
.WillOnce(Return(200))
......@@ -290,7 +293,8 @@ EXPECT_CALL(turtle, GetX())
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;...
using ::testing::Return;
...
EXPECT_CALL(turtle, GetY())
.WillOnce(Return(100))
.WillOnce(Return(200))
......@@ -317,7 +321,8 @@ Instead of returning 100, 101, 102, ..., consecutively, this mock function will
Time for another quiz! What do you think the following means?
```
using ::testing::Return;...
using ::testing::Return;
...
EXPECT_CALL(turtle, GetY())
.Times(4)
.WillOnce(Return(100));
......@@ -331,7 +336,8 @@ So far we've only shown examples where you have a single expectation. More reali
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::_;...
using ::testing::_;
...
EXPECT_CALL(turtle, Forward(_)); // #1
EXPECT_CALL(turtle, Forward(10)) // #2
.Times(2);
......@@ -347,7 +353,8 @@ By default, an expectation can match a call even though an earlier expectation h
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;...
using ::testing::InSequence;
...
TEST(FooTest, DrawsLineSegment) {
...
{
......@@ -365,7 +372,7 @@ By creating an object of type `InSequence`, all expectations in its scope are pu
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).)
(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.md#expecting-partially-ordered-calls).)
## 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)?
......@@ -373,7 +380,8 @@ Now let's do a quick quiz to see how well you can use this mock stuff already. H
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::_;...
using ::testing::_;
...
EXPECT_CALL(turtle, GoTo(_, _)) // #1
.Times(AnyNumber());
EXPECT_CALL(turtle, GoTo(0, 0)) // #2
......
......@@ -240,7 +240,7 @@ You cannot mock a variadic function (i.e. a function taking ellipsis
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.
the protocol, and we cannot look into their 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
......
This diff is collapsed.
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment