Lines Matching full:tests
5 *GoogleTest* helps you write better C++ tests.
10 supports *any* kind of tests, not just unit tests.
14 1. Tests should be *independent* and *repeatable*. It's a pain to debug a test
15 that succeeds or fails as a result of other tests. GoogleTest isolates the
16 tests by running each of them on a different object. When a test fails,
18 2. Tests should be well *organized* and reflect the structure of the tested
19 code. GoogleTest groups related tests into test suites that can share data
20 and subroutines. This common pattern is easy to recognize and makes tests
23 3. Tests should be *portable* and *reusable*. Google has a lot of code that is
24 platform-neutral; its tests should also be platform-neutral. GoogleTest
26 exceptions, so GoogleTest tests can work with a variety of configurations.
27 4. When tests fail, they should provide as much *information* about the problem
30 tests that report non-fatal failures after which the current test continues.
35 track of all tests defined, and doesn't require the user to enumerate them
37 6. Tests should be *fast*. With GoogleTest, you can reuse shared resources
38 across tests and pay for the set-up/tear-down only once, without making
39 tests depend on each other.
52 related tests, whereas current publications, including International Software
73 …path with specific input values and verify the results | [TEST()](#simple-tests) | [Test Case][ist…
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
97 assertion level and building up to tests and test suites.
145 ## Simple Tests
167 and its individual name. Tests from different test suites can have the same
179 // Tests factorial of 0.
184 // Tests factorial of positive numbers.
193 GoogleTest groups the test results by test suites, so logically related tests
195 `TEST()` should be the same. In the above example, we have two tests,
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}
207 If you find yourself writing two or more tests that operate on similar data, you
209 objects for several different tests.
224 5. If needed, define subroutines for your tests to share.
240 that can handle both types of tests. Using the wrong macro causes a compiler
250 different tests in the same test suite have different test fixture objects, and
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.
255 As an example, let's write tests for a FIFO queue class named `Queue`, which has
295 Now we'll write tests using `TEST_F()` and this fixture.
327 When these tests run, the following happens:
337 ## Invoking the Tests
339 `TEST()` and `TEST_F()` implicitly register their tests with GoogleTest. So,
341 your defined tests in order to run them.
343 After defining your tests, you can run them with `RUN_ALL_TESTS()`, which
344 returns `0` if all the tests are successful, or `1` otherwise. Note that
345 `RUN_ALL_TESTS()` runs *all tests* in your link unit--they can be from different
364 * Repeats the above steps for the next test, until all tests have run.
377 > [death tests](advanced.md#death-tests)) and thus is not supported.
386 should only apply when you need to do something custom before the tests run that
430 // Class members declared here can be used by all tests in the test suite
434 // Tests that the Foo::Bar() method does Abc.
442 // Tests that Foo does Xyz.
479 other systems (e.g. Windows). In most tests this is not an issue as usually