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