mirror of
https://github.com/google/googletest.git
synced 2024-12-27 10:11:03 +08:00
Fix link to FAQ in Primer.md
This commit is contained in:
parent
1f8fe13618
commit
ebd1d0887c
@ -265,7 +265,7 @@ int SmallestPrimeCommonDivisor(int m, int n) { ... }
|
|||||||
int n) {
|
int n) {
|
||||||
if (MutuallyPrime(m, n))
|
if (MutuallyPrime(m, n))
|
||||||
return ::testing::AssertionSuccess();
|
return ::testing::AssertionSuccess();
|
||||||
|
|
||||||
return ::testing::AssertionFailure()
|
return ::testing::AssertionFailure()
|
||||||
<< m_expr << " and " << n_expr << " (" << m << " and " << n
|
<< m_expr << " and " << n_expr << " (" << m << " and " << n
|
||||||
<< ") are not mutually prime, " << "as they have a common divisor "
|
<< ") are not mutually prime, " << "as they have a common divisor "
|
||||||
@ -804,7 +804,7 @@ For example,
|
|||||||
11: EXPECT_EQ(1, Bar(n));
|
11: EXPECT_EQ(1, Bar(n));
|
||||||
12: EXPECT_EQ(2, Bar(n + 1));
|
12: EXPECT_EQ(2, Bar(n + 1));
|
||||||
13: }
|
13: }
|
||||||
14:
|
14:
|
||||||
15: TEST(FooTest, Bar) {
|
15: TEST(FooTest, Bar) {
|
||||||
16: {
|
16: {
|
||||||
17: SCOPED_TRACE("A"); // This trace point will be included in
|
17: SCOPED_TRACE("A"); // This trace point will be included in
|
||||||
@ -1199,9 +1199,9 @@ which are all in the `testing` namespace:
|
|||||||
| `Values(v1, v2, ..., vN)` | Yields values `{v1, v2, ..., vN}`. |
|
| `Values(v1, v2, ..., vN)` | Yields values `{v1, v2, ..., vN}`. |
|
||||||
| `ValuesIn(container)` and `ValuesIn(begin, end)` | Yields values from a C-style array, an STL-style container, or an iterator range `[begin, end)`. `container`, `begin`, and `end` can be expressions whose values are determined at run time. |
|
| `ValuesIn(container)` and `ValuesIn(begin, end)` | Yields values from a C-style array, an STL-style container, or an iterator range `[begin, end)`. `container`, `begin`, and `end` can be expressions whose values are determined at run time. |
|
||||||
| `Bool()` | Yields sequence `{false, true}`. |
|
| `Bool()` | Yields sequence `{false, true}`. |
|
||||||
| `Combine(g1, g2, ..., gN)` | Yields all combinations (the Cartesian product for the math savvy) of the values generated by the `N` generators. This is only available if your system provides the `<tr1/tuple>` header. If you are sure your system does, and Google Test disagrees, you can override it by defining `GTEST_HAS_TR1_TUPLE=1`. See comments in [include/gtest/internal/gtest-port.h](https://github.com/google/googletest/blob/master/googletest/include/gtest/internal/gtest-port.h) for more information. |
|
| `Combine(g1, g2, ..., gN)` | Yields all combinations (the Cartesian product for the math savvy) of the values generated by the `N` generators. This is only available if your system provides the `<tr1/tuple>` header. If you are sure your system does, and Google Test disagrees, you can override it by defining `GTEST_HAS_TR1_TUPLE=1`. See comments in [include/gtest/internal/gtest-port.h](../include/gtest/internal/gtest-port.h) for more information. |
|
||||||
|
|
||||||
For more details, see the comments at the definitions of these functions in the [source code](https://github.com/google/googletest/blob/master/googletest/include/gtest/gtest-param-test.h).
|
For more details, see the comments at the definitions of these functions in the [source code](../include/gtest/gtest-param-test.h).
|
||||||
|
|
||||||
The following statement will instantiate tests from the `FooTest` test case
|
The following statement will instantiate tests from the `FooTest` test case
|
||||||
each with parameter values `"meeny"`, `"miny"`, and `"moe"`.
|
each with parameter values `"meeny"`, `"miny"`, and `"moe"`.
|
||||||
@ -1249,8 +1249,8 @@ tests in the given test case, whether their definitions come before or
|
|||||||
_after_ the `INSTANTIATE_TEST_CASE_P` statement.
|
_after_ the `INSTANTIATE_TEST_CASE_P` statement.
|
||||||
|
|
||||||
You can see
|
You can see
|
||||||
[these](https://github.com/google/googletest/blob/master/googletest/samples/sample7_unittest.cc)
|
[these](../samples/sample7_unittest.cc)
|
||||||
[files](https://github.com/google/googletest/blob/master/googletest/samples/sample8_unittest.cc) for more examples.
|
[files](../samples/sample8_unittest.cc) for more examples.
|
||||||
|
|
||||||
_Availability_: Linux, Windows (requires MSVC 8.0 or above), Mac; since version 1.2.0.
|
_Availability_: Linux, Windows (requires MSVC 8.0 or above), Mac; since version 1.2.0.
|
||||||
|
|
||||||
@ -1646,8 +1646,8 @@ _Availability:_ Linux, Windows, Mac; since v1.4.0.
|
|||||||
## Defining Event Listeners ##
|
## Defining Event Listeners ##
|
||||||
|
|
||||||
To define a event listener, you subclass either
|
To define a event listener, you subclass either
|
||||||
[testing::TestEventListener](https://github.com/google/googletest/blob/master/googletest/include/gtest/gtest.h#L991)
|
[testing::TestEventListener](../include/gtest/gtest.h#L991)
|
||||||
or [testing::EmptyTestEventListener](https://github.com/google/googletest/blob/master/googletest/include/gtest/gtest.h#L1044).
|
or [testing::EmptyTestEventListener](../include/gtest/gtest.h#L1044).
|
||||||
The former is an (abstract) interface, where <i>each pure virtual method<br>
|
The former is an (abstract) interface, where <i>each pure virtual method<br>
|
||||||
can be overridden to handle a test event</i> (For example, when a test
|
can be overridden to handle a test event</i> (For example, when a test
|
||||||
starts, the `OnTestStart()` method will be called.). The latter provides
|
starts, the `OnTestStart()` method will be called.). The latter provides
|
||||||
@ -1656,10 +1656,10 @@ subclass only needs to override the methods it cares about.
|
|||||||
|
|
||||||
When an event is fired, its context is passed to the handler function
|
When an event is fired, its context is passed to the handler function
|
||||||
as an argument. The following argument types are used:
|
as an argument. The following argument types are used:
|
||||||
* [UnitTest](https://github.com/google/googletest/blob/master/googletest/include/gtest/gtest.h#L1151) reflects the state of the entire test program,
|
* [UnitTest](../include/gtest/gtest.h#L1151) reflects the state of the entire test program,
|
||||||
* [TestCase](https://github.com/google/googletest/blob/master/googletest/include/gtest/gtest.h#L778) has information about a test case, which can contain one or more tests,
|
* [TestCase](../include/gtest/gtest.h#L778) has information about a test case, which can contain one or more tests,
|
||||||
* [TestInfo](https://github.com/google/googletest/blob/master/googletest/include/gtest/gtest.h#L644) contains the state of a test, and
|
* [TestInfo](../include/gtest/gtest.h#L644) contains the state of a test, and
|
||||||
* [TestPartResult](https://github.com/google/googletest/blob/master/googletest/include/gtest/gtest-test-part.h#L47) represents the result of a test assertion.
|
* [TestPartResult](../include/gtest/gtest-test-part.h#L47) represents the result of a test assertion.
|
||||||
|
|
||||||
An event handler function can examine the argument it receives to find
|
An event handler function can examine the argument it receives to find
|
||||||
out interesting information about the event and the test program's
|
out interesting information about the event and the test program's
|
||||||
@ -1695,7 +1695,7 @@ state. Here's an example:
|
|||||||
|
|
||||||
To use the event listener you have defined, add an instance of it to
|
To use the event listener you have defined, add an instance of it to
|
||||||
the Google Test event listener list (represented by class
|
the Google Test event listener list (represented by class
|
||||||
[TestEventListeners](https://github.com/google/googletest/blob/master/googletest/include/gtest/gtest.h#L1064)
|
[TestEventListeners](../include/gtest/gtest.h#L1064)
|
||||||
- note the "s" at the end of the name) in your
|
- note the "s" at the end of the name) in your
|
||||||
`main()` function, before calling `RUN_ALL_TESTS()`:
|
`main()` function, before calling `RUN_ALL_TESTS()`:
|
||||||
```
|
```
|
||||||
@ -1723,7 +1723,7 @@ event listener list and delete it. You can do so by adding one line:
|
|||||||
|
|
||||||
Now, sit back and enjoy a completely different output from your
|
Now, sit back and enjoy a completely different output from your
|
||||||
tests. For more details, you can read this
|
tests. For more details, you can read this
|
||||||
[sample](https://github.com/google/googletest/blob/master/googletest/samples/sample9_unittest.cc).
|
[sample](../samples/sample9_unittest.cc).
|
||||||
|
|
||||||
You may append more than one listener to the list. When an `On*Start()`
|
You may append more than one listener to the list. When an `On*Start()`
|
||||||
or `OnTestPartResult()` event is fired, the listeners will receive it in
|
or `OnTestPartResult()` event is fired, the listeners will receive it in
|
||||||
@ -1748,7 +1748,7 @@ failures. This ensures that failures generated by the latter are
|
|||||||
attributed to the right test by the former.
|
attributed to the right test by the former.
|
||||||
|
|
||||||
We have a sample of failure-raising listener
|
We have a sample of failure-raising listener
|
||||||
[here](https://github.com/google/googletest/blob/master/googletest/samples/sample10_unittest.cc).
|
[here](../samples/sample10_unittest.cc).
|
||||||
|
|
||||||
# Running Test Programs: Advanced Options #
|
# Running Test Programs: Advanced Options #
|
||||||
|
|
||||||
@ -2173,7 +2173,7 @@ and you should see an `OUTPUT_DIR` directory being created with files
|
|||||||
`gtest/gtest.h` and `gtest/gtest-all.cc` in it. These files contain
|
`gtest/gtest.h` and `gtest/gtest-all.cc` in it. These files contain
|
||||||
everything you need to use Google Test. Just copy them to anywhere
|
everything you need to use Google Test. Just copy them to anywhere
|
||||||
you want and you are ready to write tests. You can use the
|
you want and you are ready to write tests. You can use the
|
||||||
[scripts/test/Makefile](https://github.com/google/googletest/blob/master/googletest/scripts/test/Makefile)
|
[scripts/test/Makefile](../scripts/test/Makefile)
|
||||||
file as an example on how to compile your tests against them.
|
file as an example on how to compile your tests against them.
|
||||||
|
|
||||||
# Where to Go from Here #
|
# Where to Go from Here #
|
||||||
|
@ -28,11 +28,11 @@ list can help you decide whether it is for you too.
|
|||||||
* `SCOPED_TRACE` helps you understand the context of an assertion failure when it comes from inside a sub-routine or loop.
|
* `SCOPED_TRACE` helps you understand the context of an assertion failure when it comes from inside a sub-routine or loop.
|
||||||
* You can decide which tests to run using name patterns. This saves time when you want to quickly reproduce a test failure.
|
* You can decide which tests to run using name patterns. This saves time when you want to quickly reproduce a test failure.
|
||||||
* Google Test can generate XML test result reports that can be parsed by popular continuous build system like Hudson.
|
* Google Test can generate XML test result reports that can be parsed by popular continuous build system like Hudson.
|
||||||
* Simple things are easy in Google Test, while hard things are possible: in addition to advanced features like [global test environments](https://github.com/google/googletest/blob/master/googletest/docs/AdvancedGuide.md#global-set-up-and-tear-down) and tests parameterized by [values](https://github.com/google/googletest/blob/master/googletest/docs/AdvancedGuide.md#value-parameterized-tests) or [types](https://github.com/google/googletest/blob/master/googletest/docs/AdvancedGuide.md#typed-tests), Google Test supports various ways for the user to extend the framework -- if Google Test doesn't do something out of the box, chances are that a user can implement the feature using Google Test's public API, without changing Google Test itself. In particular, you can:
|
* Simple things are easy in Google Test, while hard things are possible: in addition to advanced features like [global test environments](AdvancedGuide.md#global-set-up-and-tear-down) and tests parameterized by [values](AdvancedGuide.md#value-parameterized-tests) or [types](docs/AdvancedGuide.md#typed-tests), Google Test supports various ways for the user to extend the framework -- if Google Test doesn't do something out of the box, chances are that a user can implement the feature using Google Test's public API, without changing Google Test itself. In particular, you can:
|
||||||
* expand your testing vocabulary by defining [custom predicates](https://github.com/google/googletest/blob/master/googletest/docs/AdvancedGuide.md#predicate-assertions-for-better-error-messages),
|
* expand your testing vocabulary by defining [custom predicates](AdvancedGuide.md#predicate-assertions-for-better-error-messages),
|
||||||
* teach Google Test how to [print your types](https://github.com/google/googletest/blob/master/googletest/docs/AdvancedGuide.md#teaching-google-test-how-to-print-your-values),
|
* teach Google Test how to [print your types](AdvancedGuide.md#teaching-google-test-how-to-print-your-values),
|
||||||
* define your own testing macros or utilities and verify them using Google Test's [Service Provider Interface](https://github.com/google/googletest/blob/master/googletest/docs/AdvancedGuide.md#catching-failures), and
|
* define your own testing macros or utilities and verify them using Google Test's [Service Provider Interface](AdvancedGuide.md#catching-failures), and
|
||||||
* reflect on the test cases or change the test output format by intercepting the [test events](https://github.com/google/googletest/blob/master/googletest/docs/AdvancedGuide.md#extending-google-test-by-handling-test-events).
|
* reflect on the test cases or change the test output format by intercepting the [test events](AdvancedGuide.md#extending-google-test-by-handling-test-events).
|
||||||
|
|
||||||
## I'm getting warnings when compiling Google Test. Would you fix them? ##
|
## I'm getting warnings when compiling Google Test. Would you fix them? ##
|
||||||
|
|
||||||
@ -201,7 +201,7 @@ we don't have a convention on the order of the two arguments for
|
|||||||
twice in the implementation, making it even harder to understand and
|
twice in the implementation, making it even harder to understand and
|
||||||
maintain. We believe the benefit doesn't justify the cost.
|
maintain. We believe the benefit doesn't justify the cost.
|
||||||
|
|
||||||
Finally, with the growth of Google Mock's [matcher](http://code.google.com/p/googlemock/wiki/CookBook#Using_Matchers_in_Google_Test_Assertions) library, we are
|
Finally, with the growth of Google Mock's [matcher](../../googlemock/docs/CookBook.md#using-matchers-in-google-test-assertions) library, we are
|
||||||
encouraging people to use the unified `EXPECT_THAT(value, matcher)`
|
encouraging people to use the unified `EXPECT_THAT(value, matcher)`
|
||||||
syntax more often in tests. One significant advantage of the matcher
|
syntax more often in tests. One significant advantage of the matcher
|
||||||
approach is that matchers can be easily combined to form new matchers,
|
approach is that matchers can be easily combined to form new matchers,
|
||||||
@ -409,7 +409,7 @@ If necessary, you can continue to derive test fixtures from a derived fixture.
|
|||||||
Google Test has no limit on how deep the hierarchy can be.
|
Google Test has no limit on how deep the hierarchy can be.
|
||||||
|
|
||||||
For a complete example using derived test fixtures, see
|
For a complete example using derived test fixtures, see
|
||||||
[sample5](https://github.com/google/googletest/blob/master/googletest/samples/sample5_unittest.cc).
|
[sample5](../samples/sample5_unittest.cc).
|
||||||
|
|
||||||
## My compiler complains "void value not ignored as it ought to be." What does this mean? ##
|
## My compiler complains "void value not ignored as it ought to be." What does this mean? ##
|
||||||
|
|
||||||
@ -849,7 +849,7 @@ expression syntax
|
|||||||
(http://en.wikipedia.org/wiki/Regular_expression#POSIX_Extended_Regular_Expressions).
|
(http://en.wikipedia.org/wiki/Regular_expression#POSIX_Extended_Regular_Expressions).
|
||||||
On Windows, it uses a limited variant of regular expression
|
On Windows, it uses a limited variant of regular expression
|
||||||
syntax. For more details, see the
|
syntax. For more details, see the
|
||||||
[regular expression syntax](AdvancedGuide#Regular_Expression_Syntax.md).
|
[regular expression syntax](AdvancedGuide.md#Regular_Expression_Syntax).
|
||||||
|
|
||||||
## I have a fixture class Foo, but TEST\_F(Foo, Bar) gives me error "no matching function for call to Foo::Foo()". Why? ##
|
## I have a fixture class Foo, but TEST\_F(Foo, Bar) gives me error "no matching function for call to Foo::Foo()". Why? ##
|
||||||
|
|
||||||
@ -956,7 +956,7 @@ using gtest-md.vcproj instead of gtest.vcproj.
|
|||||||
|
|
||||||
## I put my tests in a library and Google Test doesn't run them. What's happening? ##
|
## I put my tests in a library and Google Test doesn't run them. What's happening? ##
|
||||||
Have you read a
|
Have you read a
|
||||||
[warning](https://github.com/google/googletest/blob/master/googletest/docs/Primer.md#important-note-for-visual-c-users) on
|
[warning](Primer.md#important-note-for-visual-c-users) on
|
||||||
the Google Test Primer page?
|
the Google Test Primer page?
|
||||||
|
|
||||||
## I want to use Google Test with Visual Studio but don't know where to start. ##
|
## I want to use Google Test with Visual Studio but don't know where to start. ##
|
||||||
@ -1059,14 +1059,14 @@ TEST_F(CoolTest, DoSomething) {
|
|||||||
## How do I build Google Testing Framework with Xcode 4? ##
|
## How do I build Google Testing Framework with Xcode 4? ##
|
||||||
|
|
||||||
If you try to build Google Test's Xcode project with Xcode 4.0 or later, you may encounter an error message that looks like
|
If you try to build Google Test's Xcode project with Xcode 4.0 or later, you may encounter an error message that looks like
|
||||||
"Missing SDK in target gtest\_framework: /Developer/SDKs/MacOSX10.4u.sdk". That means that Xcode does not support the SDK the project is targeting. See the Xcode section in the [README](https://github.com/google/googletest/blob/master/googletest/README.md) file on how to resolve this.
|
"Missing SDK in target gtest\_framework: /Developer/SDKs/MacOSX10.4u.sdk". That means that Xcode does not support the SDK the project is targeting. See the Xcode section in the [README](../README.md) file on how to resolve this.
|
||||||
|
|
||||||
## My question is not covered in your FAQ! ##
|
## My question is not covered in your FAQ! ##
|
||||||
|
|
||||||
If you cannot find the answer to your question in this FAQ, there are
|
If you cannot find the answer to your question in this FAQ, there are
|
||||||
some other resources you can use:
|
some other resources you can use:
|
||||||
|
|
||||||
1. read other [wiki pages](https://github.com/google/googletest/tree/master/googletest/docs),
|
1. read other [wiki pages](../docs),
|
||||||
1. search the mailing list [archive](https://groups.google.com/forum/#!forum/googletestframework),
|
1. search the mailing list [archive](https://groups.google.com/forum/#!forum/googletestframework),
|
||||||
1. ask it on [googletestframework@googlegroups.com](mailto:googletestframework@googlegroups.com) and someone will answer it (to prevent spam, we require you to join the [discussion group](http://groups.google.com/group/googletestframework) before you can post.).
|
1. ask it on [googletestframework@googlegroups.com](mailto:googletestframework@googlegroups.com) and someone will answer it (to prevent spam, we require you to join the [discussion group](http://groups.google.com/group/googletestframework) before you can post.).
|
||||||
|
|
||||||
|
@ -147,7 +147,7 @@ but it's no longer necessary since v1.6.0 (if `<<` is supported, it
|
|||||||
will be called to print the arguments when the assertion fails;
|
will be called to print the arguments when the assertion fails;
|
||||||
otherwise Google Test will attempt to print them in the best way it
|
otherwise Google Test will attempt to print them in the best way it
|
||||||
can. For more details and how to customize the printing of the
|
can. For more details and how to customize the printing of the
|
||||||
arguments, see this Google Mock [recipe](http://code.google.com/p/googlemock/wiki/CookBook#Teaching_Google_Mock_How_to_Print_Your_Values).).
|
arguments, see this Google Mock [recipe](../../googlemock/docs/CookBook.md#teaching-google-mock-how-to-print-your-values).).
|
||||||
|
|
||||||
These assertions can work with a user-defined type, but only if you define the
|
These assertions can work with a user-defined type, but only if you define the
|
||||||
corresponding comparison operator (e.g. `==`, `<`, etc). If the corresponding
|
corresponding comparison operator (e.g. `==`, `<`, etc). If the corresponding
|
||||||
@ -256,7 +256,7 @@ To create a fixture, just:
|
|||||||
1. Derive a class from `::testing::Test` . Start its body with `protected:` or `public:` as we'll want to access fixture members from sub-classes.
|
1. Derive a class from `::testing::Test` . Start its body with `protected:` or `public:` as we'll want to access fixture members from sub-classes.
|
||||||
1. Inside the class, declare any objects you plan to use.
|
1. Inside the class, declare any objects you plan to use.
|
||||||
1. If necessary, write a default constructor or `SetUp()` function to prepare the objects for each test. A common mistake is to spell `SetUp()` as `Setup()` with a small `u` - don't let that happen to you.
|
1. If necessary, write a default constructor or `SetUp()` function to prepare the objects for each test. A common mistake is to spell `SetUp()` as `Setup()` with a small `u` - don't let that happen to you.
|
||||||
1. If necessary, write a destructor or `TearDown()` function to release any resources you allocated in `SetUp()` . To learn when you should use the constructor/destructor and when you should use `SetUp()/TearDown()`, read this [FAQ entry](http://code.google.com/p/googletest/wiki/FAQ#Should_I_use_the_constructor/destructor_of_the_test_fixture_or_t).
|
1. If necessary, write a destructor or `TearDown()` function to release any resources you allocated in `SetUp()` . To learn when you should use the constructor/destructor and when you should use `SetUp()/TearDown()`, read this [FAQ entry](FAQ.md#should-i-use-the-constructordestructor-of-the-test-fixture-or-the-set-uptear-down-function).
|
||||||
1. If needed, define subroutines for your tests to share.
|
1. If needed, define subroutines for your tests to share.
|
||||||
|
|
||||||
When using a fixture, use `TEST_F()` instead of `TEST()` as it allows you to
|
When using a fixture, use `TEST_F()` instead of `TEST()` as it allows you to
|
||||||
|
@ -123,7 +123,7 @@ c is 10<br>
|
|||||||
|
|
||||||
**Notes:**
|
**Notes:**
|
||||||
|
|
||||||
1. If you see a compiler error "no matching function to call" when using `ASSERT_PRED*` or `EXPECT_PRED*`, please see [this](http://code.google.com/p/googletest/wiki/V1_5_FAQ#The_compiler_complains_%22no_matching_function_to_call%22) for how to resolve it.
|
1. If you see a compiler error "no matching function to call" when using `ASSERT_PRED*` or `EXPECT_PRED*`, please see [this](V1_5_FAQ.md#the-compiler-complains-about-undefined-references-to-some-static-const-member-variables-but-i-did-define-them-in-the-class-body-whats-wrong) for how to resolve it.
|
||||||
1. Currently we only provide predicate assertions of arity <= 5. If you need a higher-arity assertion, let us know.
|
1. Currently we only provide predicate assertions of arity <= 5. If you need a higher-arity assertion, let us know.
|
||||||
|
|
||||||
_Availability_: Linux, Windows, Mac
|
_Availability_: Linux, Windows, Mac
|
||||||
@ -263,7 +263,7 @@ int SmallestPrimeCommonDivisor(int m, int n) { ... }
|
|||||||
int n) {
|
int n) {
|
||||||
if (MutuallyPrime(m, n))
|
if (MutuallyPrime(m, n))
|
||||||
return ::testing::AssertionSuccess();
|
return ::testing::AssertionSuccess();
|
||||||
|
|
||||||
return ::testing::AssertionFailure()
|
return ::testing::AssertionFailure()
|
||||||
<< m_expr << " and " << n_expr << " (" << m << " and " << n
|
<< m_expr << " and " << n_expr << " (" << m << " and " << n
|
||||||
<< ") are not mutually prime, " << "as they have a common divisor "
|
<< ") are not mutually prime, " << "as they have a common divisor "
|
||||||
@ -444,7 +444,7 @@ Since these precondition checks cause the processes to die, we call such tests
|
|||||||
_death tests_. More generally, any test that checks that a program terminates
|
_death tests_. More generally, any test that checks that a program terminates
|
||||||
in an expected fashion is also a death test.
|
in an expected fashion is also a death test.
|
||||||
|
|
||||||
If you want to test `EXPECT_*()/ASSERT_*()` failures in your test code, see [Catching Failures](#Catching_Failures.md).
|
If you want to test `EXPECT_*()/ASSERT_*()` failures in your test code, see [Catching Failures](#catching-failures).
|
||||||
|
|
||||||
## How to Write a Death Test ##
|
## How to Write a Death Test ##
|
||||||
|
|
||||||
@ -729,7 +729,7 @@ For example,
|
|||||||
11: EXPECT_EQ(1, Bar(n));
|
11: EXPECT_EQ(1, Bar(n));
|
||||||
12: EXPECT_EQ(2, Bar(n + 1));
|
12: EXPECT_EQ(2, Bar(n + 1));
|
||||||
13: }
|
13: }
|
||||||
14:
|
14:
|
||||||
15: TEST(FooTest, Bar) {
|
15: TEST(FooTest, Bar) {
|
||||||
16: {
|
16: {
|
||||||
17: SCOPED_TRACE("A"); // This trace point will be included in
|
17: SCOPED_TRACE("A"); // This trace point will be included in
|
||||||
@ -1114,9 +1114,9 @@ which are all in the `testing` namespace:
|
|||||||
| `Values(v1, v2, ..., vN)` | Yields values `{v1, v2, ..., vN}`. |
|
| `Values(v1, v2, ..., vN)` | Yields values `{v1, v2, ..., vN}`. |
|
||||||
| `ValuesIn(container)` and `ValuesIn(begin, end)` | Yields values from a C-style array, an STL-style container, or an iterator range `[begin, end)`. |
|
| `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}`. |
|
| `Bool()` | Yields sequence `{false, true}`. |
|
||||||
| `Combine(g1, g2, ..., gN)` | Yields all combinations (the Cartesian product for the math savvy) of the values generated by the `N` generators. This is only available if your system provides the `<tr1/tuple>` header. If you are sure your system does, and Google Test disagrees, you can override it by defining `GTEST_HAS_TR1_TUPLE=1`. See comments in [include/gtest/internal/gtest-port.h](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/internal/gtest-port.h) for more information. |
|
| `Combine(g1, g2, ..., gN)` | Yields all combinations (the Cartesian product for the math savvy) of the values generated by the `N` generators. This is only available if your system provides the `<tr1/tuple>` header. If you are sure your system does, and Google Test disagrees, you can override it by defining `GTEST_HAS_TR1_TUPLE=1`. See comments in [include/gtest/internal/gtest-port.h](../include/gtest/internal/gtest-port.h) for more information. |
|
||||||
|
|
||||||
For more details, see the comments at the definitions of these functions in the [source code](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/gtest-param-test.h).
|
For more details, see the comments at the definitions of these functions in the [source code](../include/gtest/gtest-param-test.h).
|
||||||
|
|
||||||
The following statement will instantiate tests from the `FooTest` test case
|
The following statement will instantiate tests from the `FooTest` test case
|
||||||
each with parameter values `"meeny"`, `"miny"`, and `"moe"`.
|
each with parameter values `"meeny"`, `"miny"`, and `"moe"`.
|
||||||
@ -1141,7 +1141,7 @@ names:
|
|||||||
* `InstantiationName/FooTest.HasBlahBlah/1` for `"miny"`
|
* `InstantiationName/FooTest.HasBlahBlah/1` for `"miny"`
|
||||||
* `InstantiationName/FooTest.HasBlahBlah/2` for `"moe"`
|
* `InstantiationName/FooTest.HasBlahBlah/2` for `"moe"`
|
||||||
|
|
||||||
You can use these names in [--gtest\_filter](#Running_a_Subset_of_the_Tests.md).
|
You can use these names in [--gtest\-filter](#running-a-subset-of-the-tests).
|
||||||
|
|
||||||
This statement will instantiate all tests from `FooTest` again, each
|
This statement will instantiate all tests from `FooTest` again, each
|
||||||
with parameter values `"cat"` and `"dog"`:
|
with parameter values `"cat"` and `"dog"`:
|
||||||
@ -1164,8 +1164,8 @@ tests in the given test case, whether their definitions come before or
|
|||||||
_after_ the `INSTANTIATE_TEST_CASE_P` statement.
|
_after_ the `INSTANTIATE_TEST_CASE_P` statement.
|
||||||
|
|
||||||
You can see
|
You can see
|
||||||
[these](http://code.google.com/p/googletest/source/browse/trunk/samples/sample7_unittest.cc)
|
[these](../samples/sample7_unittest.cc)
|
||||||
[files](http://code.google.com/p/googletest/source/browse/trunk/samples/sample8_unittest.cc) for more examples.
|
[files](../samples/sample8_unittest.cc) for more examples.
|
||||||
|
|
||||||
_Availability_: Linux, Windows (requires MSVC 8.0 or above), Mac; since version 1.2.0.
|
_Availability_: Linux, Windows (requires MSVC 8.0 or above), Mac; since version 1.2.0.
|
||||||
|
|
||||||
@ -1561,8 +1561,8 @@ _Availability:_ Linux, Windows, Mac; since v1.4.0.
|
|||||||
## Defining Event Listeners ##
|
## Defining Event Listeners ##
|
||||||
|
|
||||||
To define a event listener, you subclass either
|
To define a event listener, you subclass either
|
||||||
[testing::TestEventListener](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/gtest.h#855)
|
[testing::TestEventListener](../include/gtest/gtest.h#L855)
|
||||||
or [testing::EmptyTestEventListener](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/gtest.h#905).
|
or [testing::EmptyTestEventListener](../include/gtest/gtest.h#L905).
|
||||||
The former is an (abstract) interface, where <i>each pure virtual method<br>
|
The former is an (abstract) interface, where <i>each pure virtual method<br>
|
||||||
can be overridden to handle a test event</i> (For example, when a test
|
can be overridden to handle a test event</i> (For example, when a test
|
||||||
starts, the `OnTestStart()` method will be called.). The latter provides
|
starts, the `OnTestStart()` method will be called.). The latter provides
|
||||||
@ -1571,10 +1571,10 @@ subclass only needs to override the methods it cares about.
|
|||||||
|
|
||||||
When an event is fired, its context is passed to the handler function
|
When an event is fired, its context is passed to the handler function
|
||||||
as an argument. The following argument types are used:
|
as an argument. The following argument types are used:
|
||||||
* [UnitTest](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/gtest.h#1007) reflects the state of the entire test program,
|
* [UnitTest](../include/gtest/gtest.h#L1007) reflects the state of the entire test program,
|
||||||
* [TestCase](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/gtest.h#689) has information about a test case, which can contain one or more tests,
|
* [TestCase](../include/gtest/gtest.h#L689) has information about a test case, which can contain one or more tests,
|
||||||
* [TestInfo](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/gtest.h#599) contains the state of a test, and
|
* [TestInfo](../include/gtest/gtest.h#L599) contains the state of a test, and
|
||||||
* [TestPartResult](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/gtest-test-part.h#42) represents the result of a test assertion.
|
* [TestPartResult](../include/gtest/gtest-test-part.h#L42) represents the result of a test assertion.
|
||||||
|
|
||||||
An event handler function can examine the argument it receives to find
|
An event handler function can examine the argument it receives to find
|
||||||
out interesting information about the event and the test program's
|
out interesting information about the event and the test program's
|
||||||
@ -1610,7 +1610,7 @@ state. Here's an example:
|
|||||||
|
|
||||||
To use the event listener you have defined, add an instance of it to
|
To use the event listener you have defined, add an instance of it to
|
||||||
the Google Test event listener list (represented by class
|
the Google Test event listener list (represented by class
|
||||||
[TestEventListeners](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/gtest.h#929)
|
[TestEventListeners](../include/gtest/gtest.h#L929)
|
||||||
- note the "s" at the end of the name) in your
|
- note the "s" at the end of the name) in your
|
||||||
`main()` function, before calling `RUN_ALL_TESTS()`:
|
`main()` function, before calling `RUN_ALL_TESTS()`:
|
||||||
```
|
```
|
||||||
@ -1638,7 +1638,7 @@ event listener list and delete it. You can do so by adding one line:
|
|||||||
|
|
||||||
Now, sit back and enjoy a completely different output from your
|
Now, sit back and enjoy a completely different output from your
|
||||||
tests. For more details, you can read this
|
tests. For more details, you can read this
|
||||||
[sample](http://code.google.com/p/googletest/source/browse/trunk/samples/sample9_unittest.cc).
|
[sample](../samples/sample9_unittest.cc).
|
||||||
|
|
||||||
You may append more than one listener to the list. When an `On*Start()`
|
You may append more than one listener to the list. When an `On*Start()`
|
||||||
or `OnTestPartResult()` event is fired, the listeners will receive it in
|
or `OnTestPartResult()` event is fired, the listeners will receive it in
|
||||||
@ -1663,7 +1663,7 @@ failures. This ensures that failures generated by the latter are
|
|||||||
attributed to the right test by the former.
|
attributed to the right test by the former.
|
||||||
|
|
||||||
We have a sample of failure-raising listener
|
We have a sample of failure-raising listener
|
||||||
[here](http://code.google.com/p/googletest/source/browse/trunk/samples/sample10_unittest.cc).
|
[here](../samples/sample10_unittest.cc).
|
||||||
|
|
||||||
# Running Test Programs: Advanced Options #
|
# Running Test Programs: Advanced Options #
|
||||||
|
|
||||||
@ -1783,12 +1783,12 @@ _Availability:_ Linux, Windows, Mac.
|
|||||||
|
|
||||||
### Temporarily Enabling Disabled Tests ###
|
### Temporarily Enabling Disabled Tests ###
|
||||||
|
|
||||||
To include [disabled tests](#Temporarily_Disabling_Tests.md) in test
|
To include [disabled tests](#temporarily-disabling-tests) in test
|
||||||
execution, just invoke the test program with the
|
execution, just invoke the test program with the
|
||||||
`--gtest_also_run_disabled_tests` flag or set the
|
`--gtest_also_run_disabled_tests` flag or set the
|
||||||
`GTEST_ALSO_RUN_DISABLED_TESTS` environment variable to a value other
|
`GTEST_ALSO_RUN_DISABLED_TESTS` environment variable to a value other
|
||||||
than `0`. You can combine this with the
|
than `0`. You can combine this with the
|
||||||
[--gtest\_filter](#Running_a_Subset_of_the_Tests.md) flag to further select
|
[--gtest\_filter](#running-a-subset-of-the-tests) flag to further select
|
||||||
which disabled tests to run.
|
which disabled tests to run.
|
||||||
|
|
||||||
_Availability:_ Linux, Windows, Mac; since version 1.3.0.
|
_Availability:_ Linux, Windows, Mac; since version 1.3.0.
|
||||||
@ -2086,11 +2086,11 @@ and you should see an `OUTPUT_DIR` directory being created with files
|
|||||||
`gtest/gtest.h` and `gtest/gtest-all.cc` in it. These files contain
|
`gtest/gtest.h` and `gtest/gtest-all.cc` in it. These files contain
|
||||||
everything you need to use Google Test. Just copy them to anywhere
|
everything you need to use Google Test. Just copy them to anywhere
|
||||||
you want and you are ready to write tests. You can use the
|
you want and you are ready to write tests. You can use the
|
||||||
[scrpts/test/Makefile](http://code.google.com/p/googletest/source/browse/trunk/scripts/test/Makefile)
|
[scrpts/test/Makefile](../scripts/test/Makefile)
|
||||||
file as an example on how to compile your tests against them.
|
file as an example on how to compile your tests against them.
|
||||||
|
|
||||||
# Where to Go from Here #
|
# Where to Go from Here #
|
||||||
|
|
||||||
Congratulations! You've now learned more advanced Google Test tools and are
|
Congratulations! You've now learned more advanced Google Test tools and are
|
||||||
ready to tackle more complex testing tasks. If you want to dive even deeper, you
|
ready to tackle more complex testing tasks. If you want to dive even deeper, you
|
||||||
can read the [FAQ](V1_5_FAQ.md).
|
can read the [FAQ](V1_5_FAQ.md).
|
||||||
|
@ -104,7 +104,7 @@ we don't have a convention on the order of the two arguments for
|
|||||||
twice in the implementation, making it even harder to understand and
|
twice in the implementation, making it even harder to understand and
|
||||||
maintain. We believe the benefit doesn't justify the cost.
|
maintain. We believe the benefit doesn't justify the cost.
|
||||||
|
|
||||||
Finally, with the growth of Google Mock's [matcher](http://code.google.com/p/googlemock/wiki/CookBook#Using_Matchers_in_Google_Test_Assertions) library, we are
|
Finally, with the growth of Google Mock's [matcher](../../CookBook.md#using-matchers-in-google-test-assertions) library, we are
|
||||||
encouraging people to use the unified `EXPECT_THAT(value, matcher)`
|
encouraging people to use the unified `EXPECT_THAT(value, matcher)`
|
||||||
syntax more often in tests. One significant advantage of the matcher
|
syntax more often in tests. One significant advantage of the matcher
|
||||||
approach is that matchers can be easily combined to form new matchers,
|
approach is that matchers can be easily combined to form new matchers,
|
||||||
@ -651,7 +651,7 @@ EXPECT_TRUE(internal::Func(12345));
|
|||||||
|
|
||||||
## I would like to run a test several times with different parameters. Do I need to write several similar copies of it? ##
|
## I would like to run a test several times with different parameters. Do I need to write several similar copies of it? ##
|
||||||
|
|
||||||
No. You can use a feature called [value-parameterized tests](V1_5_AdvancedGuide#Value_Parameterized_Tests.md) which
|
No. You can use a feature called [value-parameterized tests](V1_5_AdvancedGuide.md#Value_Parameterized_Tests) which
|
||||||
lets you repeat your tests with different parameters, without defining it more than once.
|
lets you repeat your tests with different parameters, without defining it more than once.
|
||||||
|
|
||||||
## How do I test a file that defines main()? ##
|
## How do I test a file that defines main()? ##
|
||||||
@ -701,6 +701,7 @@ reference global and/or local variables, and can be:
|
|||||||
* a compound statement.
|
* a compound statement.
|
||||||
|
|
||||||
> Some examples are shown here:
|
> Some examples are shown here:
|
||||||
|
|
||||||
```
|
```
|
||||||
// A death test can be a simple function call.
|
// A death test can be a simple function call.
|
||||||
TEST(MyDeathTest, FunctionCall) {
|
TEST(MyDeathTest, FunctionCall) {
|
||||||
@ -744,7 +745,7 @@ On POSIX systems, Google Test uses the POSIX Extended regular
|
|||||||
expression syntax
|
expression syntax
|
||||||
(http://en.wikipedia.org/wiki/Regular_expression#POSIX_Extended_Regular_Expressions). On
|
(http://en.wikipedia.org/wiki/Regular_expression#POSIX_Extended_Regular_Expressions). On
|
||||||
Windows, it uses a limited variant of regular expression syntax. For
|
Windows, it uses a limited variant of regular expression syntax. For
|
||||||
more details, see the [regular expression syntax](V1_5_AdvancedGuide#Regular_Expression_Syntax.md).
|
more details, see the [regular expression syntax](V1_5_AdvancedGuide.md#Regular_Expression_Syntax).
|
||||||
|
|
||||||
## I have a fixture class Foo, but TEST\_F(Foo, Bar) gives me error "no matching function for call to Foo::Foo()". Why? ##
|
## I have a fixture class Foo, but TEST\_F(Foo, Bar) gives me error "no matching function for call to Foo::Foo()". Why? ##
|
||||||
|
|
||||||
@ -851,7 +852,7 @@ using gtest-md.vcproj instead of gtest.vcproj.
|
|||||||
|
|
||||||
## I put my tests in a library and Google Test doesn't run them. What's happening? ##
|
## I put my tests in a library and Google Test doesn't run them. What's happening? ##
|
||||||
Have you read a
|
Have you read a
|
||||||
[warning](V1_5_Primer#Important_note_for_Visual_C++_users.md) on
|
[warning](V1_5_Primer.md#important-note-for-visual-c-users) on
|
||||||
the Google Test Primer page?
|
the Google Test Primer page?
|
||||||
|
|
||||||
## I want to use Google Test with Visual Studio but don't know where to start. ##
|
## I want to use Google Test with Visual Studio but don't know where to start. ##
|
||||||
@ -882,4 +883,4 @@ not enough information in your question):
|
|||||||
* the name and version of your compiler,
|
* the name and version of your compiler,
|
||||||
* the complete command line flags you give to your compiler,
|
* the complete command line flags you give to your compiler,
|
||||||
* the complete compiler error messages (if the question is about compilation),
|
* the complete compiler error messages (if the question is about compilation),
|
||||||
* the _actual_ code (ideally, a minimal but complete program) that has the problem you encounter.
|
* the _actual_ code (ideally, a minimal but complete program) that has the problem you encounter.
|
||||||
|
@ -251,7 +251,7 @@ To create a fixture, just:
|
|||||||
1. Derive a class from `::testing::Test` . Start its body with `protected:` or `public:` as we'll want to access fixture members from sub-classes.
|
1. Derive a class from `::testing::Test` . Start its body with `protected:` or `public:` as we'll want to access fixture members from sub-classes.
|
||||||
1. Inside the class, declare any objects you plan to use.
|
1. Inside the class, declare any objects you plan to use.
|
||||||
1. If necessary, write a default constructor or `SetUp()` function to prepare the objects for each test. A common mistake is to spell `SetUp()` as `Setup()` with a small `u` - don't let that happen to you.
|
1. If necessary, write a default constructor or `SetUp()` function to prepare the objects for each test. A common mistake is to spell `SetUp()` as `Setup()` with a small `u` - don't let that happen to you.
|
||||||
1. If necessary, write a destructor or `TearDown()` function to release any resources you allocated in `SetUp()` . To learn when you should use the constructor/destructor and when you should use `SetUp()/TearDown()`, read this [FAQ entry](http://code.google.com/p/googletest/wiki/V1_5_FAQ#Should_I_use_the_constructor/destructor_of_the_test_fixture_or_t).
|
1. If necessary, write a destructor or `TearDown()` function to release any resources you allocated in `SetUp()` . To learn when you should use the constructor/destructor and when you should use `SetUp()/TearDown()`, read this [FAQ entry](V1_5_FAQ.md#should-i-use-the-constructordestructor-of-the-test-fixture-or-the-set-uptear-down-function).
|
||||||
1. If needed, define subroutines for your tests to share.
|
1. If needed, define subroutines for your tests to share.
|
||||||
|
|
||||||
When using a fixture, use `TEST_F()` instead of `TEST()` as it allows you to
|
When using a fixture, use `TEST_F()` instead of `TEST()` as it allows you to
|
||||||
@ -494,4 +494,4 @@ is currently _unsafe_ to use Google Test assertions from two threads
|
|||||||
concurrently on other systems (e.g. Windows). In most tests this is
|
concurrently on other systems (e.g. Windows). In most tests this is
|
||||||
not an issue as usually the assertions are done in the main thread. If
|
not an issue as usually the assertions are done in the main thread. If
|
||||||
you want to help, you can volunteer to implement the necessary
|
you want to help, you can volunteer to implement the necessary
|
||||||
synchronization primitives in `gtest-port.h` for your platform.
|
synchronization primitives in `gtest-port.h` for your platform.
|
||||||
|
@ -123,7 +123,7 @@ c is 10<br>
|
|||||||
|
|
||||||
**Notes:**
|
**Notes:**
|
||||||
|
|
||||||
1. If you see a compiler error "no matching function to call" when using `ASSERT_PRED*` or `EXPECT_PRED*`, please see [this](http://code.google.com/p/googletest/wiki/V1_6_FAQ#The_compiler_complains_%22no_matching_function_to_call%22) for how to resolve it.
|
1. If you see a compiler error "no matching function to call" when using `ASSERT_PRED*` or `EXPECT_PRED*`, please see [this](v1_6_FAQ.md#ithe-compiler-complains-about-undefined-references-to-some-static-const-member-variables-but-i-did-define-them-in-the-class-body-whats-wrong) for how to resolve it.
|
||||||
1. Currently we only provide predicate assertions of arity <= 5. If you need a higher-arity assertion, let us know.
|
1. Currently we only provide predicate assertions of arity <= 5. If you need a higher-arity assertion, let us know.
|
||||||
|
|
||||||
_Availability_: Linux, Windows, Mac
|
_Availability_: Linux, Windows, Mac
|
||||||
@ -263,7 +263,7 @@ int SmallestPrimeCommonDivisor(int m, int n) { ... }
|
|||||||
int n) {
|
int n) {
|
||||||
if (MutuallyPrime(m, n))
|
if (MutuallyPrime(m, n))
|
||||||
return ::testing::AssertionSuccess();
|
return ::testing::AssertionSuccess();
|
||||||
|
|
||||||
return ::testing::AssertionFailure()
|
return ::testing::AssertionFailure()
|
||||||
<< m_expr << " and " << n_expr << " (" << m << " and " << n
|
<< m_expr << " and " << n_expr << " (" << m << " and " << n
|
||||||
<< ") are not mutually prime, " << "as they have a common divisor "
|
<< ") are not mutually prime, " << "as they have a common divisor "
|
||||||
@ -515,9 +515,9 @@ _death tests_. More generally, any test that checks that a program terminates
|
|||||||
Note that if a piece of code throws an exception, we don't consider it "death"
|
Note that if a piece of code throws an exception, we don't consider it "death"
|
||||||
for the purpose of death tests, as the caller of the code could catch the exception
|
for the purpose of death tests, as the caller of the code could catch the exception
|
||||||
and avoid the crash. If you want to verify exceptions thrown by your code,
|
and avoid the crash. If you want to verify exceptions thrown by your code,
|
||||||
see [Exception Assertions](#Exception_Assertions.md).
|
see [Exception Assertions](#exception-assertions).
|
||||||
|
|
||||||
If you want to test `EXPECT_*()/ASSERT_*()` failures in your test code, see [Catching Failures](#Catching_Failures.md).
|
If you want to test `EXPECT_*()/ASSERT_*()` failures in your test code, see [Catching Failures](#catching-failures).
|
||||||
|
|
||||||
## How to Write a Death Test ##
|
## How to Write a Death Test ##
|
||||||
|
|
||||||
@ -801,7 +801,7 @@ For example,
|
|||||||
11: EXPECT_EQ(1, Bar(n));
|
11: EXPECT_EQ(1, Bar(n));
|
||||||
12: EXPECT_EQ(2, Bar(n + 1));
|
12: EXPECT_EQ(2, Bar(n + 1));
|
||||||
13: }
|
13: }
|
||||||
14:
|
14:
|
||||||
15: TEST(FooTest, Bar) {
|
15: TEST(FooTest, Bar) {
|
||||||
16: {
|
16: {
|
||||||
17: SCOPED_TRACE("A"); // This trace point will be included in
|
17: SCOPED_TRACE("A"); // This trace point will be included in
|
||||||
@ -1196,9 +1196,9 @@ which are all in the `testing` namespace:
|
|||||||
| `Values(v1, v2, ..., vN)` | Yields values `{v1, v2, ..., vN}`. |
|
| `Values(v1, v2, ..., vN)` | Yields values `{v1, v2, ..., vN}`. |
|
||||||
| `ValuesIn(container)` and `ValuesIn(begin, end)` | Yields values from a C-style array, an STL-style container, or an iterator range `[begin, end)`. `container`, `begin`, and `end` can be expressions whose values are determined at run time. |
|
| `ValuesIn(container)` and `ValuesIn(begin, end)` | Yields values from a C-style array, an STL-style container, or an iterator range `[begin, end)`. `container`, `begin`, and `end` can be expressions whose values are determined at run time. |
|
||||||
| `Bool()` | Yields sequence `{false, true}`. |
|
| `Bool()` | Yields sequence `{false, true}`. |
|
||||||
| `Combine(g1, g2, ..., gN)` | Yields all combinations (the Cartesian product for the math savvy) of the values generated by the `N` generators. This is only available if your system provides the `<tr1/tuple>` header. If you are sure your system does, and Google Test disagrees, you can override it by defining `GTEST_HAS_TR1_TUPLE=1`. See comments in [include/gtest/internal/gtest-port.h](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/internal/gtest-port.h) for more information. |
|
| `Combine(g1, g2, ..., gN)` | Yields all combinations (the Cartesian product for the math savvy) of the values generated by the `N` generators. This is only available if your system provides the `<tr1/tuple>` header. If you are sure your system does, and Google Test disagrees, you can override it by defining `GTEST_HAS_TR1_TUPLE=1`. See comments in [include/gtest/internal/gtest-port.h](../include/gtest/internal/gtest-port.h) for more information. |
|
||||||
|
|
||||||
For more details, see the comments at the definitions of these functions in the [source code](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/gtest-param-test.h).
|
For more details, see the comments at the definitions of these functions in the [source code](../include/gtest/gtest-param-test.h).
|
||||||
|
|
||||||
The following statement will instantiate tests from the `FooTest` test case
|
The following statement will instantiate tests from the `FooTest` test case
|
||||||
each with parameter values `"meeny"`, `"miny"`, and `"moe"`.
|
each with parameter values `"meeny"`, `"miny"`, and `"moe"`.
|
||||||
@ -1223,7 +1223,7 @@ names:
|
|||||||
* `InstantiationName/FooTest.HasBlahBlah/1` for `"miny"`
|
* `InstantiationName/FooTest.HasBlahBlah/1` for `"miny"`
|
||||||
* `InstantiationName/FooTest.HasBlahBlah/2` for `"moe"`
|
* `InstantiationName/FooTest.HasBlahBlah/2` for `"moe"`
|
||||||
|
|
||||||
You can use these names in [--gtest\_filter](#Running_a_Subset_of_the_Tests.md).
|
You can use these names in [--gtest\-filter](#running-a-subset-of-the-tests).
|
||||||
|
|
||||||
This statement will instantiate all tests from `FooTest` again, each
|
This statement will instantiate all tests from `FooTest` again, each
|
||||||
with parameter values `"cat"` and `"dog"`:
|
with parameter values `"cat"` and `"dog"`:
|
||||||
@ -1246,8 +1246,8 @@ tests in the given test case, whether their definitions come before or
|
|||||||
_after_ the `INSTANTIATE_TEST_CASE_P` statement.
|
_after_ the `INSTANTIATE_TEST_CASE_P` statement.
|
||||||
|
|
||||||
You can see
|
You can see
|
||||||
[these](http://code.google.com/p/googletest/source/browse/trunk/samples/sample7_unittest.cc)
|
[these](../samples/sample7_unittest.cc)
|
||||||
[files](http://code.google.com/p/googletest/source/browse/trunk/samples/sample8_unittest.cc) for more examples.
|
[files](../samples/sample8_unittest.cc) for more examples.
|
||||||
|
|
||||||
_Availability_: Linux, Windows (requires MSVC 8.0 or above), Mac; since version 1.2.0.
|
_Availability_: Linux, Windows (requires MSVC 8.0 or above), Mac; since version 1.2.0.
|
||||||
|
|
||||||
@ -1643,8 +1643,8 @@ _Availability:_ Linux, Windows, Mac; since v1.4.0.
|
|||||||
## Defining Event Listeners ##
|
## Defining Event Listeners ##
|
||||||
|
|
||||||
To define a event listener, you subclass either
|
To define a event listener, you subclass either
|
||||||
[testing::TestEventListener](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/gtest.h#855)
|
[testing::TestEventListener](../include/gtest/gtest.h#L855)
|
||||||
or [testing::EmptyTestEventListener](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/gtest.h#905).
|
or [testing::EmptyTestEventListener](../include/gtest/gtest.h#L905).
|
||||||
The former is an (abstract) interface, where <i>each pure virtual method<br>
|
The former is an (abstract) interface, where <i>each pure virtual method<br>
|
||||||
can be overridden to handle a test event</i> (For example, when a test
|
can be overridden to handle a test event</i> (For example, when a test
|
||||||
starts, the `OnTestStart()` method will be called.). The latter provides
|
starts, the `OnTestStart()` method will be called.). The latter provides
|
||||||
@ -1653,10 +1653,10 @@ subclass only needs to override the methods it cares about.
|
|||||||
|
|
||||||
When an event is fired, its context is passed to the handler function
|
When an event is fired, its context is passed to the handler function
|
||||||
as an argument. The following argument types are used:
|
as an argument. The following argument types are used:
|
||||||
* [UnitTest](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/gtest.h#1007) reflects the state of the entire test program,
|
* [UnitTest](../include/gtest/gtest.h#L1007) reflects the state of the entire test program,
|
||||||
* [TestCase](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/gtest.h#689) has information about a test case, which can contain one or more tests,
|
* [TestCase](../include/gtest/gtest.h#L689) has information about a test case, which can contain one or more tests,
|
||||||
* [TestInfo](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/gtest.h#599) contains the state of a test, and
|
* [TestInfo](../include/gtest/gtest.h#L599) contains the state of a test, and
|
||||||
* [TestPartResult](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/gtest-test-part.h#42) represents the result of a test assertion.
|
* [TestPartResult](../include/gtest/gtest-test-part.h#L42) represents the result of a test assertion.
|
||||||
|
|
||||||
An event handler function can examine the argument it receives to find
|
An event handler function can examine the argument it receives to find
|
||||||
out interesting information about the event and the test program's
|
out interesting information about the event and the test program's
|
||||||
@ -1692,7 +1692,7 @@ state. Here's an example:
|
|||||||
|
|
||||||
To use the event listener you have defined, add an instance of it to
|
To use the event listener you have defined, add an instance of it to
|
||||||
the Google Test event listener list (represented by class
|
the Google Test event listener list (represented by class
|
||||||
[TestEventListeners](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/gtest.h#929)
|
[TestEventListeners](../include/gtest/gtest.h#L929)
|
||||||
- note the "s" at the end of the name) in your
|
- note the "s" at the end of the name) in your
|
||||||
`main()` function, before calling `RUN_ALL_TESTS()`:
|
`main()` function, before calling `RUN_ALL_TESTS()`:
|
||||||
```
|
```
|
||||||
@ -1720,7 +1720,7 @@ event listener list and delete it. You can do so by adding one line:
|
|||||||
|
|
||||||
Now, sit back and enjoy a completely different output from your
|
Now, sit back and enjoy a completely different output from your
|
||||||
tests. For more details, you can read this
|
tests. For more details, you can read this
|
||||||
[sample](http://code.google.com/p/googletest/source/browse/trunk/samples/sample9_unittest.cc).
|
[sample](../samples/sample9_unittest.cc).
|
||||||
|
|
||||||
You may append more than one listener to the list. When an `On*Start()`
|
You may append more than one listener to the list. When an `On*Start()`
|
||||||
or `OnTestPartResult()` event is fired, the listeners will receive it in
|
or `OnTestPartResult()` event is fired, the listeners will receive it in
|
||||||
@ -1745,7 +1745,7 @@ failures. This ensures that failures generated by the latter are
|
|||||||
attributed to the right test by the former.
|
attributed to the right test by the former.
|
||||||
|
|
||||||
We have a sample of failure-raising listener
|
We have a sample of failure-raising listener
|
||||||
[here](http://code.google.com/p/googletest/source/browse/trunk/samples/sample10_unittest.cc).
|
[here](../samples/sample10_unittest.cc).
|
||||||
|
|
||||||
# Running Test Programs: Advanced Options #
|
# Running Test Programs: Advanced Options #
|
||||||
|
|
||||||
@ -1865,12 +1865,12 @@ _Availability:_ Linux, Windows, Mac.
|
|||||||
|
|
||||||
### Temporarily Enabling Disabled Tests ###
|
### Temporarily Enabling Disabled Tests ###
|
||||||
|
|
||||||
To include [disabled tests](#Temporarily_Disabling_Tests.md) in test
|
To include [disabled tests](#temporarily-disabling-tests) in test
|
||||||
execution, just invoke the test program with the
|
execution, just invoke the test program with the
|
||||||
`--gtest_also_run_disabled_tests` flag or set the
|
`--gtest_also_run_disabled_tests` flag or set the
|
||||||
`GTEST_ALSO_RUN_DISABLED_TESTS` environment variable to a value other
|
`GTEST_ALSO_RUN_DISABLED_TESTS` environment variable to a value other
|
||||||
than `0`. You can combine this with the
|
than `0`. You can combine this with the
|
||||||
[--gtest\_filter](#Running_a_Subset_of_the_Tests.md) flag to further select
|
[--gtest\-filter](#running-a-subset-of-the_tests) flag to further select
|
||||||
which disabled tests to run.
|
which disabled tests to run.
|
||||||
|
|
||||||
_Availability:_ Linux, Windows, Mac; since version 1.3.0.
|
_Availability:_ Linux, Windows, Mac; since version 1.3.0.
|
||||||
@ -2168,11 +2168,11 @@ and you should see an `OUTPUT_DIR` directory being created with files
|
|||||||
`gtest/gtest.h` and `gtest/gtest-all.cc` in it. These files contain
|
`gtest/gtest.h` and `gtest/gtest-all.cc` in it. These files contain
|
||||||
everything you need to use Google Test. Just copy them to anywhere
|
everything you need to use Google Test. Just copy them to anywhere
|
||||||
you want and you are ready to write tests. You can use the
|
you want and you are ready to write tests. You can use the
|
||||||
[scripts/test/Makefile](http://code.google.com/p/googletest/source/browse/trunk/scripts/test/Makefile)
|
[scripts/test/Makefile](../scripts/test/Makefile)
|
||||||
file as an example on how to compile your tests against them.
|
file as an example on how to compile your tests against them.
|
||||||
|
|
||||||
# Where to Go from Here #
|
# Where to Go from Here #
|
||||||
|
|
||||||
Congratulations! You've now learned more advanced Google Test tools and are
|
Congratulations! You've now learned more advanced Google Test tools and are
|
||||||
ready to tackle more complex testing tasks. If you want to dive even deeper, you
|
ready to tackle more complex testing tasks. If you want to dive even deeper, you
|
||||||
can read the [Frequently-Asked Questions](V1_6_FAQ.md).
|
can read the [Frequently-Asked Questions](V1_6_FAQ.md).
|
||||||
|
@ -28,11 +28,11 @@ list can help you decide whether it is for you too.
|
|||||||
* `SCOPED_TRACE` helps you understand the context of an assertion failure when it comes from inside a sub-routine or loop.
|
* `SCOPED_TRACE` helps you understand the context of an assertion failure when it comes from inside a sub-routine or loop.
|
||||||
* You can decide which tests to run using name patterns. This saves time when you want to quickly reproduce a test failure.
|
* You can decide which tests to run using name patterns. This saves time when you want to quickly reproduce a test failure.
|
||||||
* Google Test can generate XML test result reports that can be parsed by popular continuous build system like Hudson.
|
* Google Test can generate XML test result reports that can be parsed by popular continuous build system like Hudson.
|
||||||
* Simple things are easy in Google Test, while hard things are possible: in addition to advanced features like [global test environments](http://code.google.com/p/googletest/wiki/V1_6_AdvancedGuide#Global_Set-Up_and_Tear-Down) and tests parameterized by [values](http://code.google.com/p/googletest/wiki/V1_6_AdvancedGuide#Value_Parameterized_Tests) or [types](http://code.google.com/p/googletest/wiki/V1_6_AdvancedGuide#Typed_Tests), Google Test supports various ways for the user to extend the framework -- if Google Test doesn't do something out of the box, chances are that a user can implement the feature using Google Test's public API, without changing Google Test itself. In particular, you can:
|
* Simple things are easy in Google Test, while hard things are possible: in addition to advanced features like [global test environments](V1_6_AdvancedGuide.md#Global_Set-Up_and_Tear-Down) and tests parameterized by [values](V1_6_AdvancedGuide.md#value-parameterized-tests) or [types](V1_6_AdvancedGuide.md#typed-tests), Google Test supports various ways for the user to extend the framework -- if Google Test doesn't do something out of the box, chances are that a user can implement the feature using Google Test's public API, without changing Google Test itself. In particular, you can:
|
||||||
* expand your testing vocabulary by defining [custom predicates](http://code.google.com/p/googletest/wiki/V1_6_AdvancedGuide#Predicate_Assertions_for_Better_Error_Messages),
|
* expand your testing vocabulary by defining [custom predicates](V1_6_AdvancedGuide.md#predicate-assertions-for-better-error-messages),
|
||||||
* teach Google Test how to [print your types](http://code.google.com/p/googletest/wiki/V1_6_AdvancedGuide#Teaching_Google_Test_How_to_Print_Your_Values),
|
* teach Google Test how to [print your types](V1_6_AdvancedGuide.md#teaching-google-test-how-to-print-your-values),
|
||||||
* define your own testing macros or utilities and verify them using Google Test's [Service Provider Interface](http://code.google.com/p/googletest/wiki/V1_6_AdvancedGuide#Catching_Failures), and
|
* define your own testing macros or utilities and verify them using Google Test's [Service Provider Interface](V1_6_AdvancedGuide.md#catching-failures), and
|
||||||
* reflect on the test cases or change the test output format by intercepting the [test events](http://code.google.com/p/googletest/wiki/V1_6_AdvancedGuide#Extending_Google_Test_by_Handling_Test_Events).
|
* reflect on the test cases or change the test output format by intercepting the [test events](V1_6_AdvancedGuide.md#extending-google-test-by-handling-test-events).
|
||||||
|
|
||||||
## I'm getting warnings when compiling Google Test. Would you fix them? ##
|
## I'm getting warnings when compiling Google Test. Would you fix them? ##
|
||||||
|
|
||||||
@ -201,7 +201,7 @@ we don't have a convention on the order of the two arguments for
|
|||||||
twice in the implementation, making it even harder to understand and
|
twice in the implementation, making it even harder to understand and
|
||||||
maintain. We believe the benefit doesn't justify the cost.
|
maintain. We believe the benefit doesn't justify the cost.
|
||||||
|
|
||||||
Finally, with the growth of Google Mock's [matcher](http://code.google.com/p/googlemock/wiki/CookBook#Using_Matchers_in_Google_Test_Assertions) library, we are
|
Finally, with the growth of Google Mock's [matcher](../../CookBook.md#using-matchers-in-google-test-assertions) library, we are
|
||||||
encouraging people to use the unified `EXPECT_THAT(value, matcher)`
|
encouraging people to use the unified `EXPECT_THAT(value, matcher)`
|
||||||
syntax more often in tests. One significant advantage of the matcher
|
syntax more often in tests. One significant advantage of the matcher
|
||||||
approach is that matchers can be easily combined to form new matchers,
|
approach is that matchers can be easily combined to form new matchers,
|
||||||
@ -409,7 +409,7 @@ If necessary, you can continue to derive test fixtures from a derived fixture.
|
|||||||
Google Test has no limit on how deep the hierarchy can be.
|
Google Test has no limit on how deep the hierarchy can be.
|
||||||
|
|
||||||
For a complete example using derived test fixtures, see
|
For a complete example using derived test fixtures, see
|
||||||
[sample5](http://code.google.com/p/googletest/source/browse/trunk/samples/sample5_unittest.cc).
|
[sample5](../samples/sample5_unittest.cc).
|
||||||
|
|
||||||
## My compiler complains "void value not ignored as it ought to be." What does this mean? ##
|
## My compiler complains "void value not ignored as it ought to be." What does this mean? ##
|
||||||
|
|
||||||
@ -748,7 +748,7 @@ EXPECT_TRUE(internal::Func(12345));
|
|||||||
|
|
||||||
## I would like to run a test several times with different parameters. Do I need to write several similar copies of it? ##
|
## I would like to run a test several times with different parameters. Do I need to write several similar copies of it? ##
|
||||||
|
|
||||||
No. You can use a feature called [value-parameterized tests](V1_6_AdvancedGuide#Value_Parameterized_Tests.md) which
|
No. You can use a feature called [value-parameterized tests](V1_6_AdvancedGuide.md#Value_Parameterized_Tests) which
|
||||||
lets you repeat your tests with different parameters, without defining it more than once.
|
lets you repeat your tests with different parameters, without defining it more than once.
|
||||||
|
|
||||||
## How do I test a file that defines main()? ##
|
## How do I test a file that defines main()? ##
|
||||||
@ -798,6 +798,7 @@ reference global and/or local variables, and can be:
|
|||||||
* a compound statement.
|
* a compound statement.
|
||||||
|
|
||||||
> Some examples are shown here:
|
> Some examples are shown here:
|
||||||
|
|
||||||
```
|
```
|
||||||
// A death test can be a simple function call.
|
// A death test can be a simple function call.
|
||||||
TEST(MyDeathTest, FunctionCall) {
|
TEST(MyDeathTest, FunctionCall) {
|
||||||
@ -842,7 +843,7 @@ expression syntax
|
|||||||
(http://en.wikipedia.org/wiki/Regular_expression#POSIX_Extended_Regular_Expressions).
|
(http://en.wikipedia.org/wiki/Regular_expression#POSIX_Extended_Regular_Expressions).
|
||||||
On Windows, it uses a limited variant of regular expression
|
On Windows, it uses a limited variant of regular expression
|
||||||
syntax. For more details, see the
|
syntax. For more details, see the
|
||||||
[regular expression syntax](V1_6_AdvancedGuide#Regular_Expression_Syntax.md).
|
[regular expression syntax](V1_6_AdvancedGuide.md#Regular_Expression_Syntax).
|
||||||
|
|
||||||
## I have a fixture class Foo, but TEST\_F(Foo, Bar) gives me error "no matching function for call to Foo::Foo()". Why? ##
|
## I have a fixture class Foo, but TEST\_F(Foo, Bar) gives me error "no matching function for call to Foo::Foo()". Why? ##
|
||||||
|
|
||||||
@ -949,7 +950,7 @@ using gtest-md.vcproj instead of gtest.vcproj.
|
|||||||
|
|
||||||
## I put my tests in a library and Google Test doesn't run them. What's happening? ##
|
## I put my tests in a library and Google Test doesn't run them. What's happening? ##
|
||||||
Have you read a
|
Have you read a
|
||||||
[warning](http://code.google.com/p/googletest/wiki/V1_6_Primer#Important_note_for_Visual_C++_users) on
|
[warning](V1_6_Primer.md#important-note-for-visual-c-users) on
|
||||||
the Google Test Primer page?
|
the Google Test Primer page?
|
||||||
|
|
||||||
## I want to use Google Test with Visual Studio but don't know where to start. ##
|
## I want to use Google Test with Visual Studio but don't know where to start. ##
|
||||||
@ -1034,4 +1035,4 @@ not enough information in your question):
|
|||||||
* the name and version of your compiler,
|
* the name and version of your compiler,
|
||||||
* the complete command line flags you give to your compiler,
|
* the complete command line flags you give to your compiler,
|
||||||
* the complete compiler error messages (if the question is about compilation),
|
* the complete compiler error messages (if the question is about compilation),
|
||||||
* the _actual_ code (ideally, a minimal but complete program) that has the problem you encounter.
|
* the _actual_ code (ideally, a minimal but complete program) that has the problem you encounter.
|
||||||
|
@ -146,7 +146,7 @@ but it's no longer necessary since v1.6.0 (if `<<` is supported, it
|
|||||||
will be called to print the arguments when the assertion fails;
|
will be called to print the arguments when the assertion fails;
|
||||||
otherwise Google Test will attempt to print them in the best way it
|
otherwise Google Test will attempt to print them in the best way it
|
||||||
can. For more details and how to customize the printing of the
|
can. For more details and how to customize the printing of the
|
||||||
arguments, see this Google Mock [recipe](http://code.google.com/p/googlemock/wiki/CookBook#Teaching_Google_Mock_How_to_Print_Your_Values).).
|
arguments, see this Google Mock [recipe](../../googlemock/docs/CookBook.md#teaching-google-mock-how-to-print-your-values).).
|
||||||
|
|
||||||
These assertions can work with a user-defined type, but only if you define the
|
These assertions can work with a user-defined type, but only if you define the
|
||||||
corresponding comparison operator (e.g. `==`, `<`, etc). If the corresponding
|
corresponding comparison operator (e.g. `==`, `<`, etc). If the corresponding
|
||||||
@ -255,7 +255,7 @@ To create a fixture, just:
|
|||||||
1. Derive a class from `::testing::Test` . Start its body with `protected:` or `public:` as we'll want to access fixture members from sub-classes.
|
1. Derive a class from `::testing::Test` . Start its body with `protected:` or `public:` as we'll want to access fixture members from sub-classes.
|
||||||
1. Inside the class, declare any objects you plan to use.
|
1. Inside the class, declare any objects you plan to use.
|
||||||
1. If necessary, write a default constructor or `SetUp()` function to prepare the objects for each test. A common mistake is to spell `SetUp()` as `Setup()` with a small `u` - don't let that happen to you.
|
1. If necessary, write a default constructor or `SetUp()` function to prepare the objects for each test. A common mistake is to spell `SetUp()` as `Setup()` with a small `u` - don't let that happen to you.
|
||||||
1. If necessary, write a destructor or `TearDown()` function to release any resources you allocated in `SetUp()` . To learn when you should use the constructor/destructor and when you should use `SetUp()/TearDown()`, read this [FAQ entry](http://code.google.com/p/googletest/wiki/V1_6_FAQ#Should_I_use_the_constructor/destructor_of_the_test_fixture_or_t).
|
1. If necessary, write a destructor or `TearDown()` function to release any resources you allocated in `SetUp()` . To learn when you should use the constructor/destructor and when you should use `SetUp()/TearDown()`, read this [FAQ entry](V1_6_FAQ.md#should-i-use-the-constructordestructor-of-the-test-fixture-or-the-set-uptear-down-function).
|
||||||
1. If needed, define subroutines for your tests to share.
|
1. If needed, define subroutines for your tests to share.
|
||||||
|
|
||||||
When using a fixture, use `TEST_F()` instead of `TEST()` as it allows you to
|
When using a fixture, use `TEST_F()` instead of `TEST()` as it allows you to
|
||||||
@ -498,4 +498,4 @@ is currently _unsafe_ to use Google Test assertions from two threads
|
|||||||
concurrently on other systems (e.g. Windows). In most tests this is
|
concurrently on other systems (e.g. Windows). In most tests this is
|
||||||
not an issue as usually the assertions are done in the main thread. If
|
not an issue as usually the assertions are done in the main thread. If
|
||||||
you want to help, you can volunteer to implement the necessary
|
you want to help, you can volunteer to implement the necessary
|
||||||
synchronization primitives in `gtest-port.h` for your platform.
|
synchronization primitives in `gtest-port.h` for your platform.
|
||||||
|
@ -161,7 +161,7 @@ exp ::= simple_expression_in_Python_syntax
|
|||||||
|
|
||||||
## Code ##
|
## Code ##
|
||||||
|
|
||||||
You can find the source code of Pump in [scripts/pump.py](http://code.google.com/p/googletest/source/browse/trunk/scripts/pump.py). It is still
|
You can find the source code of Pump in [scripts/pump.py](../scripts/pump.py). It is still
|
||||||
very unpolished and lacks automated tests, although it has been
|
very unpolished and lacks automated tests, although it has been
|
||||||
successfully used many times. If you find a chance to use it in your
|
successfully used many times. If you find a chance to use it in your
|
||||||
project, please let us know what you think! We also welcome help on
|
project, please let us know what you think! We also welcome help on
|
||||||
@ -174,4 +174,4 @@ You can find real-world applications of Pump in [Google Test](http://www.google.
|
|||||||
## Tips ##
|
## Tips ##
|
||||||
|
|
||||||
* If a meta variable is followed by a letter or digit, you can separate them using `[[]]`, which inserts an empty string. For example `Foo$j[[]]Helper` generate `Foo1Helper` when `j` is 1.
|
* If a meta variable is followed by a letter or digit, you can separate them using `[[]]`, which inserts an empty string. For example `Foo$j[[]]Helper` generate `Foo1Helper` when `j` is 1.
|
||||||
* To avoid extra-long Pump source lines, you can break a line anywhere you want by inserting `[[]]` followed by a new line. Since any new-line character next to `[[` or `]]` is ignored, the generated code won't contain this new line.
|
* To avoid extra-long Pump source lines, you can break a line anywhere you want by inserting `[[]]` followed by a new line. Since any new-line character next to `[[` or `]]` is ignored, the generated code won't contain this new line.
|
||||||
|
@ -1,14 +1,14 @@
|
|||||||
If you're like us, you'd like to look at some Google Test sample code. The
|
If you're like us, you'd like to look at some Google Test sample code. The
|
||||||
[samples folder](http://code.google.com/p/googletest/source/browse/#svn/trunk/samples) has a number of well-commented samples showing how to use a
|
[samples folder](../samples) has a number of well-commented samples showing how to use a
|
||||||
variety of Google Test features.
|
variety of Google Test features.
|
||||||
|
|
||||||
* [Sample #1](http://code.google.com/p/googletest/source/browse/trunk/samples/sample1_unittest.cc) shows the basic steps of using Google Test to test C++ functions.
|
* [Sample #1](../samples/sample1_unittest.cc) shows the basic steps of using Google Test to test C++ functions.
|
||||||
* [Sample #2](http://code.google.com/p/googletest/source/browse/trunk/samples/sample2_unittest.cc) shows a more complex unit test for a class with multiple member functions.
|
* [Sample #2](../samples/sample2_unittest.cc) shows a more complex unit test for a class with multiple member functions.
|
||||||
* [Sample #3](http://code.google.com/p/googletest/source/browse/trunk/samples/sample3_unittest.cc) uses a test fixture.
|
* [Sample #3](../samples/sample3_unittest.cc) uses a test fixture.
|
||||||
* [Sample #4](http://code.google.com/p/googletest/source/browse/trunk/samples/sample4_unittest.cc) is another basic example of using Google Test.
|
* [Sample #4](../samples/sample4_unittest.cc) is another basic example of using Google Test.
|
||||||
* [Sample #5](http://code.google.com/p/googletest/source/browse/trunk/samples/sample5_unittest.cc) teaches how to reuse a test fixture in multiple test cases by deriving sub-fixtures from it.
|
* [Sample #5](../samples/sample5_unittest.cc) teaches how to reuse a test fixture in multiple test cases by deriving sub-fixtures from it.
|
||||||
* [Sample #6](http://code.google.com/p/googletest/source/browse/trunk/samples/sample6_unittest.cc) demonstrates type-parameterized tests.
|
* [Sample #6](../samples/sample6_unittest.cc) demonstrates type-parameterized tests.
|
||||||
* [Sample #7](http://code.google.com/p/googletest/source/browse/trunk/samples/sample7_unittest.cc) teaches the basics of value-parameterized tests.
|
* [Sample #7](../samples/sample7_unittest.cc) teaches the basics of value-parameterized tests.
|
||||||
* [Sample #8](http://code.google.com/p/googletest/source/browse/trunk/samples/sample8_unittest.cc) shows using `Combine()` in value-parameterized tests.
|
* [Sample #8](../samples/sample8_unittest.cc) shows using `Combine()` in value-parameterized tests.
|
||||||
* [Sample #9](http://code.google.com/p/googletest/source/browse/trunk/samples/sample9_unittest.cc) shows use of the listener API to modify Google Test's console output and the use of its reflection API to inspect test results.
|
* [Sample #9](../samples/sample9_unittest.cc) shows use of the listener API to modify Google Test's console output and the use of its reflection API to inspect test results.
|
||||||
* [Sample #10](http://code.google.com/p/googletest/source/browse/trunk/samples/sample10_unittest.cc) shows use of the listener API to implement a primitive memory leak checker.
|
* [Sample #10](../samples/sample10_unittest.cc) shows use of the listener API to implement a primitive memory leak checker.
|
||||||
|
@ -123,7 +123,7 @@ c is 10<br>
|
|||||||
|
|
||||||
**Notes:**
|
**Notes:**
|
||||||
|
|
||||||
1. If you see a compiler error "no matching function to call" when using `ASSERT_PRED*` or `EXPECT_PRED*`, please see [this](http://code.google.com/p/googletest/wiki/V1_7_FAQ#The_compiler_complains_%22no_matching_function_to_call%22) for how to resolve it.
|
1. If you see a compiler error "no matching function to call" when using `ASSERT_PRED*` or `EXPECT_PRED*`, please see [this](V1_7_FAQ.md#the-compiler-complains-about-undefined-references-to-some-static-const-member-variables-but-i-did-define-them-in-the-class-body-whats-wrong) for how to resolve it.
|
||||||
1. Currently we only provide predicate assertions of arity <= 5. If you need a higher-arity assertion, let us know.
|
1. Currently we only provide predicate assertions of arity <= 5. If you need a higher-arity assertion, let us know.
|
||||||
|
|
||||||
_Availability_: Linux, Windows, Mac
|
_Availability_: Linux, Windows, Mac
|
||||||
@ -263,7 +263,7 @@ int SmallestPrimeCommonDivisor(int m, int n) { ... }
|
|||||||
int n) {
|
int n) {
|
||||||
if (MutuallyPrime(m, n))
|
if (MutuallyPrime(m, n))
|
||||||
return ::testing::AssertionSuccess();
|
return ::testing::AssertionSuccess();
|
||||||
|
|
||||||
return ::testing::AssertionFailure()
|
return ::testing::AssertionFailure()
|
||||||
<< m_expr << " and " << n_expr << " (" << m << " and " << n
|
<< m_expr << " and " << n_expr << " (" << m << " and " << n
|
||||||
<< ") are not mutually prime, " << "as they have a common divisor "
|
<< ") are not mutually prime, " << "as they have a common divisor "
|
||||||
@ -515,9 +515,9 @@ _death tests_. More generally, any test that checks that a program terminates
|
|||||||
Note that if a piece of code throws an exception, we don't consider it "death"
|
Note that if a piece of code throws an exception, we don't consider it "death"
|
||||||
for the purpose of death tests, as the caller of the code could catch the exception
|
for the purpose of death tests, as the caller of the code could catch the exception
|
||||||
and avoid the crash. If you want to verify exceptions thrown by your code,
|
and avoid the crash. If you want to verify exceptions thrown by your code,
|
||||||
see [Exception Assertions](#Exception_Assertions.md).
|
see [Exception Assertions](#exception-assertions).
|
||||||
|
|
||||||
If you want to test `EXPECT_*()/ASSERT_*()` failures in your test code, see [Catching Failures](#Catching_Failures.md).
|
If you want to test `EXPECT_*()/ASSERT_*()` failures in your test code, see [Catching Failures](#catching-failures).
|
||||||
|
|
||||||
## How to Write a Death Test ##
|
## How to Write a Death Test ##
|
||||||
|
|
||||||
@ -802,7 +802,7 @@ For example,
|
|||||||
11: EXPECT_EQ(1, Bar(n));
|
11: EXPECT_EQ(1, Bar(n));
|
||||||
12: EXPECT_EQ(2, Bar(n + 1));
|
12: EXPECT_EQ(2, Bar(n + 1));
|
||||||
13: }
|
13: }
|
||||||
14:
|
14:
|
||||||
15: TEST(FooTest, Bar) {
|
15: TEST(FooTest, Bar) {
|
||||||
16: {
|
16: {
|
||||||
17: SCOPED_TRACE("A"); // This trace point will be included in
|
17: SCOPED_TRACE("A"); // This trace point will be included in
|
||||||
@ -1197,9 +1197,9 @@ which are all in the `testing` namespace:
|
|||||||
| `Values(v1, v2, ..., vN)` | Yields values `{v1, v2, ..., vN}`. |
|
| `Values(v1, v2, ..., vN)` | Yields values `{v1, v2, ..., vN}`. |
|
||||||
| `ValuesIn(container)` and `ValuesIn(begin, end)` | Yields values from a C-style array, an STL-style container, or an iterator range `[begin, end)`. `container`, `begin`, and `end` can be expressions whose values are determined at run time. |
|
| `ValuesIn(container)` and `ValuesIn(begin, end)` | Yields values from a C-style array, an STL-style container, or an iterator range `[begin, end)`. `container`, `begin`, and `end` can be expressions whose values are determined at run time. |
|
||||||
| `Bool()` | Yields sequence `{false, true}`. |
|
| `Bool()` | Yields sequence `{false, true}`. |
|
||||||
| `Combine(g1, g2, ..., gN)` | Yields all combinations (the Cartesian product for the math savvy) of the values generated by the `N` generators. This is only available if your system provides the `<tr1/tuple>` header. If you are sure your system does, and Google Test disagrees, you can override it by defining `GTEST_HAS_TR1_TUPLE=1`. See comments in [include/gtest/internal/gtest-port.h](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/internal/gtest-port.h) for more information. |
|
| `Combine(g1, g2, ..., gN)` | Yields all combinations (the Cartesian product for the math savvy) of the values generated by the `N` generators. This is only available if your system provides the `<tr1/tuple>` header. If you are sure your system does, and Google Test disagrees, you can override it by defining `GTEST_HAS_TR1_TUPLE=1`. See comments in [include/gtest/internal/gtest-port.h](../include/gtest/internal/gtest-port.h) for more information. |
|
||||||
|
|
||||||
For more details, see the comments at the definitions of these functions in the [source code](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/gtest-param-test.h).
|
For more details, see the comments at the definitions of these functions in the [source code](../include/gtest/gtest-param-test.h).
|
||||||
|
|
||||||
The following statement will instantiate tests from the `FooTest` test case
|
The following statement will instantiate tests from the `FooTest` test case
|
||||||
each with parameter values `"meeny"`, `"miny"`, and `"moe"`.
|
each with parameter values `"meeny"`, `"miny"`, and `"moe"`.
|
||||||
@ -1224,7 +1224,7 @@ names:
|
|||||||
* `InstantiationName/FooTest.HasBlahBlah/1` for `"miny"`
|
* `InstantiationName/FooTest.HasBlahBlah/1` for `"miny"`
|
||||||
* `InstantiationName/FooTest.HasBlahBlah/2` for `"moe"`
|
* `InstantiationName/FooTest.HasBlahBlah/2` for `"moe"`
|
||||||
|
|
||||||
You can use these names in [--gtest\_filter](#Running_a_Subset_of_the_Tests.md).
|
You can use these names in [--gtest\_filter](#running-a-subset-of-the-tests).
|
||||||
|
|
||||||
This statement will instantiate all tests from `FooTest` again, each
|
This statement will instantiate all tests from `FooTest` again, each
|
||||||
with parameter values `"cat"` and `"dog"`:
|
with parameter values `"cat"` and `"dog"`:
|
||||||
@ -1247,8 +1247,8 @@ tests in the given test case, whether their definitions come before or
|
|||||||
_after_ the `INSTANTIATE_TEST_CASE_P` statement.
|
_after_ the `INSTANTIATE_TEST_CASE_P` statement.
|
||||||
|
|
||||||
You can see
|
You can see
|
||||||
[these](http://code.google.com/p/googletest/source/browse/trunk/samples/sample7_unittest.cc)
|
[these](../samples/sample7_unittest.cc)
|
||||||
[files](http://code.google.com/p/googletest/source/browse/trunk/samples/sample8_unittest.cc) for more examples.
|
[files](../samples/sample8_unittest.cc) for more examples.
|
||||||
|
|
||||||
_Availability_: Linux, Windows (requires MSVC 8.0 or above), Mac; since version 1.2.0.
|
_Availability_: Linux, Windows (requires MSVC 8.0 or above), Mac; since version 1.2.0.
|
||||||
|
|
||||||
@ -1644,8 +1644,8 @@ _Availability:_ Linux, Windows, Mac; since v1.4.0.
|
|||||||
## Defining Event Listeners ##
|
## Defining Event Listeners ##
|
||||||
|
|
||||||
To define a event listener, you subclass either
|
To define a event listener, you subclass either
|
||||||
[testing::TestEventListener](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/gtest.h#855)
|
[testing::TestEventListener](../include/gtest/gtest.h#L855)
|
||||||
or [testing::EmptyTestEventListener](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/gtest.h#905).
|
or [testing::EmptyTestEventListener](../include/gtest/gtest.h#L905).
|
||||||
The former is an (abstract) interface, where <i>each pure virtual method<br>
|
The former is an (abstract) interface, where <i>each pure virtual method<br>
|
||||||
can be overridden to handle a test event</i> (For example, when a test
|
can be overridden to handle a test event</i> (For example, when a test
|
||||||
starts, the `OnTestStart()` method will be called.). The latter provides
|
starts, the `OnTestStart()` method will be called.). The latter provides
|
||||||
@ -1654,10 +1654,10 @@ subclass only needs to override the methods it cares about.
|
|||||||
|
|
||||||
When an event is fired, its context is passed to the handler function
|
When an event is fired, its context is passed to the handler function
|
||||||
as an argument. The following argument types are used:
|
as an argument. The following argument types are used:
|
||||||
* [UnitTest](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/gtest.h#1007) reflects the state of the entire test program,
|
* [UnitTest](../include/gtest/gtest.h#L1007) reflects the state of the entire test program,
|
||||||
* [TestCase](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/gtest.h#689) has information about a test case, which can contain one or more tests,
|
* [TestCase](../include/gtest/gtest.h#L689) has information about a test case, which can contain one or more tests,
|
||||||
* [TestInfo](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/gtest.h#599) contains the state of a test, and
|
* [TestInfo](../include/gtest/gtest.h#L599) contains the state of a test, and
|
||||||
* [TestPartResult](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/gtest-test-part.h#42) represents the result of a test assertion.
|
* [TestPartResult](../include/gtest/gtest-test-part.h#L42) represents the result of a test assertion.
|
||||||
|
|
||||||
An event handler function can examine the argument it receives to find
|
An event handler function can examine the argument it receives to find
|
||||||
out interesting information about the event and the test program's
|
out interesting information about the event and the test program's
|
||||||
@ -1693,7 +1693,7 @@ state. Here's an example:
|
|||||||
|
|
||||||
To use the event listener you have defined, add an instance of it to
|
To use the event listener you have defined, add an instance of it to
|
||||||
the Google Test event listener list (represented by class
|
the Google Test event listener list (represented by class
|
||||||
[TestEventListeners](http://code.google.com/p/googletest/source/browse/trunk/include/gtest/gtest.h#929)
|
[TestEventListeners](../include/gtest/gtest.h#L929)
|
||||||
- note the "s" at the end of the name) in your
|
- note the "s" at the end of the name) in your
|
||||||
`main()` function, before calling `RUN_ALL_TESTS()`:
|
`main()` function, before calling `RUN_ALL_TESTS()`:
|
||||||
```
|
```
|
||||||
@ -1721,7 +1721,7 @@ event listener list and delete it. You can do so by adding one line:
|
|||||||
|
|
||||||
Now, sit back and enjoy a completely different output from your
|
Now, sit back and enjoy a completely different output from your
|
||||||
tests. For more details, you can read this
|
tests. For more details, you can read this
|
||||||
[sample](http://code.google.com/p/googletest/source/browse/trunk/samples/sample9_unittest.cc).
|
[sample](../samples/sample9_unittest.cc).
|
||||||
|
|
||||||
You may append more than one listener to the list. When an `On*Start()`
|
You may append more than one listener to the list. When an `On*Start()`
|
||||||
or `OnTestPartResult()` event is fired, the listeners will receive it in
|
or `OnTestPartResult()` event is fired, the listeners will receive it in
|
||||||
@ -1746,7 +1746,7 @@ failures. This ensures that failures generated by the latter are
|
|||||||
attributed to the right test by the former.
|
attributed to the right test by the former.
|
||||||
|
|
||||||
We have a sample of failure-raising listener
|
We have a sample of failure-raising listener
|
||||||
[here](http://code.google.com/p/googletest/source/browse/trunk/samples/sample10_unittest.cc).
|
[here](../samples/sample10_unittest.cc).
|
||||||
|
|
||||||
# Running Test Programs: Advanced Options #
|
# Running Test Programs: Advanced Options #
|
||||||
|
|
||||||
@ -1866,12 +1866,12 @@ _Availability:_ Linux, Windows, Mac.
|
|||||||
|
|
||||||
### Temporarily Enabling Disabled Tests ###
|
### Temporarily Enabling Disabled Tests ###
|
||||||
|
|
||||||
To include [disabled tests](#Temporarily_Disabling_Tests.md) in test
|
To include [disabled tests](#temporarily-disabling-tests) in test
|
||||||
execution, just invoke the test program with the
|
execution, just invoke the test program with the
|
||||||
`--gtest_also_run_disabled_tests` flag or set the
|
`--gtest_also_run_disabled_tests` flag or set the
|
||||||
`GTEST_ALSO_RUN_DISABLED_TESTS` environment variable to a value other
|
`GTEST_ALSO_RUN_DISABLED_TESTS` environment variable to a value other
|
||||||
than `0`. You can combine this with the
|
than `0`. You can combine this with the
|
||||||
[--gtest\_filter](#Running_a_Subset_of_the_Tests.md) flag to further select
|
[--gtest\_filter](#running-a-subset-of-the-tests) flag to further select
|
||||||
which disabled tests to run.
|
which disabled tests to run.
|
||||||
|
|
||||||
_Availability:_ Linux, Windows, Mac; since version 1.3.0.
|
_Availability:_ Linux, Windows, Mac; since version 1.3.0.
|
||||||
@ -2171,11 +2171,11 @@ and you should see an `OUTPUT_DIR` directory being created with files
|
|||||||
`gtest/gtest.h` and `gtest/gtest-all.cc` in it. These files contain
|
`gtest/gtest.h` and `gtest/gtest-all.cc` in it. These files contain
|
||||||
everything you need to use Google Test. Just copy them to anywhere
|
everything you need to use Google Test. Just copy them to anywhere
|
||||||
you want and you are ready to write tests. You can use the
|
you want and you are ready to write tests. You can use the
|
||||||
[scripts/test/Makefile](http://code.google.com/p/googletest/source/browse/trunk/scripts/test/Makefile)
|
[scripts/test/Makefile](../scripts/test/Makefile)
|
||||||
file as an example on how to compile your tests against them.
|
file as an example on how to compile your tests against them.
|
||||||
|
|
||||||
# Where to Go from Here #
|
# Where to Go from Here #
|
||||||
|
|
||||||
Congratulations! You've now learned more advanced Google Test tools and are
|
Congratulations! You've now learned more advanced Google Test tools and are
|
||||||
ready to tackle more complex testing tasks. If you want to dive even deeper, you
|
ready to tackle more complex testing tasks. If you want to dive even deeper, you
|
||||||
can read the [Frequently-Asked Questions](V1_7_FAQ.md).
|
can read the [Frequently-Asked Questions](V1_7_FAQ.md).
|
||||||
|
@ -28,11 +28,11 @@ list can help you decide whether it is for you too.
|
|||||||
* `SCOPED_TRACE` helps you understand the context of an assertion failure when it comes from inside a sub-routine or loop.
|
* `SCOPED_TRACE` helps you understand the context of an assertion failure when it comes from inside a sub-routine or loop.
|
||||||
* You can decide which tests to run using name patterns. This saves time when you want to quickly reproduce a test failure.
|
* You can decide which tests to run using name patterns. This saves time when you want to quickly reproduce a test failure.
|
||||||
* Google Test can generate XML test result reports that can be parsed by popular continuous build system like Hudson.
|
* Google Test can generate XML test result reports that can be parsed by popular continuous build system like Hudson.
|
||||||
* Simple things are easy in Google Test, while hard things are possible: in addition to advanced features like [global test environments](http://code.google.com/p/googletest/wiki/V1_7_AdvancedGuide#Global_Set-Up_and_Tear-Down) and tests parameterized by [values](http://code.google.com/p/googletest/wiki/V1_7_AdvancedGuide#Value_Parameterized_Tests) or [types](http://code.google.com/p/googletest/wiki/V1_7_AdvancedGuide#Typed_Tests), Google Test supports various ways for the user to extend the framework -- if Google Test doesn't do something out of the box, chances are that a user can implement the feature using Google Test's public API, without changing Google Test itself. In particular, you can:
|
* Simple things are easy in Google Test, while hard things are possible: in addition to advanced features like [global test environments](V1_7_AdvancedGuide.md#global-set-up-and-tear-down) and tests parameterized by [values](V1_7_AdvancedGuide.md#value-parameterized-tests) or [types](V1_7_AdvancedGuide.md#typed-tests), Google Test supports various ways for the user to extend the framework -- if Google Test doesn't do something out of the box, chances are that a user can implement the feature using Google Test's public API, without changing Google Test itself. In particular, you can:
|
||||||
* expand your testing vocabulary by defining [custom predicates](http://code.google.com/p/googletest/wiki/V1_7_AdvancedGuide#Predicate_Assertions_for_Better_Error_Messages),
|
* expand your testing vocabulary by defining [custom predicates](V1_7_AdvancedGuide.md#predicate-assertions-for-better-error-messages),
|
||||||
* teach Google Test how to [print your types](http://code.google.com/p/googletest/wiki/V1_7_AdvancedGuide#Teaching_Google_Test_How_to_Print_Your_Values),
|
* teach Google Test how to [print your types](V1_7_AdvancedGuide.md#teaching-google-test-how-to-print-your-values),
|
||||||
* define your own testing macros or utilities and verify them using Google Test's [Service Provider Interface](http://code.google.com/p/googletest/wiki/V1_7_AdvancedGuide#Catching_Failures), and
|
* define your own testing macros or utilities and verify them using Google Test's [Service Provider Interface](V1_7_AdvancedGuide.md#catching-failures), and
|
||||||
* reflect on the test cases or change the test output format by intercepting the [test events](http://code.google.com/p/googletest/wiki/V1_7_AdvancedGuide#Extending_Google_Test_by_Handling_Test_Events).
|
* reflect on the test cases or change the test output format by intercepting the [test events](V1_7_AdvancedGuide.md#extending-google-test-by-handling-test-events).
|
||||||
|
|
||||||
## I'm getting warnings when compiling Google Test. Would you fix them? ##
|
## I'm getting warnings when compiling Google Test. Would you fix them? ##
|
||||||
|
|
||||||
@ -201,7 +201,7 @@ we don't have a convention on the order of the two arguments for
|
|||||||
twice in the implementation, making it even harder to understand and
|
twice in the implementation, making it even harder to understand and
|
||||||
maintain. We believe the benefit doesn't justify the cost.
|
maintain. We believe the benefit doesn't justify the cost.
|
||||||
|
|
||||||
Finally, with the growth of Google Mock's [matcher](http://code.google.com/p/googlemock/wiki/CookBook#Using_Matchers_in_Google_Test_Assertions) library, we are
|
Finally, with the growth of Google Mock's [matcher](../../CookBook.md#using-matchers-in-google-test-assertions) library, we are
|
||||||
encouraging people to use the unified `EXPECT_THAT(value, matcher)`
|
encouraging people to use the unified `EXPECT_THAT(value, matcher)`
|
||||||
syntax more often in tests. One significant advantage of the matcher
|
syntax more often in tests. One significant advantage of the matcher
|
||||||
approach is that matchers can be easily combined to form new matchers,
|
approach is that matchers can be easily combined to form new matchers,
|
||||||
@ -409,7 +409,7 @@ If necessary, you can continue to derive test fixtures from a derived fixture.
|
|||||||
Google Test has no limit on how deep the hierarchy can be.
|
Google Test has no limit on how deep the hierarchy can be.
|
||||||
|
|
||||||
For a complete example using derived test fixtures, see
|
For a complete example using derived test fixtures, see
|
||||||
[sample5](http://code.google.com/p/googletest/source/browse/trunk/samples/sample5_unittest.cc).
|
[sample5](../samples/sample5_unittest.cc).
|
||||||
|
|
||||||
## My compiler complains "void value not ignored as it ought to be." What does this mean? ##
|
## My compiler complains "void value not ignored as it ought to be." What does this mean? ##
|
||||||
|
|
||||||
@ -748,7 +748,7 @@ EXPECT_TRUE(internal::Func(12345));
|
|||||||
|
|
||||||
## I would like to run a test several times with different parameters. Do I need to write several similar copies of it? ##
|
## I would like to run a test several times with different parameters. Do I need to write several similar copies of it? ##
|
||||||
|
|
||||||
No. You can use a feature called [value-parameterized tests](V1_7_AdvancedGuide#Value_Parameterized_Tests.md) which
|
No. You can use a feature called [value-parameterized tests](V1_7_AdvancedGuide.md#Value_Parameterized_Tests) which
|
||||||
lets you repeat your tests with different parameters, without defining it more than once.
|
lets you repeat your tests with different parameters, without defining it more than once.
|
||||||
|
|
||||||
## How do I test a file that defines main()? ##
|
## How do I test a file that defines main()? ##
|
||||||
@ -798,6 +798,7 @@ reference global and/or local variables, and can be:
|
|||||||
* a compound statement.
|
* a compound statement.
|
||||||
|
|
||||||
> Some examples are shown here:
|
> Some examples are shown here:
|
||||||
|
|
||||||
```
|
```
|
||||||
// A death test can be a simple function call.
|
// A death test can be a simple function call.
|
||||||
TEST(MyDeathTest, FunctionCall) {
|
TEST(MyDeathTest, FunctionCall) {
|
||||||
@ -842,7 +843,7 @@ expression syntax
|
|||||||
(http://en.wikipedia.org/wiki/Regular_expression#POSIX_Extended_Regular_Expressions).
|
(http://en.wikipedia.org/wiki/Regular_expression#POSIX_Extended_Regular_Expressions).
|
||||||
On Windows, it uses a limited variant of regular expression
|
On Windows, it uses a limited variant of regular expression
|
||||||
syntax. For more details, see the
|
syntax. For more details, see the
|
||||||
[regular expression syntax](V1_7_AdvancedGuide#Regular_Expression_Syntax.md).
|
[regular expression syntax](V1_7_AdvancedGuide.md#Regular_Expression_Syntax).
|
||||||
|
|
||||||
## I have a fixture class Foo, but TEST\_F(Foo, Bar) gives me error "no matching function for call to Foo::Foo()". Why? ##
|
## I have a fixture class Foo, but TEST\_F(Foo, Bar) gives me error "no matching function for call to Foo::Foo()". Why? ##
|
||||||
|
|
||||||
@ -949,7 +950,7 @@ using gtest-md.vcproj instead of gtest.vcproj.
|
|||||||
|
|
||||||
## I put my tests in a library and Google Test doesn't run them. What's happening? ##
|
## I put my tests in a library and Google Test doesn't run them. What's happening? ##
|
||||||
Have you read a
|
Have you read a
|
||||||
[warning](http://code.google.com/p/googletest/wiki/V1_7_Primer#Important_note_for_Visual_C++_users) on
|
[warning](V1_7_Primer.md#important-note-for-visual-c-users) on
|
||||||
the Google Test Primer page?
|
the Google Test Primer page?
|
||||||
|
|
||||||
## I want to use Google Test with Visual Studio but don't know where to start. ##
|
## I want to use Google Test with Visual Studio but don't know where to start. ##
|
||||||
@ -1053,7 +1054,7 @@ TEST_F(CoolTest, DoSomething) {
|
|||||||
## How do I build Google Testing Framework with Xcode 4? ##
|
## How do I build Google Testing Framework with Xcode 4? ##
|
||||||
|
|
||||||
If you try to build Google Test's Xcode project with Xcode 4.0 or later, you may encounter an error message that looks like
|
If you try to build Google Test's Xcode project with Xcode 4.0 or later, you may encounter an error message that looks like
|
||||||
"Missing SDK in target gtest\_framework: /Developer/SDKs/MacOSX10.4u.sdk". That means that Xcode does not support the SDK the project is targeting. See the Xcode section in the [README](http://code.google.com/p/googletest/source/browse/trunk/README) file on how to resolve this.
|
"Missing SDK in target gtest\_framework: /Developer/SDKs/MacOSX10.4u.sdk". That means that Xcode does not support the SDK the project is targeting. See the Xcode section in the [README](../../README.MD) file on how to resolve this.
|
||||||
|
|
||||||
## My question is not covered in your FAQ! ##
|
## My question is not covered in your FAQ! ##
|
||||||
|
|
||||||
@ -1078,4 +1079,4 @@ not enough information in your question):
|
|||||||
* the name and version of your compiler,
|
* the name and version of your compiler,
|
||||||
* the complete command line flags you give to your compiler,
|
* the complete command line flags you give to your compiler,
|
||||||
* the complete compiler error messages (if the question is about compilation),
|
* the complete compiler error messages (if the question is about compilation),
|
||||||
* the _actual_ code (ideally, a minimal but complete program) that has the problem you encounter.
|
* the _actual_ code (ideally, a minimal but complete program) that has the problem you encounter.
|
||||||
|
@ -146,7 +146,7 @@ but it's no longer necessary since v1.6.0 (if `<<` is supported, it
|
|||||||
will be called to print the arguments when the assertion fails;
|
will be called to print the arguments when the assertion fails;
|
||||||
otherwise Google Test will attempt to print them in the best way it
|
otherwise Google Test will attempt to print them in the best way it
|
||||||
can. For more details and how to customize the printing of the
|
can. For more details and how to customize the printing of the
|
||||||
arguments, see this Google Mock [recipe](http://code.google.com/p/googlemock/wiki/CookBook#Teaching_Google_Mock_How_to_Print_Your_Values).).
|
arguments, see this Google Mock [recipe](../../googlemock/docs/CookBook.md#teaching-google-mock-how-to-print-your-values).).
|
||||||
|
|
||||||
These assertions can work with a user-defined type, but only if you define the
|
These assertions can work with a user-defined type, but only if you define the
|
||||||
corresponding comparison operator (e.g. `==`, `<`, etc). If the corresponding
|
corresponding comparison operator (e.g. `==`, `<`, etc). If the corresponding
|
||||||
@ -255,7 +255,7 @@ To create a fixture, just:
|
|||||||
1. Derive a class from `::testing::Test` . Start its body with `protected:` or `public:` as we'll want to access fixture members from sub-classes.
|
1. Derive a class from `::testing::Test` . Start its body with `protected:` or `public:` as we'll want to access fixture members from sub-classes.
|
||||||
1. Inside the class, declare any objects you plan to use.
|
1. Inside the class, declare any objects you plan to use.
|
||||||
1. If necessary, write a default constructor or `SetUp()` function to prepare the objects for each test. A common mistake is to spell `SetUp()` as `Setup()` with a small `u` - don't let that happen to you.
|
1. If necessary, write a default constructor or `SetUp()` function to prepare the objects for each test. A common mistake is to spell `SetUp()` as `Setup()` with a small `u` - don't let that happen to you.
|
||||||
1. If necessary, write a destructor or `TearDown()` function to release any resources you allocated in `SetUp()` . To learn when you should use the constructor/destructor and when you should use `SetUp()/TearDown()`, read this [FAQ entry](http://code.google.com/p/googletest/wiki/V1_7_FAQ#Should_I_use_the_constructor/destructor_of_the_test_fixture_or_t).
|
1. If necessary, write a destructor or `TearDown()` function to release any resources you allocated in `SetUp()` . To learn when you should use the constructor/destructor and when you should use `SetUp()/TearDown()`, read this [FAQ entry](V1_7_FAQ.md#should-i-use-the-constructordestructor-of-the-test-fixture-or-the-set-uptear-down-function).
|
||||||
1. If needed, define subroutines for your tests to share.
|
1. If needed, define subroutines for your tests to share.
|
||||||
|
|
||||||
When using a fixture, use `TEST_F()` instead of `TEST()` as it allows you to
|
When using a fixture, use `TEST_F()` instead of `TEST()` as it allows you to
|
||||||
@ -498,4 +498,4 @@ is currently _unsafe_ to use Google Test assertions from two threads
|
|||||||
concurrently on other systems (e.g. Windows). In most tests this is
|
concurrently on other systems (e.g. Windows). In most tests this is
|
||||||
not an issue as usually the assertions are done in the main thread. If
|
not an issue as usually the assertions are done in the main thread. If
|
||||||
you want to help, you can volunteer to implement the necessary
|
you want to help, you can volunteer to implement the necessary
|
||||||
synchronization primitives in `gtest-port.h` for your platform.
|
synchronization primitives in `gtest-port.h` for your platform.
|
||||||
|
@ -161,7 +161,7 @@ exp ::= simple_expression_in_Python_syntax
|
|||||||
|
|
||||||
## Code ##
|
## Code ##
|
||||||
|
|
||||||
You can find the source code of Pump in [scripts/pump.py](http://code.google.com/p/googletest/source/browse/trunk/scripts/pump.py). It is still
|
You can find the source code of Pump in [scripts/pump.py](../scripts/pump.py). It is still
|
||||||
very unpolished and lacks automated tests, although it has been
|
very unpolished and lacks automated tests, although it has been
|
||||||
successfully used many times. If you find a chance to use it in your
|
successfully used many times. If you find a chance to use it in your
|
||||||
project, please let us know what you think! We also welcome help on
|
project, please let us know what you think! We also welcome help on
|
||||||
@ -174,4 +174,4 @@ You can find real-world applications of Pump in [Google Test](http://www.google.
|
|||||||
## Tips ##
|
## Tips ##
|
||||||
|
|
||||||
* If a meta variable is followed by a letter or digit, you can separate them using `[[]]`, which inserts an empty string. For example `Foo$j[[]]Helper` generate `Foo1Helper` when `j` is 1.
|
* If a meta variable is followed by a letter or digit, you can separate them using `[[]]`, which inserts an empty string. For example `Foo$j[[]]Helper` generate `Foo1Helper` when `j` is 1.
|
||||||
* To avoid extra-long Pump source lines, you can break a line anywhere you want by inserting `[[]]` followed by a new line. Since any new-line character next to `[[` or `]]` is ignored, the generated code won't contain this new line.
|
* To avoid extra-long Pump source lines, you can break a line anywhere you want by inserting `[[]]` followed by a new line. Since any new-line character next to `[[` or `]]` is ignored, the generated code won't contain this new line.
|
||||||
|
@ -1,14 +1,14 @@
|
|||||||
If you're like us, you'd like to look at some Google Test sample code. The
|
If you're like us, you'd like to look at some Google Test sample code. The
|
||||||
[samples folder](http://code.google.com/p/googletest/source/browse/#svn/trunk/samples) has a number of well-commented samples showing how to use a
|
[samples folder](../samples) has a number of well-commented samples showing how to use a
|
||||||
variety of Google Test features.
|
variety of Google Test features.
|
||||||
|
|
||||||
* [Sample #1](http://code.google.com/p/googletest/source/browse/trunk/samples/sample1_unittest.cc) shows the basic steps of using Google Test to test C++ functions.
|
* [Sample #1](../samples/sample1_unittest.cc) shows the basic steps of using Google Test to test C++ functions.
|
||||||
* [Sample #2](http://code.google.com/p/googletest/source/browse/trunk/samples/sample2_unittest.cc) shows a more complex unit test for a class with multiple member functions.
|
* [Sample #2](../samples/sample2_unittest.cc) shows a more complex unit test for a class with multiple member functions.
|
||||||
* [Sample #3](http://code.google.com/p/googletest/source/browse/trunk/samples/sample3_unittest.cc) uses a test fixture.
|
* [Sample #3](../samples/sample3_unittest.cc) uses a test fixture.
|
||||||
* [Sample #4](http://code.google.com/p/googletest/source/browse/trunk/samples/sample4_unittest.cc) is another basic example of using Google Test.
|
* [Sample #4](../samples/sample4_unittest.cc) is another basic example of using Google Test.
|
||||||
* [Sample #5](http://code.google.com/p/googletest/source/browse/trunk/samples/sample5_unittest.cc) teaches how to reuse a test fixture in multiple test cases by deriving sub-fixtures from it.
|
* [Sample #5](../samples/sample5_unittest.cc) teaches how to reuse a test fixture in multiple test cases by deriving sub-fixtures from it.
|
||||||
* [Sample #6](http://code.google.com/p/googletest/source/browse/trunk/samples/sample6_unittest.cc) demonstrates type-parameterized tests.
|
* [Sample #6](../samples/sample6_unittest.cc) demonstrates type-parameterized tests.
|
||||||
* [Sample #7](http://code.google.com/p/googletest/source/browse/trunk/samples/sample7_unittest.cc) teaches the basics of value-parameterized tests.
|
* [Sample #7](../samples/sample7_unittest.cc) teaches the basics of value-parameterized tests.
|
||||||
* [Sample #8](http://code.google.com/p/googletest/source/browse/trunk/samples/sample8_unittest.cc) shows using `Combine()` in value-parameterized tests.
|
* [Sample #8](../samples/sample8_unittest.cc) shows using `Combine()` in value-parameterized tests.
|
||||||
* [Sample #9](http://code.google.com/p/googletest/source/browse/trunk/samples/sample9_unittest.cc) shows use of the listener API to modify Google Test's console output and the use of its reflection API to inspect test results.
|
* [Sample #9](../samples/sample9_unittest.cc) shows use of the listener API to modify Google Test's console output and the use of its reflection API to inspect test results.
|
||||||
* [Sample #10](http://code.google.com/p/googletest/source/browse/trunk/samples/sample10_unittest.cc) shows use of the listener API to implement a primitive memory leak checker.
|
* [Sample #10](../samples/sample10_unittest.cc) shows use of the listener API to implement a primitive memory leak checker.
|
||||||
|
Loading…
x
Reference in New Issue
Block a user