]>
Commit | Line | Data |
---|---|---|
7c673cae FG |
1 | [/ |
2 | / Copyright (c) 2003 Boost.Test contributors | |
3 | / | |
4 | / Distributed under the Boost Software License, Version 1.0. (See accompanying | |
5 | / file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt) | |
6 | /] | |
7 | ||
8 | [section:design_rationale Design rationale] | |
9 | ||
10 | Unit testing tasks arise during many different stages of software development: from initial project | |
11 | implementation to its maintenance and later revisions. These tasks differ in their complexity and purpose | |
12 | and accordingly are approached differently by different developers. The wide spectrum of tasks in a problem | |
13 | domain cause many requirements (sometimes conflicting) to be placed on a unit testing framework. These | |
14 | include: | |
15 | ||
16 | * Writing a [link ref_test_module unit test module] should be simple and obvious for new users. | |
17 | * The framework should allow advanced users to perform non-trivial tests. | |
18 | * Test module should be able to have many small test cases and developer should be able to group them into | |
19 | test suites. | |
20 | * At the beginning of the development users want to see verbose and descriptive error messages. | |
21 | * During the regression testing users just want to know if any tests failed. | |
22 | * For small test modules, their execution time should prevail over compilation time: user don't want to wait a minute | |
23 | to compile a test that takes a second to run. | |
24 | * For long and complex tests users want to be able to see the testing progress. | |
25 | * Simplest tests shouldn't require an external library. | |
26 | * For long term usage users of the __UTF__ should be able to build it as a standalone library. | |
27 | ||
28 | The __UTF__ satisfies the requirements above, and provides versatile facilities to: | |
29 | ||
30 | * Easily specify all the expectations in the code being tested. | |
31 | * Organize these expectations into [link test_case test cases] and [link test_suite test suites]. | |
32 | * Detect different kinds of errors, failures, time-outs and report them in a uniform customizable way. | |
33 | ||
34 | [h4:why_framework Why do you need a framework?] | |
35 | ||
36 | While you can write a testing program yourself from scratch, the framework offers the following benefits: | |
37 | ||
38 | * You get an error report in a text format. Error reports are uniform and you can easily machine-analyze them. | |
39 | * Error reporting is separated from the testing code. You can easily change the error report format without affecting the testing code. | |
40 | * The framework automatically detects exceptions thrown by the tested components and time-outs, and reports them along other errors. | |
41 | * You can easily filter the test cases, and call only the desired ones. This does not require changing the testing code. | |
42 | ||
43 | [endsect][/ design_rationale] | |
44 | ||
45 | [section:how_to_read How to read this documentation] | |
46 | ||
47 | This documentation is structured by what *you*, as a user, need to know to successfully use the __UTF__ and the order of decisions | |
48 | you have to make and order of complexity of the problems you might encounter. If you ever find yourself facing with some unclear | |
49 | term feel free to jump directly to the [link boost_test.section_glossary glossary] section, where short definitions for all used | |
50 | terms were collected. | |
51 | ||
52 | Typically, when writing a test module using the __UTF__ you have to go through the following steps: | |
53 | ||
54 | * You decide how you want to incorporate the __UTF__: `#include` it as a header-only library, or link with it as a static library, | |
55 | or use it as a shared (or dynamically loaded) library. For details on this topic see section [link boost_test.usage_variants Usage variants]. | |
56 | * You add a [link test_case test case] into a [link ref_test_tree test tree]. | |
57 | For details, see section [link boost_test.tests_organization.test_cases Test cases]. | |
58 | * You perform correctness checks of the code under tested. For details, see section [link boost_test.testing_tools Writing unit tests]. | |
59 | * You perform the initialization of code under test before each test case. | |
60 | For details, see section [link boost_test.tests_organization.fixtures Fixtures]. | |
61 | * You might want to customize the way test failures are reported. For details, see section [link boost_test.test_output Controlling output]. | |
62 | * You can control the run-time behavior of the built test module (e.g., run only selected tests, change the output format). | |
63 | This is covered in section [link boost_test.runtime_config Runtime configuration]. | |
64 | ||
65 | If you can't find answer to your question in any of the section mentioned above or if you believe you need even more configuration options, | |
66 | you can check [link boost_test.adv_scenarios Advanced usage scenarios] section. | |
67 | ||
68 | [endsect][/ how_to_read] | |
69 | ||
70 | [/ EOF] |