eson/googletest
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

docs/primer: Fixed usage of test case

Browse Source 
According to the nomenclature, what was called a test case
is actually a test suite
This commit is contained in:
Philipp Hasper 2019-06-16 15:00:02 +02:00 committed by GitHub
parent e110929a7b
commit b72b1bee95
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 11 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

22
googletest/docs/primer.md
View File

@ -253,10 +253,10 @@ TEST(TestSuiteName, TestName) {
``` ```
`TEST()` arguments go from general to specific. The *first* argument is the name `TEST()` arguments go from general to specific. The *first* argument is the name
of the test case, and the *second* argument is the test's name within the test of the test suite, and the *second* argument is the test's name within the test
case. Both names must be valid C++ identifiers, and they should not contain case. Both names must be valid C++ identifiers, and they should not contain
underscore (`_`). A test's *full name* consists of its containing test case and underscore (`_`). A test's *full name* consists of its containing test suite and
its individual name. Tests from different test cases can have the same its individual name. Tests from different test suites can have the same
individual name. individual name.
For example, let's take a simple integer function: For example, let's take a simple integer function:
@ -282,13 +282,13 @@ TEST(FactorialTest, HandlesPositiveInput) {
} }
``` ```
googletest groups the test results by test cases, so logically-related tests googletest groups the test results by test suites, so logically-related tests
should be in the same test case; in other words, the first argument to their should be in the same test suite; in other words, the first argument to their
`TEST()` should be the same. In the above example, we have two tests, `TEST()` should be the same. In the above example, we have two tests,
`HandlesZeroInput` and `HandlesPositiveInput`, that belong to the same test case `HandlesZeroInput` and `HandlesPositiveInput`, that belong to the same test suite
`FactorialTest`. `FactorialTest`.
When naming your test cases and tests, you should follow the same convention as When naming your test suites and tests, you should follow the same convention as
for [naming functions and for [naming functions and
classes](https://google.github.io/styleguide/cppguide.html#Function_Names). classes](https://google.github.io/styleguide/cppguide.html#Function_Names).
@ -324,7 +324,7 @@ TEST_F(TestSuiteName, TestName) {
} }
``` ```
Like `TEST()`, the first argument is the test case name, but for `TEST_F()` this Like `TEST()`, the first argument is the test suite name, but for `TEST_F()` this
must be the name of the test fixture class. You've probably guessed: `_F` is for must be the name of the test fixture class. You've probably guessed: `_F` is for
fixture. fixture.
@ -339,7 +339,7 @@ declaration`".
For each test defined with `TEST_F()` , googletest will create a *fresh* test For each test defined with `TEST_F()` , googletest will create a *fresh* test
fixture at runtime, immediately initialize it via `SetUp()` , run the test, fixture at runtime, immediately initialize it via `SetUp()` , run the test,
clean up by calling `TearDown()` , and then delete the test fixture. Note that clean up by calling `TearDown()` , and then delete the test fixture. Note that
different tests in the same test case have different test fixture objects, and different tests in the same test suite have different test fixture objects, and
googletest always deletes a test fixture before it creates the next one. googletest always deletes a test fixture before it creates the next one.
googletest does **not** reuse the same test fixture for multiple tests. Any googletest does **not** reuse the same test fixture for multiple tests. Any
changes one test makes to the fixture do not affect other tests. changes one test makes to the fixture do not affect other tests.
@ -436,7 +436,7 @@ your defined tests in order to run them.
After defining your tests, you can run them with `RUN_ALL_TESTS()` , which After defining your tests, you can run them with `RUN_ALL_TESTS()` , which
returns `0` if all the tests are successful, or `1` otherwise. Note that returns `0` if all the tests are successful, or `1` otherwise. Note that
`RUN_ALL_TESTS()` runs *all tests* in your link unit -- they can be from `RUN_ALL_TESTS()` runs *all tests* in your link unit -- they can be from
different test cases, or even different source files. different test suites, or even different source files.
When invoked, the `RUN_ALL_TESTS()` macro: When invoked, the `RUN_ALL_TESTS()` macro:
@ -508,7 +508,7 @@ class FooTest : public ::testing::Test {
// before the destructor). // before the destructor).
} }
// Objects declared here can be used by all tests in the test case for Foo. // Objects declared here can be used by all tests in the test suite for Foo.
}; };
// Tests that the Foo::Bar() method does Abc. // Tests that the Foo::Bar() method does Abc.