Lines Matching full:test
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
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.
33 5. The testing framework should liberate test writers from housekeeping chores
34 and let them focus on the test *content*. GoogleTest automatically keeps
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*.
73 …with specific input values and verify the results | [TEST()](#simple-tests) | [Test Case][istqb te…
76 [istqb test case]: https://glossary.istqb.org/en_US/term/test-case-2
77 [istqb test suite]: https://glossary.istqb.org/en_US/term/test-suite-1-3
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
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.
147 To create a test:
149 1. Use the `TEST()` macro to define and name a test function. These are
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
217 the objects for each test. A common mistake is to spell `SetUp()` as
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 {
321 to use `EXPECT_*` when you want the test to continue to reveal more errors after
323 make sense. For example, the second assertion in the `Dequeue` test is
330 2. The first test (`IsEmptyInitially`) runs on `t1`.
333 running the `DequeueWorks` test.
339 `TEST()` and `TEST_F()` implicitly register their tests with GoogleTest. So,
346 test suites, or even different source files.
352 * Creates a test fixture object for the first test.
356 * Runs the test on the fixture object.
364 * Repeats the above steps for the next test, until all tests have run.
371 > automated testing service determines whether a test has passed based on its
387 cannot be expressed within the framework of fixtures and test suites.
404 class FooTest : public testing::Test {
410 // You can do set-up work for each test here.
418 // and cleaning up each test, you can define the following methods:
422 // before each test).
426 // Code here will be called immediately after each test (right
430 // Class members declared here can be used by all tests in the test suite
458 flags, and removes all recognized flags. This allows the user to control a test
467 agree with you completely, and that's why Google Test provides a basic
468 implementation of main(). If it fits your needs, then just link your test with
476 * Google Test is designed to be thread-safe. The implementation is thread-safe
478 *unsafe* to use Google Test assertions from two threads concurrently on