Merge pull request #2042 from gennadiycivil/master
Update Docs TestCase->TestSuite
This commit is contained in:
Gennadiy Civil
GitHub
commit
3880b13e4c
|
|
@ -751,7 +751,7 @@ necessary.
|
|||
### Death Test Naming
|
||||
|
||||
IMPORTANT: We strongly recommend you to follow the convention of naming your
|
||||
**test case** (not test) `*DeathTest` when it contains a death test, as
|
||||
**test suite** (not test) `*DeathTest` when it contains a death test, as
|
||||
demonstrated in the above example. The [Death Tests And
|
||||
Threads](#death-tests-and-threads) section below explains why.
|
||||
|
||||
|
|
@ -865,7 +865,7 @@ googletest has three features intended to raise awareness of threading issues.
|
|||
|
||||
1. A warning is emitted if multiple threads are running when a death test is
|
||||
encountered.
|
||||
2. Test cases with a name ending in "DeathTest" are run before all other tests.
|
||||
2. Test suites with a name ending in "DeathTest" are run before all other tests.
|
||||
3. It uses `clone()` instead of `fork()` to spawn the child process on Linux
|
||||
(`clone()` is not available on Cygwin and Mac), as `fork()` is more likely
|
||||
to cause the child to hang when the parent process has multiple threads.
|
||||
|
|
@ -1174,15 +1174,15 @@ will output XML like this:
|
|||
> ones already used by googletest (`name`, `status`, `time`, `classname`,
|
||||
> `type_param`, and `value_param`).
|
||||
> * Calling `RecordProperty()` outside of the lifespan of a test is allowed.
|
||||
> If it's called outside of a test but between a test case's
|
||||
> `SetUpTestCase()` and `TearDownTestCase()` methods, it will be attributed
|
||||
> to the XML element for the test case. If it's called outside of all test
|
||||
> cases (e.g. in a test environment), it will be attributed to the top-level
|
||||
> If it's called outside of a test but between a test suite's
|
||||
> `SetUpTestSuite()` and `TearDownTestSuite()` methods, it will be attributed
|
||||
> to the XML element for the test suite. If it's called outside of all test
|
||||
> suites (e.g. in a test environment), it will be attributed to the top-level
|
||||
> XML element.
|
||||
|
||||
**Availability**: Linux, Windows, Mac.
|
||||
|
||||
## Sharing Resources Between Tests in the Same Test Case
|
||||
## Sharing Resources Between Tests in the Same Test Suite
|
||||
|
||||
googletest creates a new test fixture object for each test in order to make
|
||||
tests independent and easier to debug. However, sometimes tests use resources
|
||||
|
|
@ -1191,20 +1191,20 @@ expensive.
|
|||
|
||||
If the tests don't change the resource, there's no harm in their sharing a
|
||||
single resource copy. So, in addition to per-test set-up/tear-down, googletest
|
||||
also supports per-test-case set-up/tear-down. To use it:
|
||||
also supports per-test-suite set-up/tear-down. To use it:
|
||||
|
||||
1. In your test fixture class (say `FooTest` ), declare as `static` some member
|
||||
variables to hold the shared resources.
|
||||
1. Outside your test fixture class (typically just below it), define those
|
||||
member variables, optionally giving them initial values.
|
||||
1. In the same test fixture class, define a `static void SetUpTestCase()`
|
||||
function (remember not to spell it as **`SetupTestCase`** with a small `u`!)
|
||||
to set up the shared resources and a `static void TearDownTestCase()`
|
||||
1. In the same test fixture class, define a `static void SetUpTestSuite()`
|
||||
function (remember not to spell it as **`SetUpTestSuite`** with a small `u`!)
|
||||
to set up the shared resources and a `static void TearDownTestSuite()`
|
||||
function to tear them down.
|
||||
|
||||
That's it! googletest automatically calls `SetUpTestCase()` before running the
|
||||
*first test* in the `FooTest` test case (i.e. before creating the first
|
||||
`FooTest` object), and calls `TearDownTestCase()` after running the *last test*
|
||||
That's it! googletest automatically calls `SetUpTestSuite()` before running the
|
||||
*first test* in the `FooTest` test suite (i.e. before creating the first
|
||||
`FooTest` object), and calls `TearDownTestSuite()` after running the *last test*
|
||||
in it (i.e. after deleting the last `FooTest` object). In between, the tests can
|
||||
use the shared resources.
|
||||
|
||||
|
|
@ -1213,22 +1213,22 @@ preceding or following another. Also, the tests must either not modify the state
|
|||
of any shared resource, or, if they do modify the state, they must restore the
|
||||
state to its original value before passing control to the next test.
|
||||
|
||||
Here's an example of per-test-case set-up and tear-down:
|
||||
Here's an example of per-test-suite set-up and tear-down:
|
||||
|
||||
```c++
|
||||
class FooTest : public ::testing::Test {
|
||||
protected:
|
||||
// Per-test-case set-up.
|
||||
// Called before the first test in this test case.
|
||||
// Per-test-suite set-up.
|
||||
// Called before the first test in this test suite.
|
||||
// Can be omitted if not needed.
|
||||
static void SetUpTestCase() {
|
||||
static void SetUpTestSuite() {
|
||||
shared_resource_ = new ...;
|
||||
}
|
||||
|
||||
// Per-test-case tear-down.
|
||||
// Called after the last test in this test case.
|
||||
// Per-test-suite tear-down.
|
||||
// Called after the last test in this test suite.
|
||||
// Can be omitted if not needed.
|
||||
static void TearDownTestCase() {
|
||||
static void TearDownTestSuite() {
|
||||
delete shared_resource_;
|
||||
shared_resource_ = NULL;
|
||||
}
|
||||
|
|
@ -1254,7 +1254,7 @@ TEST_F(FooTest, Test2) {
|
|||
}
|
||||
```
|
||||
|
||||
NOTE: Though the above code declares `SetUpTestCase()` protected, it may
|
||||
NOTE: Though the above code declares `SetUpTestSuite()` protected, it may
|
||||
sometimes be necessary to declare it public, such as when using it with
|
||||
`TEST_P`.
|
||||
|
||||
|
|
@ -1262,7 +1262,7 @@ sometimes be necessary to declare it public, such as when using it with
|
|||
|
||||
## Global Set-Up and Tear-Down
|
||||
|
||||
Just as you can do set-up and tear-down at the test level and the test case
|
||||
Just as you can do set-up and tear-down at the test level and the test suite
|
||||
level, you can also do it at the test program level. Here's how.
|
||||
|
||||
First, you subclass the `::testing::Environment` class to define a test
|
||||
|
|
@ -1341,7 +1341,7 @@ both `::testing::Test` and `::testing::WithParamInterface<T>`. `T` can be any
|
|||
copyable type. If it's a raw pointer, you are responsible for managing the
|
||||
lifespan of the pointed values.
|
||||
|
||||
NOTE: If your test fixture defines `SetUpTestCase()` or `TearDownTestCase()`
|
||||
NOTE: If your test fixture defines `SetUpTestSuite()` or `TearDownTestSuite()`
|
||||
they must be declared **public** rather than **protected** in order to use
|
||||
`TEST_P`.
|
||||
|
||||
|
|
@ -1380,7 +1380,7 @@ TEST_P(FooTest, HasBlahBlah) {
|
|||
}
|
||||
```
|
||||
|
||||
Finally, you can use `INSTANTIATE_TEST_CASE_P` to instantiate the test case with
|
||||
Finally, you can use `INSTANTIATE_TEST_SUITE_P` to instantiate the test suite with
|
||||
any set of parameters you want. googletest defines a number of functions for
|
||||
generating test parameters. They return what we call (surprise!) *parameter
|
||||
generators*. Here is a summary of them, which are all in the `testing`
|
||||
|
|
@ -1396,11 +1396,11 @@ namespace:
|
|||
|
||||
For more details, see the comments at the definitions of these functions.
|
||||
|
||||
The following statement will instantiate tests from the `FooTest` test case each
|
||||
The following statement will instantiate tests from the `FooTest` test suite each
|
||||
with parameter values `"meeny"`, `"miny"`, and `"moe"`.
|
||||
|
||||
```c++
|
||||
INSTANTIATE_TEST_CASE_P(InstantiationName,
|
||||
INSTANTIATE_TEST_SUITE_P(InstantiationName,
|
||||
FooTest,
|
||||
::testing::Values("meeny", "miny", "moe"));
|
||||
```
|
||||
|
|
@ -1409,11 +1409,11 @@ NOTE: The code above must be placed at global or namespace scope, not at
|
|||
function scope.
|
||||
|
||||
NOTE: Don't forget this step! If you do your test will silently pass, but none
|
||||
of its cases will ever run!
|
||||
of its suites will ever run!
|
||||
|
||||
To distinguish different instances of the pattern (yes, you can instantiate it
|
||||
more than once), the first argument to `INSTANTIATE_TEST_CASE_P` is a prefix
|
||||
that will be added to the actual test case name. Remember to pick unique
|
||||
more than once), the first argument to `INSTANTIATE_TEST_SUITE_P` is a prefix
|
||||
that will be added to the actual test suite name. Remember to pick unique
|
||||
prefixes for different instantiations. The tests from the instantiation above
|
||||
will have these names:
|
||||
|
||||
|
|
@ -1431,7 +1431,7 @@ parameter values `"cat"` and `"dog"`:
|
|||
|
||||
```c++
|
||||
const char* pets[] = {"cat", "dog"};
|
||||
INSTANTIATE_TEST_CASE_P(AnotherInstantiationName, FooTest,
|
||||
INSTANTIATE_TEST_SUITE_P(AnotherInstantiationName, FooTest,
|
||||
::testing::ValuesIn(pets));
|
||||
```
|
||||
|
||||
|
|
@ -1442,9 +1442,9 @@ The tests from the instantiation above will have these names:
|
|||
* `AnotherInstantiationName/FooTest.HasBlahBlah/0` for `"cat"`
|
||||
* `AnotherInstantiationName/FooTest.HasBlahBlah/1` for `"dog"`
|
||||
|
||||
Please note that `INSTANTIATE_TEST_CASE_P` will instantiate *all* tests in the
|
||||
given test case, whether their definitions come before or *after* the
|
||||
`INSTANTIATE_TEST_CASE_P` statement.
|
||||
Please note that `INSTANTIATE_TEST_SUITE_P` will instantiate *all* tests in the
|
||||
given test suite, whether their definitions come before or *after* the
|
||||
`INSTANTIATE_TEST_SUITE_P` statement.
|
||||
|
||||
You can see sample7_unittest.cc and sample8_unittest.cc for more examples.
|
||||
|
||||
|
|
@ -1470,13 +1470,13 @@ To define abstract tests, you should organize your code like this:
|
|||
`foo_param_test.h`. Think of this as *implementing* your abstract tests.
|
||||
|
||||
Once they are defined, you can instantiate them by including `foo_param_test.h`,
|
||||
invoking `INSTANTIATE_TEST_CASE_P()`, and depending on the library target that
|
||||
contains `foo_param_test.cc`. You can instantiate the same abstract test case
|
||||
invoking `INSTANTIATE_TEST_SUITE_P()`, and depending on the library target that
|
||||
contains `foo_param_test.cc`. You can instantiate the same abstract test suite
|
||||
multiple times, possibly in different source files.
|
||||
|
||||
### Specifying Names for Value-Parameterized Test Parameters
|
||||
|
||||
The optional last argument to `INSTANTIATE_TEST_CASE_P()` allows the user to
|
||||
The optional last argument to `INSTANTIATE_TEST_SUITE_P()` allows the user to
|
||||
specify a function or functor that generates custom test name suffixes based on
|
||||
the test parameters. The function should accept one argument of type
|
||||
`testing::TestParamInfo<class ParamType>`, and return `std::string`.
|
||||
|
|
@ -1487,17 +1487,17 @@ returns the value of `testing::PrintToString(GetParam())`. It does not work for
|
|||
|
||||
NOTE: test names must be non-empty, unique, and may only contain ASCII
|
||||
alphanumeric characters. In particular, they [should not contain
|
||||
underscores](https://github.com/google/googletest/blob/master/googletest/docs/faq.md#why-should-test-case-names-and-test-names-not-contain-underscore).
|
||||
underscores](https://github.com/google/googletest/blob/master/googletest/docs/faq.md#why-should-test-suite-names-and-test-names-not-contain-underscore).
|
||||
|
||||
```c++
|
||||
class MyTestCase : public testing::TestWithParam<int> {};
|
||||
class MyTestsuite : public testing::TestWithParam<int> {};
|
||||
|
||||
TEST_P(MyTestCase, MyTest)
|
||||
TEST_P(MyTestsuite, MyTest)
|
||||
{
|
||||
std::cout << "Example Test Param: " << GetParam() << std::endl;
|
||||
}
|
||||
|
||||
INSTANTIATE_TEST_CASE_P(MyGroup, MyTestCase, testing::Range(0, 10),
|
||||
INSTANTIATE_TEST_SUITE_P(MyGroup, MyTestsuite, testing::Range(0, 10),
|
||||
testing::PrintToStringParamName());
|
||||
```
|
||||
|
||||
|
|
@ -1532,20 +1532,20 @@ class FooTest : public ::testing::Test {
|
|||
};
|
||||
```
|
||||
|
||||
Next, associate a list of types with the test case, which will be repeated for
|
||||
Next, associate a list of types with the test suite, which will be repeated for
|
||||
each type in the list:
|
||||
|
||||
```c++
|
||||
using MyTypes = ::testing::Types<char, int, unsigned int>;
|
||||
TYPED_TEST_CASE(FooTest, MyTypes);
|
||||
TYPED_TEST_SUITE(FooTest, MyTypes);
|
||||
```
|
||||
|
||||
The type alias (`using` or `typedef`) is necessary for the `TYPED_TEST_CASE`
|
||||
The type alias (`using` or `typedef`) is necessary for the `TYPED_TEST_SUITE`
|
||||
macro to parse correctly. Otherwise the compiler will think that each comma in
|
||||
the type list introduces a new macro argument.
|
||||
|
||||
Then, use `TYPED_TEST()` instead of `TEST_F()` to define a typed test for this
|
||||
test case. You can repeat this as many times as you want:
|
||||
test suite. You can repeat this as many times as you want:
|
||||
|
||||
```c++
|
||||
TYPED_TEST(FooTest, DoesBlah) {
|
||||
|
|
@ -1596,10 +1596,10 @@ class FooTest : public ::testing::Test {
|
|||
};
|
||||
```
|
||||
|
||||
Next, declare that you will define a type-parameterized test case:
|
||||
Next, declare that you will define a type-parameterized test suite:
|
||||
|
||||
```c++
|
||||
TYPED_TEST_CASE_P(FooTest);
|
||||
TYPED_TEST_SUITE_P(FooTest);
|
||||
```
|
||||
|
||||
Then, use `TYPED_TEST_P()` to define a type-parameterized test. You can repeat
|
||||
|
|
@ -1616,12 +1616,12 @@ TYPED_TEST_P(FooTest, HasPropertyA) { ... }
|
|||
```
|
||||
|
||||
Now the tricky part: you need to register all test patterns using the
|
||||
`REGISTER_TYPED_TEST_CASE_P` macro before you can instantiate them. The first
|
||||
argument of the macro is the test case name; the rest are the names of the tests
|
||||
in this test case:
|
||||
`REGISTER_TYPED_TEST_SUITE_P` macro before you can instantiate them. The first
|
||||
argument of the macro is the test suite name; the rest are the names of the tests
|
||||
in this test suite:
|
||||
|
||||
```c++
|
||||
REGISTER_TYPED_TEST_CASE_P(FooTest,
|
||||
REGISTER_TYPED_TEST_SUITE_P(FooTest,
|
||||
DoesBlah, HasPropertyA);
|
||||
```
|
||||
|
||||
|
|
@ -1631,18 +1631,18 @@ source files and instantiate it multiple times.
|
|||
|
||||
```c++
|
||||
typedef ::testing::Types<char, int, unsigned int> MyTypes;
|
||||
INSTANTIATE_TYPED_TEST_CASE_P(My, FooTest, MyTypes);
|
||||
INSTANTIATE_TYPED_TEST_SUITE_P(My, FooTest, MyTypes);
|
||||
```
|
||||
|
||||
To distinguish different instances of the pattern, the first argument to the
|
||||
`INSTANTIATE_TYPED_TEST_CASE_P` macro is a prefix that will be added to the
|
||||
actual test case name. Remember to pick unique prefixes for different instances.
|
||||
`INSTANTIATE_TYPED_TEST_SUITE_P` macro is a prefix that will be added to the
|
||||
actual test suite name. Remember to pick unique prefixes for different instances.
|
||||
|
||||
In the special case where the type list contains only one type, you can write
|
||||
that type directly without `::testing::Types<...>`, like this:
|
||||
|
||||
```c++
|
||||
INSTANTIATE_TYPED_TEST_CASE_P(My, FooTest, int);
|
||||
INSTANTIATE_TYPED_TEST_SUITE_P(My, FooTest, int);
|
||||
```
|
||||
|
||||
You can see `sample6_unittest.cc` for a complete example.
|
||||
|
|
@ -1704,7 +1704,7 @@ To test them, we use the following special techniques:
|
|||
this line in the class body:
|
||||
|
||||
```c++
|
||||
FRIEND_TEST(TestCaseName, TestName);
|
||||
FRIEND_TEST(TestsuiteName, TestName);
|
||||
```
|
||||
|
||||
For example,
|
||||
|
|
@ -1826,11 +1826,11 @@ namespace testing {
|
|||
|
||||
class TestInfo {
|
||||
public:
|
||||
// Returns the test case name and the test name, respectively.
|
||||
// Returns the test suite name and the test name, respectively.
|
||||
//
|
||||
// Do NOT delete or free the return value - it's managed by the
|
||||
// TestInfo class.
|
||||
const char* test_case_name() const;
|
||||
const char* test_suite_name() const;
|
||||
const char* name() const;
|
||||
};
|
||||
|
||||
|
|
@ -1848,14 +1848,14 @@ To obtain a `TestInfo` object for the currently running test, call
|
|||
|
||||
|
||||
|
||||
printf("We are in test %s of test case %s.\n",
|
||||
printf("We are in test %s of test suite %s.\n",
|
||||
test_info->name(),
|
||||
test_info->test_case_name());
|
||||
test_info->test_suite_name());
|
||||
```
|
||||
|
||||
`current_test_info()` returns a null pointer if no test is running. In
|
||||
particular, you cannot find the test case name in `TestCaseSetUp()`,
|
||||
`TestCaseTearDown()` (where you know the test case name implicitly), or
|
||||
particular, you cannot find the test suite name in `TestsuiteSetUp()`,
|
||||
`TestsuiteTearDown()` (where you know the test suite name implicitly), or
|
||||
functions called from them.
|
||||
|
||||
**Availability**: Linux, Windows, Mac.
|
||||
|
|
@ -1864,7 +1864,7 @@ functions called from them.
|
|||
|
||||
googletest provides an **event listener API** to let you receive notifications
|
||||
about the progress of a test program and test failures. The events you can
|
||||
listen to include the start and end of the test program, a test case, or a test
|
||||
listen to include the start and end of the test program, a test suite, or a test
|
||||
method, among others. You may use this API to augment or replace the standard
|
||||
console output, replace the XML output, or provide a completely different form
|
||||
of output, such as a GUI or a database. You can also use test events as
|
||||
|
|
@ -1885,7 +1885,7 @@ When an event is fired, its context is passed to the handler function as an
|
|||
argument. The following argument types are used:
|
||||
|
||||
* UnitTest reflects the state of the entire test program,
|
||||
* TestCase has information about a test case, which can contain one or more
|
||||
* Testsuite has information about a test suite, which can contain one or more
|
||||
tests,
|
||||
* TestInfo contains the state of a test, and
|
||||
* TestPartResult represents the result of a test assertion.
|
||||
|
|
@ -1900,7 +1900,7 @@ Here's an example:
|
|||
// Called before a test starts.
|
||||
virtual void OnTestStart(const ::testing::TestInfo& test_info) {
|
||||
printf("*** Test %s.%s starting.\n",
|
||||
test_info.test_case_name(), test_info.name());
|
||||
test_info.test_suite_name(), test_info.name());
|
||||
}
|
||||
|
||||
// Called after a failed assertion or a SUCCESS().
|
||||
|
|
@ -1915,7 +1915,7 @@ Here's an example:
|
|||
// Called after a test ends.
|
||||
virtual void OnTestEnd(const ::testing::TestInfo& test_info) {
|
||||
printf("*** Test %s.%s ending.\n",
|
||||
test_info.test_case_name(), test_info.name());
|
||||
test_info.test_suite_name(), test_info.name());
|
||||
}
|
||||
};
|
||||
```
|
||||
|
|
@ -2002,10 +2002,10 @@ running them so that a filter may be applied if needed. Including the flag
|
|||
format:
|
||||
|
||||
```none
|
||||
TestCase1.
|
||||
Testsuite1.
|
||||
TestName1
|
||||
TestName2
|
||||
TestCase2.
|
||||
Testsuite2.
|
||||
TestName
|
||||
```
|
||||
|
||||
|
|
@ -2020,7 +2020,7 @@ By default, a googletest program runs all tests the user has defined. Sometimes,
|
|||
you want to run only a subset of the tests (e.g. for debugging or quickly
|
||||
verifying a change). If you set the `GTEST_FILTER` environment variable or the
|
||||
`--gtest_filter` flag to a filter string, googletest will only run the tests
|
||||
whose full names (in the form of `TestCaseName.TestName`) match the filter.
|
||||
whose full names (in the form of `TestsuiteName.TestName`) match the filter.
|
||||
|
||||
The format of a filter is a '`:`'-separated list of wildcard patterns (called
|
||||
the *positive patterns*) optionally followed by a '`-`' and another
|
||||
|
|
@ -2038,16 +2038,16 @@ For example:
|
|||
* `./foo_test` Has no flag, and thus runs all its tests.
|
||||
* `./foo_test --gtest_filter=*` Also runs everything, due to the single
|
||||
match-everything `*` value.
|
||||
* `./foo_test --gtest_filter=FooTest.*` Runs everything in test case `FooTest`
|
||||
* `./foo_test --gtest_filter=FooTest.*` Runs everything in test suite `FooTest`
|
||||
.
|
||||
* `./foo_test --gtest_filter=*Null*:*Constructor*` Runs any test whose full
|
||||
name contains either `"Null"` or `"Constructor"` .
|
||||
* `./foo_test --gtest_filter=-*DeathTest.*` Runs all non-death tests.
|
||||
* `./foo_test --gtest_filter=FooTest.*-FooTest.Bar` Runs everything in test
|
||||
case `FooTest` except `FooTest.Bar`.
|
||||
suite `FooTest` except `FooTest.Bar`.
|
||||
* `./foo_test --gtest_filter=FooTest.*:BarTest.*-FooTest.Bar:BarTest.Foo` Runs
|
||||
everything in test case `FooTest` except `FooTest.Bar` and everything in
|
||||
test case `BarTest` except `BarTest.Foo`.
|
||||
everything in test suite `FooTest` except `FooTest.Bar` and everything in
|
||||
test suite `BarTest` except `BarTest.Foo`.
|
||||
|
||||
#### Temporarily Disabling Tests
|
||||
|
||||
|
|
@ -2056,9 +2056,9 @@ If you have a broken test that you cannot fix right away, you can add the
|
|||
better than commenting out the code or using `#if 0`, as disabled tests are
|
||||
still compiled (and thus won't rot).
|
||||
|
||||
If you need to disable all tests in a test case, you can either add `DISABLED_`
|
||||
If you need to disable all tests in a test suite, you can either add `DISABLED_`
|
||||
to the front of the name of each test, or alternatively add it to the front of
|
||||
the test case name.
|
||||
the test suite name.
|
||||
|
||||
For example, the following tests won't be run by googletest, even though they
|
||||
will still be compiled:
|
||||
|
|
@ -2165,7 +2165,7 @@ important information:
|
|||
... some error messages ...<br/>
|
||||
<span style="color:red">[ FAILED ] <span style="color:black">BarTest.ReturnsTrueOnSuccess<br/>
|
||||
...<br/>
|
||||
<span style="color:green">[==========]<span style="color:black"> 30 tests from 14 test cases ran.<br/>
|
||||
<span style="color:green">[==========]<span style="color:black"> 30 tests from 14 test suites ran.<br/>
|
||||
<span style="color:green">[ PASSED ]<span style="color:black"> 28 tests.<br/>
|
||||
<span style="color:red">[ FAILED ]<span style="color:black"> 2 tests, listed below:<br/>
|
||||
<span style="color:red">[ FAILED ]<span style="color:black"> BarTest.ReturnsTrueOnSuccess<br/>
|
||||
|
|
@ -2227,7 +2227,7 @@ apply to googletest tests, as shown here:
|
|||
|
||||
```xml
|
||||
<testsuites name="AllTests" ...>
|
||||
<testsuite name="test_case_name" ...>
|
||||
<testsuite name="test_suite_name" ...>
|
||||
<testcase name="test_name" ...>
|
||||
<failure message="..."/>
|
||||
<failure message="..."/>
|
||||
|
|
@ -2238,7 +2238,7 @@ apply to googletest tests, as shown here:
|
|||
```
|
||||
|
||||
* The root `<testsuites>` element corresponds to the entire test program.
|
||||
* `<testsuite>` elements correspond to googletest test cases.
|
||||
* `<testsuite>` elements correspond to googletest test suites.
|
||||
* `<testcase>` elements correspond to googletest test functions.
|
||||
|
||||
For instance, the following program
|
||||
|
|
@ -2272,10 +2272,10 @@ could generate this report:
|
|||
Things to note:
|
||||
|
||||
* The `tests` attribute of a `<testsuites>` or `<testsuite>` element tells how
|
||||
many test functions the googletest program or test case contains, while the
|
||||
many test functions the googletest program or test suite contains, while the
|
||||
`failures` attribute tells how many of them failed.
|
||||
|
||||
* The `time` attribute expresses the duration of the test, test case, or
|
||||
* The `time` attribute expresses the duration of the test, test suite, or
|
||||
entire test program in seconds.
|
||||
|
||||
* The `timestamp` attribute records the local date and time of the test
|
||||
|
|
@ -2302,7 +2302,7 @@ The report format conforms to the following JSON Schema:
|
|||
"$schema": "http://json-schema.org/schema#",
|
||||
"type": "object",
|
||||
"definitions": {
|
||||
"TestCase": {
|
||||
"Testsuite": {
|
||||
"type": "object",
|
||||
"properties": {
|
||||
"name": { "type": "string" },
|
||||
|
|
@ -2358,7 +2358,7 @@ The report format conforms to the following JSON Schema:
|
|||
"testsuites": {
|
||||
"type": "array",
|
||||
"items": {
|
||||
"$ref": "#/definitions/TestCase"
|
||||
"$ref": "#/definitions/Testsuite"
|
||||
}
|
||||
}
|
||||
}
|
||||
|
|
@ -2384,7 +2384,7 @@ message UnitTest {
|
|||
google.protobuf.Timestamp timestamp = 5;
|
||||
google.protobuf.Duration time = 6;
|
||||
string name = 7;
|
||||
repeated TestCase testsuites = 8;
|
||||
repeated Testsuite testsuites = 8;
|
||||
}
|
||||
|
||||
message TestCase {
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
# Googletest FAQ
|
||||
|
||||
|
||||
## Why should test case names and test names not contain underscore?
|
||||
## Why should test suite names and test names not contain underscore?
|
||||
|
||||
Underscore (`_`) is special, as C++ reserves the following to be used by the
|
||||
compiler and the standard library:
|
||||
|
|
@ -14,26 +14,26 @@ User code is *prohibited* from using such identifiers.
|
|||
|
||||
Now let's look at what this means for `TEST` and `TEST_F`.
|
||||
|
||||
Currently `TEST(TestCaseName, TestName)` generates a class named
|
||||
`TestCaseName_TestName_Test`. What happens if `TestCaseName` or `TestName`
|
||||
Currently `TEST(TestSuiteName, TestName)` generates a class named
|
||||
`TestSuiteName_TestName_Test`. What happens if `TestSuiteName` or `TestName`
|
||||
contains `_`?
|
||||
|
||||
1. If `TestCaseName` starts with an `_` followed by an upper-case letter (say,
|
||||
1. If `TestSuiteName` starts with an `_` followed by an upper-case letter (say,
|
||||
`_Foo`), we end up with `_Foo_TestName_Test`, which is reserved and thus
|
||||
invalid.
|
||||
1. If `TestCaseName` ends with an `_` (say, `Foo_`), we get
|
||||
1. If `TestSuiteName` ends with an `_` (say, `Foo_`), we get
|
||||
`Foo__TestName_Test`, which is invalid.
|
||||
1. If `TestName` starts with an `_` (say, `_Bar`), we get
|
||||
`TestCaseName__Bar_Test`, which is invalid.
|
||||
`TestSuiteName__Bar_Test`, which is invalid.
|
||||
1. If `TestName` ends with an `_` (say, `Bar_`), we get
|
||||
`TestCaseName_Bar__Test`, which is invalid.
|
||||
`TestSuiteName_Bar__Test`, which is invalid.
|
||||
|
||||
So clearly `TestCaseName` and `TestName` cannot start or end with `_` (Actually,
|
||||
`TestCaseName` can start with `_` -- as long as the `_` isn't followed by an
|
||||
So clearly `TestSuiteName` and `TestName` cannot start or end with `_` (Actually,
|
||||
`TestSuiteName` can start with `_` -- as long as the `_` isn't followed by an
|
||||
upper-case letter. But that's getting complicated. So for simplicity we just say
|
||||
that it cannot start with `_`.).
|
||||
|
||||
It may seem fine for `TestCaseName` and `TestName` to contain `_` in the middle.
|
||||
It may seem fine for `TestSuiteName` and `TestName` to contain `_` in the middle.
|
||||
However, consider this:
|
||||
|
||||
```c++
|
||||
|
|
@ -44,7 +44,7 @@ TEST(Time_Flies, Like_An_Arrow) { ... }
|
|||
Now, the two `TEST`s will both generate the same class
|
||||
(`Time_Flies_Like_An_Arrow_Test`). That's not good.
|
||||
|
||||
So for simplicity, we just ask the users to avoid `_` in `TestCaseName` and
|
||||
So for simplicity, we just ask the users to avoid `_` in `TestSuiteName` and
|
||||
`TestName`. The rule is more constraining than necessary, but it's simple and
|
||||
easy to remember. It also gives googletest some wiggle room in case its
|
||||
implementation needs to change in the future.
|
||||
|
|
@ -472,7 +472,7 @@ switch to `EXPECT_*()` if that works. This
|
|||
|
||||
C++ is case-sensitive. Did you spell it as `Setup()`?
|
||||
|
||||
Similarly, sometimes people spell `SetUpTestCase()` as `SetupTestCase()` and
|
||||
Similarly, sometimes people spell `SetUpTestSuite()` as `SetupTestSuite()` and
|
||||
wonder why it's never called.
|
||||
|
||||
## How do I jump to the line of a failure in Emacs directly?
|
||||
|
|
|
|||
|
|
@ -61,21 +61,19 @@ The related term _Test_, as it is used in the googletest, is corresponding to
|
|||
the term _[Test Case](http://glossary.istqb.org/search/test%20case)_ of ISTQB
|
||||
and others.
|
||||
|
||||
The term _Test_ is commonly of broad enough sense, including ISTQB's
|
||||
definition of _Test Case_, so it's not much of a problem here. But the
|
||||
term _Test Case_ as used in Google Test is of contradictory sense and thus confusing.
|
||||
The term _Test_ is commonly of broad enough sense, including ISTQB's definition
|
||||
of _Test Case_, so it's not much of a problem here. But the term _Test Case_ as
|
||||
was used in Google Test is of contradictory sense and thus confusing.
|
||||
|
||||
Unfortunately replacing the term _Test Case_ by _Test Suite_ throughout the
|
||||
googletest is not easy without breaking dependent projects, as `TestCase` is
|
||||
part of the public API at various places.
|
||||
googletest recently started replacing the term _Test Case_ by _Test Suite_ The
|
||||
preferred API is TestSuite*. The older TestCase* API is being slowly deprecated
|
||||
and refactored away
|
||||
|
||||
So for the time being, please be aware of the different definitions of
|
||||
the terms:
|
||||
So please be aware of the different definitions of the terms:
|
||||
|
||||
Meaning | googletest Term | [ISTQB](http://www.istqb.org/) Term
|
||||
:----------------------------------------------------------------------------------- | :--------------------------------------------------------------------------------------------------------- | :----------------------------------
|
||||
Exercise a particular program path with specific input values and verify the results | [TEST()](#simple-tests) | [Test Case](http://glossary.istqb.org/search/test%20case)
|
||||
A set of several tests related to one component | [TestCase](#basic-concepts) | [TestSuite](http://glossary.istqb.org/search/test%20suite)
|
||||
|
||||
## Basic Concepts
|
||||
|
||||
|
|
@ -252,7 +250,7 @@ To create a test:
|
|||
entire test fails. Otherwise, it succeeds.
|
||||
|
||||
```c++
|
||||
TEST(TestCaseName, TestName) {
|
||||
TEST(TestSuiteName, TestName) {
|
||||
... test body ...
|
||||
}
|
||||
```
|
||||
|
|
@ -324,7 +322,7 @@ When using a fixture, use `TEST_F()` instead of `TEST()` as it allows you to
|
|||
access objects and subroutines in the test fixture:
|
||||
|
||||
```c++
|
||||
TEST_F(TestCaseName, TestName) {
|
||||
TEST_F(TestSuiteName, TestName) {
|
||||
... test body ...
|
||||
}
|
||||
```
|
||||
|
|
|
|||
Loading…
Reference in New Issue
Block a user