Lines Matching +full:check +full:- +full:test +full:- +full:suites
12 So what makes a good test, and how does GoogleTest fit in? We believe:
14 1. Tests should be *independent* and *repeatable*. It's a pain to debug a test
16 tests by running each of them on a different object. When a test fails,
19 code. GoogleTest groups related tests into test suites that can share data
24 platform-neutral; its tests should also be platform-neutral. GoogleTest
28 as possible. GoogleTest doesn't stop at the first test failure. Instead, it
29 only stops the current test and continues with the next. You can also set up
30 tests that report non-fatal failures after which the current test continues.
31 Thus, you can detect and fix multiple bugs in a single run-edit-compile
33 5. The testing framework should liberate test writers from housekeeping chores
34 and let them focus on the test *content*. GoogleTest automatically keeps
38 across tests and pay for the set-up/tear-down only once, without making
49 terms *Test*, *Test Case* and *Test Suite*, so beware of misunderstanding these.
51 Historically, GoogleTest started to use the term *Test Case* for grouping
55 *[Test Suite][istqb test suite]* for this.
57 The related term *Test*, as it is used in GoogleTest, corresponds to the term
58 *[Test Case][istqb test case]* of ISTQB and others.
60 The term *Test* is commonly of broad enough sense, including ISTQB's definition
61 of *Test Case*, so it's not much of a problem here. But the term *Test Case* as
62 was used in Google Test is of contradictory sense and thus confusing.
64 GoogleTest recently started replacing the term *Test Case* with *Test Suite*.
72 :----------------------------------------------------------------------------------- | :-----------…
73 …with specific input values and verify the results | [TEST()](#simple-tests) | [Test Case][istqb te…
76 [istqb test case]: http://glossary.istqb.org/en/search/test%20case
77 [istqb test suite]: http://glossary.istqb.org/en/search/test%20suite
82 that check whether a condition is true. An assertion's result can be *success*,
86 *Tests* use assertions to verify the tested code's behavior. If a test crashes
89 A *test suite* contains one or many tests. You should group your tests into test
90 suites that reflect the structure of the tested code. When multiple tests in a
91 test suite need to share common objects and subroutines, you can put them into a
92 *test fixture* class.
94 A *test program* can contain multiple test suites.
96 We'll now explain how to write a test program, starting at the individual
97 assertion level and building up to tests and test suites.
101 GoogleTest assertions are macros that resemble function calls. You test a class
107 The assertions come in pairs that test the same thing but have different effects
111 preferred, as they allow more than one failure to be reported in a test.
116 possibly skipping clean-up code that comes after it, it may cause a space leak.
117 Depending on the nature of the leak, it may or may not be worth fixing - so keep
134 macro--in particular, C strings and `string` objects. If a wide string
136 streamed to an assertion, it will be translated to UTF-8 when printed.
139 your code in various ways. You can check Boolean conditions, compare values
140 based on relational operators, verify string values, floating-point values, and
147 To create a test:
149 1. Use the `TEST()` macro to define and name a test function. These are
152 use the various GoogleTest assertions to check values.
153 3. The test's result is determined by the assertions; if any assertion in the
154 test fails (either fatally or non-fatally), or if the test crashes, the
155 entire test fails. Otherwise, it succeeds.
158 TEST(TestSuiteName, TestName) {
159 ... test body ...
163 `TEST()` arguments go from general to specific. The *first* argument is the name
164 of the test suite, and the *second* argument is the test's name within the test
166 underscores (`_`). A test's *full name* consists of its containing test suite
167 and its individual name. Tests from different test suites can have the same
176 A test suite for this function might look like:
180 TEST(FactorialTest, HandlesZeroInput) {
185 TEST(FactorialTest, HandlesPositiveInput) {
193 GoogleTest groups the test results by test suites, so logically related tests
194 should be in the same test suite; in other words, the first argument to their
195 `TEST()` should be the same. In the above example, we have two tests,
196 `HandlesZeroInput` and `HandlesPositiveInput`, that belong to the same test
199 When naming your test suites and tests, you should follow the same convention as
205 ## Test Fixtures: Using the Same Data Configuration for Multiple Tests {#same-data-multiple-tests}
208 can use a *test fixture*. This allows you to reuse the same configuration of
213 1. Derive a class from `::testing::Test` . Start its body with `protected:`, as
214 we'll want to access fixture members from sub-classes.
217 the objects for each test. A common mistake is to spell `SetUp()` as
218 **`Setup()`** with a small `u` - Use `override` in C++11 to make sure you
226 When using a fixture, use `TEST_F()` instead of `TEST()` as it allows you to
227 access objects and subroutines in the test fixture:
231 ... test body ...
235 Unlike `TEST()`, in `TEST_F()` the first argument must be the name of the test
236 fixture class. (`_F` stands for "Fixture"). No test suite name is specified for
243 Also, you must first define a test fixture class before using it in a
247 For each test defined with `TEST_F()`, GoogleTest will create a *fresh* test
248 fixture at runtime, immediately initialize it via `SetUp()`, run the test, clean
249 up by calling `TearDown()`, and then delete the test fixture. Note that
250 different tests in the same test suite have different test fixture objects, and
251 GoogleTest always deletes a test fixture before it creates the next one.
252 GoogleTest does **not** reuse the same test fixture for multiple tests. Any
253 changes one test makes to the fixture do not affect other tests.
274 class QueueTest : public ::testing::Test {
292 each test, other than what's already done by the destructor.
320 to use `EXPECT_*` when you want the test to continue to reveal more errors after
322 make sense. For example, the second assertion in the `Dequeue` test is
330 3. The first test (`IsEmptyInitially`) runs on `t1`.
331 4. `t1.TearDown()` cleans up after the test finishes.
334 running the `DequeueWorks` test.
340 `TEST()` and `TEST_F()` implicitly register their tests with GoogleTest. So,
341 unlike with many other C++ testing frameworks, you don't have to re-list all
346 `RUN_ALL_TESTS()` runs *all tests* in your link unit--they can be from different
347 test suites, or even different source files.
353 * Creates a test fixture object for the first test.
357 * Runs the test on the fixture object.
365 * Repeats the above steps for the next test, until all tests have run.
372 > automated testing service determines whether a test has passed based on its
377 > once conflicts with some advanced GoogleTest features (e.g., thread-safe
378 > [death tests](advanced.md#death-tests)) and thus is not supported.
388 cannot be expressed within the framework of fixtures and test suites.
405 class FooTest : public ::testing::Test {
411 // You can do set-up work for each test here.
415 // You can do clean-up work that doesn't throw exceptions here.
419 // and cleaning up each test, you can define the following methods:
423 // before each test).
427 // Code here will be called immediately after each test (right
431 // Class members declared here can be used by all tests in the test suite
460 control a test program's behavior via various flags, which we'll cover in the
468 agree with you completely, and that's why Google Test provides a basic
469 implementation of main(). If it fits your needs, then just link your test with
477 * Google Test is designed to be thread-safe. The implementation is thread-safe
479 *unsafe* to use Google Test assertions from two threads concurrently on
483 `gtest-port.h` for your platform.