Merge branch 'master' into master
This commit is contained in:
commit
87a37c60e3
@ -4,6 +4,12 @@
|
||||
[![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/GoogleTestAppVeyor/googletest/branch/master)
|
||||
|
||||
**Future Plans**:
|
||||
* 1.8.x Release - the 1.8.x will be the last release that works with pre-C++11 compilers. The 1.8.1 will not accept any requests for any new features and any bugfix requests will only be accepted if proven "critical"
|
||||
* Post 1.8.x - work to improve/cleanup/pay technical debt. When this work is completed there will be a 1.9.x tagged release
|
||||
* Post 1.9.x googletest will follow [Abseil Live at Head philosophy](https://abseil.io/about/philosophy)
|
||||
|
||||
|
||||
Welcome to **Google Test**, Google's C++ test framework!
|
||||
|
||||
This repository is a merger of the formerly separate GoogleTest and
|
||||
|
@ -31,8 +31,6 @@
|
||||
// An installation-specific extension point for gmock-matchers.h.
|
||||
// ============================================================
|
||||
//
|
||||
// Adds google3 callback support to CallableTraits.
|
||||
|
||||
// GOOGLETEST_CM0002 DO NOT DELETE
|
||||
|
||||
#ifndef GMOCK_INCLUDE_GMOCK_INTERNAL_CUSTOM_GMOCK_MATCHERS_H_
|
||||
|
@ -29,13 +29,14 @@
|
||||
# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
|
||||
# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
|
||||
|
||||
"""Tests the text output of Google C++ Mocking Framework.
|
||||
r"""Tests the text output of Google C++ Mocking Framework.
|
||||
|
||||
To update the golden file:
|
||||
gmock_output_test.py --build_dir=BUILD/DIR --gengolden
|
||||
# where BUILD/DIR contains the built gmock_output_test_ file.
|
||||
where BUILD/DIR contains the built gmock_output_test_ file.
|
||||
gmock_output_test.py --gengolden
|
||||
gmock_output_test.py
|
||||
|
||||
"""
|
||||
|
||||
__author__ = 'wan@google.com (Zhanyong Wan)'
|
||||
|
@ -230,7 +230,7 @@ find_package(PythonInterp)
|
||||
# from the given source files with the given compiler flags.
|
||||
function(cxx_test_with_flags name cxx_flags libs)
|
||||
cxx_executable_with_flags(${name} "${cxx_flags}" "${libs}" ${ARGN})
|
||||
add_test(${name} ${name})
|
||||
add_test(NAME ${name} COMMAND ${name})
|
||||
endfunction()
|
||||
|
||||
# cxx_test(name libs srcs...)
|
||||
|
@ -3,7 +3,7 @@
|
||||
|
||||
## Introduction
|
||||
|
||||
Now that you have read the [googletest Primer](primer) and learned how to write
|
||||
Now that you have read the [googletest Primer](primer.md) and learned how to write
|
||||
tests using googletest, it's time to learn some new tricks. This document will
|
||||
show you more assertions as well as how to construct complex failure messages,
|
||||
propagate fatal failures, reuse and speed up your test fixtures, and use various
|
||||
@ -103,13 +103,11 @@ If you already have a function or functor that returns `bool` (or a type that
|
||||
can be implicitly converted to `bool`), you can use it in a *predicate
|
||||
assertion* to get the function arguments printed for free:
|
||||
|
||||
| Fatal assertion | Nonfatal assertion | Verifies |
|
||||
| -------------------- | -------------------- | --------------------------- |
|
||||
| `ASSERT_PRED1(pred1, | `EXPECT_PRED1(pred1, | `pred1(val1)` is true |
|
||||
: val1);` : val1);` : :
|
||||
| `ASSERT_PRED2(pred2, | `EXPECT_PRED2(pred2, | `pred2(val1, val2)` is true |
|
||||
: val1, val2);` : val1, val2);` : :
|
||||
| `...` | `...` | ... |
|
||||
| Fatal assertion | Nonfatal assertion | Verifies |
|
||||
| ---------------------------------- | ---------------------------------- | --------------------------- |
|
||||
| `ASSERT_PRED1(pred1, val1);` | `EXPECT_PRED1(pred1, val1);` | `pred1(val1)` is true |
|
||||
| `ASSERT_PRED2(pred2, val1, val2);` | `EXPECT_PRED2(pred2, val1, val2);` | `pred2(val1, val2)` is true |
|
||||
| `...` | `...` | ... |
|
||||
|
||||
In the above, `predn` is an `n`-ary predicate function or functor, where `val1`,
|
||||
`val2`, ..., and `valn` are its arguments. The assertion succeeds if the
|
||||
@ -120,7 +118,7 @@ either case, the arguments are evaluated exactly once.
|
||||
Here's an example. Given
|
||||
|
||||
```c++
|
||||
// Returns true iff m and n have no common divisors except 1.
|
||||
// Returns true if m and n have no common divisors except 1.
|
||||
bool MutuallyPrime(int m, int n) { ... }
|
||||
|
||||
const int a = 3;
|
||||
@ -152,7 +150,7 @@ c is 10
|
||||
>
|
||||
> 1. If you see a compiler error "no matching function to call" when using
|
||||
> `ASSERT_PRED*` or `EXPECT_PRED*`, please see
|
||||
> [this](faq#OverloadedPredicate) for how to resolve it.
|
||||
> [this](faq.md#OverloadedPredicate) for how to resolve it.
|
||||
> 1. Currently we only provide predicate assertions of arity <= 5. If you need
|
||||
> a higher-arity assertion, let [us](https://github.com/google/googletest/issues) know.
|
||||
|
||||
@ -339,12 +337,10 @@ want to learn more, see
|
||||
|
||||
#### Floating-Point Macros
|
||||
|
||||
| Fatal assertion | Nonfatal assertion | Verifies |
|
||||
| ----------------------- | ----------------------- | ----------------------- |
|
||||
| `ASSERT_FLOAT_EQ(val1, | `EXPECT_FLOAT_EQ(val1, | the two `float` values |
|
||||
: val2);` : val2);` : are almost equal :
|
||||
| `ASSERT_DOUBLE_EQ(val1, | `EXPECT_DOUBLE_EQ(val1, | the two `double` values |
|
||||
: val2);` : val2);` : are almost equal :
|
||||
| Fatal assertion | Nonfatal assertion | Verifies |
|
||||
| ------------------------------- | ------------------------------ | ---------------------------------------- |
|
||||
| `ASSERT_FLOAT_EQ(val1, val2);` | `EXPECT_FLOAT_EQ(val1,val2);` | the two `float` values are almost equal |
|
||||
| `ASSERT_DOUBLE_EQ(val1, val2);` | `EXPECT_DOUBLE_EQ(val1, val2);`| the two `double` values are almost equal |
|
||||
|
||||
By "almost equal" we mean the values are within 4 ULP's from each other.
|
||||
|
||||
@ -354,12 +350,9 @@ unsafe and has been deprecated. Please don't use it any more.
|
||||
|
||||
The following assertions allow you to choose the acceptable error bound:
|
||||
|
||||
| Fatal assertion | Nonfatal assertion | Verifies |
|
||||
| ------------------ | ------------------------ | ------------------------- |
|
||||
| `ASSERT_NEAR(val1, | `EXPECT_NEAR(val1, val2, | the difference between |
|
||||
: val2, abs_error);` : abs_error);` : `val1` and `val2` doesn't :
|
||||
: : : exceed the given absolute :
|
||||
: : : error :
|
||||
| Fatal assertion | Nonfatal assertion | Verifies |
|
||||
| ------------------------------------- | ------------------------------------- | ------------------------- |
|
||||
| `ASSERT_NEAR(val1, val2, abs_error);` | `EXPECT_NEAR(val1, val2, abs_error);` | the difference between `val1` and `val2` doesn't exceed the given absolute error |
|
||||
|
||||
**Availability**: Linux, Windows, Mac.
|
||||
|
||||
@ -387,10 +380,9 @@ library of matchers for validating arguments passed to mock objects. A gMock
|
||||
*matcher* is basically a predicate that knows how to describe itself. It can be
|
||||
used in these assertion macros:
|
||||
|
||||
| Fatal assertion | Nonfatal assertion | Verifies |
|
||||
| ------------------- | ------------------------------ | --------------------- |
|
||||
| `ASSERT_THAT(value, | `EXPECT_THAT(value, matcher);` | value matches matcher |
|
||||
: matcher);` : : :
|
||||
| Fatal assertion | Nonfatal assertion | Verifies |
|
||||
| ------------------------------ | ------------------------------ | --------------------- |
|
||||
| `ASSERT_THAT(value, matcher);` | `EXPECT_THAT(value, matcher);` | value matches matcher |
|
||||
|
||||
For example, `StartsWith(prefix)` is a matcher that matches a string starting
|
||||
with `prefix`, and you can write:
|
||||
@ -1396,17 +1388,11 @@ namespace:
|
||||
|
||||
| Parameter Generator | Behavior |
|
||||
| ---------------------------- | ------------------------------------------- |
|
||||
| `Range(begin, end [, step])` | Yields values `{begin, begin+step, |
|
||||
: : begin+step+step, ...}`. The values do not :
|
||||
: : include `end`. `step` defaults to 1. :
|
||||
| `Range(begin, end [, step])` | Yields values `{begin, begin+step, begin+step+step, ...}`. The values do not include `end`. `step` defaults to 1. |
|
||||
| `Values(v1, v2, ..., vN)` | Yields values `{v1, v2, ..., vN}`. |
|
||||
| `ValuesIn(container)` and | Yields values from a C-style array, an |
|
||||
: `ValuesIn(begin,end)` : STL-style container, or an iterator range :
|
||||
: : `[begin, end)`. :
|
||||
| `ValuesIn(container)` and `ValuesIn(begin,end)` | Yields values from a C-style array, an STL-style container, or an iterator range `[begin, end)`. |
|
||||
| `Bool()` | Yields sequence `{false, true}`. |
|
||||
| `Combine(g1, g2, ..., gN)` | Yields all combinations (Cartesian product) |
|
||||
: : as std\:\:tuples of the values generated by :
|
||||
: : the `N` generators. :
|
||||
| `Combine(g1, g2, ..., gN)` | Yields all combinations (Cartesian product) as std\:\:tuples of the values generated by the `N` generators. |
|
||||
|
||||
For more details, see the comments at the definitions of these functions.
|
||||
|
||||
@ -1726,11 +1712,11 @@ To test them, we use the following special techniques:
|
||||
```c++
|
||||
// foo.h
|
||||
|
||||
#include "gtest/gtest_prod.h"
|
||||
#include "gtest/gtest_prod.h"
|
||||
|
||||
class Foo {
|
||||
...
|
||||
private:
|
||||
private:
|
||||
FRIEND_TEST(FooTest, BarReturnsZeroOnNull);
|
||||
|
||||
int Bar(void* x);
|
||||
@ -1779,7 +1765,7 @@ To test them, we use the following special techniques:
|
||||
```
|
||||
|
||||
|
||||
## "Catching" Failures
|
||||
## "Catching" Failures
|
||||
|
||||
If you are building a testing utility on top of googletest, you'll want to test
|
||||
your utility. What framework would you use to test it? googletest, of course.
|
||||
@ -2168,23 +2154,22 @@ random seed and re-shuffle the tests in each iteration.
|
||||
googletest can use colors in its terminal output to make it easier to spot the
|
||||
important information:
|
||||
|
||||
...
|
||||
<span style="color:green">[----------]<span style="color:black"> 1 test from FooTest
|
||||
<span style="color:green">[ RUN ]<span style="color:black"> FooTest.DoesAbc
|
||||
<span style="color:green">[ OK ]<span style="color:black"> FooTest.DoesAbc
|
||||
<span style="color:green">[----------]<span style="color:black"> 2 tests from BarTest
|
||||
<span style="color:green">[ RUN ]<span style="color:black"> BarTest.HasXyzProperty
|
||||
<span style="color:green">[ OK ]<span style="color:black"> BarTest.HasXyzProperty
|
||||
<span style="color:green">[ RUN ]<span style="color:black"> BarTest.ReturnsTrueOnSuccess
|
||||
... some error messages ...
|
||||
<span style="color:red">[ FAILED ] <span style="color:black">BarTest.ReturnsTrueOnSuccess
|
||||
...
|
||||
<span style="color:green">[==========]<span style="color:black"> 30 tests from 14 test cases ran.
|
||||
<span style="color:green">[ PASSED ]<span style="color:black"> 28 tests.
|
||||
<span style="color:red">[ FAILED ]<span style="color:black"> 2 tests, listed below:
|
||||
<span style="color:red">[ FAILED ]<span style="color:black"> BarTest.ReturnsTrueOnSuccess
|
||||
<span style="color:red">[ FAILED ]<span style="color:black"> AnotherTest.DoesXyz
|
||||
|
||||
...<br/>
|
||||
<span style="color:green">[----------]<span style="color:black"> 1 test from FooTest<br/>
|
||||
<span style="color:green">[ RUN ]<span style="color:black"> FooTest.DoesAbc<br/>
|
||||
<span style="color:green">[ OK ]<span style="color:black"> FooTest.DoesAbc<br/>
|
||||
<span style="color:green">[----------]<span style="color:black"> 2 tests from BarTest<br/>
|
||||
<span style="color:green">[ RUN ]<span style="color:black"> BarTest.HasXyzProperty<br/>
|
||||
<span style="color:green">[ OK ]<span style="color:black"> BarTest.HasXyzProperty<br/>
|
||||
<span style="color:green">[ RUN ]<span style="color:black"> BarTest.ReturnsTrueOnSuccess<br/>
|
||||
... some error messages ...<br/>
|
||||
<span style="color:red">[ FAILED ] <span style="color:black">BarTest.ReturnsTrueOnSuccess<br/>
|
||||
...<br/>
|
||||
<span style="color:green">[==========]<span style="color:black"> 30 tests from 14 test cases ran.<br/>
|
||||
<span style="color:green">[ PASSED ]<span style="color:black"> 28 tests.<br/>
|
||||
<span style="color:red">[ FAILED ]<span style="color:black"> 2 tests, listed below:<br/>
|
||||
<span style="color:red">[ FAILED ]<span style="color:black"> BarTest.ReturnsTrueOnSuccess<br/>
|
||||
<span style="color:red">[ FAILED ]<span style="color:black"> AnotherTest.DoesXyz<br/>
|
||||
2 FAILED TESTS
|
||||
|
||||
You can set the `GTEST_COLOR` environment variable or the `--gtest_color`
|
||||
@ -2193,8 +2178,7 @@ disable colors, or let googletest decide. When the value is `auto`, googletest
|
||||
will use colors if and only if the output goes to a terminal and (on non-Windows
|
||||
platforms) the `TERM` environment variable is set to `xterm` or `xterm-color`.
|
||||
|
||||
>
|
||||
> **Availability**: Linux, Windows, Mac.
|
||||
**Availability**: Linux, Windows, Mac.
|
||||
|
||||
#### Suppressing the Elapsed Time
|
||||
|
||||
|
@ -707,8 +707,9 @@ In general, the recommended way to cause the code to behave differently under
|
||||
test is [Dependency Injection](https://en.wikipedia.org/wiki/Dependency_injection). You can inject
|
||||
different functionality from the test and from the production code. Since your
|
||||
production code doesn't link in the for-test logic at all (the
|
||||
[`testonly`](http://go/testonly) attribute for BUILD targets helps to ensure
|
||||
that), there is no danger in accidentally running it.
|
||||
[`testonly`](https://docs.bazel.build/versions/master/be/common-definitions.html#common.testonly)
|
||||
attribute for BUILD targets helps to ensure that), there is no danger in
|
||||
accidentally running it.
|
||||
|
||||
However, if you *really*, *really*, *really* have no choice, and if you follow
|
||||
the rule of ending your test program names with `_test`, you can use the
|
||||
|
@ -180,6 +180,7 @@
|
||||
// GTEST_HAS_TYPED_TEST - typed tests
|
||||
// GTEST_HAS_TYPED_TEST_P - type-parameterized tests
|
||||
// GTEST_IS_THREADSAFE - Google Test is thread-safe.
|
||||
// GOOGLETEST_CM0007 DO NOT DELETE
|
||||
// GTEST_USES_POSIX_RE - enhanced POSIX regex is used. Do not confuse with
|
||||
// GTEST_HAS_POSIX_RE (see above) which users can
|
||||
// define themselves.
|
||||
@ -231,6 +232,7 @@
|
||||
// Regular expressions:
|
||||
// RE - a simple regular expression class using the POSIX
|
||||
// Extended Regular Expression syntax on UNIX-like platforms
|
||||
// GOOGLETEST_CM0008 DO NOT DELETE
|
||||
// or a reduced regular exception syntax on other
|
||||
// platforms, including Windows.
|
||||
// Logging:
|
||||
|
@ -233,11 +233,14 @@ static std::string DeathTestThreadWarning(size_t thread_count) {
|
||||
Message msg;
|
||||
msg << "Death tests use fork(), which is unsafe particularly"
|
||||
<< " in a threaded context. For this test, " << GTEST_NAME_ << " ";
|
||||
if (thread_count == 0)
|
||||
if (thread_count == 0) {
|
||||
msg << "couldn't detect the number of threads.";
|
||||
else
|
||||
} else {
|
||||
msg << "detected " << thread_count << " threads.";
|
||||
msg << " See https://github.com/google/googletest/blob/master/googletest/docs/advanced.md#death-tests-and-threads"
|
||||
}
|
||||
msg << " See "
|
||||
"https://github.com/google/googletest/blob/master/googletest/docs/"
|
||||
"advanced.md#death-tests-and-threads"
|
||||
<< " for more explanation and suggested solutions, especially if"
|
||||
<< " this is the last message you see before your test times out.";
|
||||
return msg.GetString();
|
||||
|
@ -3590,6 +3590,7 @@ std::string XmlUnitTestResultPrinter::RemoveInvalidXmlCharacters(
|
||||
|
||||
// The following routines generate an XML representation of a UnitTest
|
||||
// object.
|
||||
// GOOGLETEST_CM0009 DO NOT DELETE
|
||||
//
|
||||
// This is how Google Test concepts map to the DTD:
|
||||
//
|
||||
|
@ -31,12 +31,11 @@
|
||||
|
||||
"""Tests the text output of Google C++ Testing and Mocking Framework.
|
||||
|
||||
|
||||
SYNOPSIS
|
||||
googletest_output_test.py --build_dir=BUILD/DIR --gengolden
|
||||
# where BUILD/DIR contains the built googletest-output-test_ file.
|
||||
googletest_output_test.py --gengolden
|
||||
googletest_output_test.py
|
||||
To update the golden file:
|
||||
googletest_output_test.py --build_dir=BUILD/DIR --gengolden
|
||||
where BUILD/DIR contains the built googletest-output-test_ file.
|
||||
googletest_output_test.py --gengolden
|
||||
googletest_output_test.py
|
||||
"""
|
||||
|
||||
__author__ = 'wan@google.com (Zhanyong Wan)'
|
||||
|
@ -36,15 +36,13 @@ __author__ = 'wan@google.com (Zhanyong Wan)'
|
||||
import os
|
||||
import sys
|
||||
|
||||
IS_LINUX = os.name == 'posix' and os.uname()[0] == 'Linux'
|
||||
IS_WINDOWS = os.name == 'nt'
|
||||
IS_CYGWIN = os.name == 'posix' and 'CYGWIN' in os.uname()[0]
|
||||
|
||||
import atexit
|
||||
import shutil
|
||||
import tempfile
|
||||
import unittest
|
||||
_test_module = unittest
|
||||
import unittest as _test_module
|
||||
|
||||
try:
|
||||
import subprocess
|
||||
@ -74,7 +72,7 @@ def SetEnvVar(env_var, value):
|
||||
# Here we expose a class from a particular module, depending on the
|
||||
# environment. The comment suppresses the 'Invalid variable name' lint
|
||||
# complaint.
|
||||
TestCase = _test_module.TestCase # pylint: disable-msg=C6409
|
||||
TestCase = _test_module.TestCase # pylint: disable=C6409
|
||||
|
||||
# Initially maps a flag to its default value. After
|
||||
# _ParseAndStripGTestFlags() is called, maps a flag to its actual value.
|
||||
@ -88,7 +86,7 @@ def _ParseAndStripGTestFlags(argv):
|
||||
|
||||
# Suppresses the lint complaint about a global variable since we need it
|
||||
# here to maintain module-wide state.
|
||||
global _gtest_flags_are_parsed # pylint: disable-msg=W0603
|
||||
global _gtest_flags_are_parsed # pylint: disable=W0603
|
||||
if _gtest_flags_are_parsed:
|
||||
return
|
||||
|
||||
|
0
googletest/test/gtest_testbridge_test.py
Normal file → Executable file
0
googletest/test/gtest_testbridge_test.py
Normal file → Executable file
Loading…
Reference in New Issue
Block a user