ceph/src/boost/libs/test/doc/closing_chapters/glossary.qbk

   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:section_glossary Glossary]
   9
  10 Here is the list of terms used throughout this documentation.
  11
  12 [#ref_test_module][h3 Test module]
  13 This is a single binary that performs the test. Physically a test module consists of one or more test source files,
  14 which can be built into an executable or a dynamic library. A test module that consists of a single test source
  15 file is called ['single-file test module]. Otherwise
  16 it's called ['multi-file test module]. Logically, each test module consists of four parts:
  17
  18 # [link test_setup test setup] (or test initialization),
  19 # [link test_body test body]
  20 # [link test_cleanup test cleanup]
  21 # [link test_runner test runner]
  22
  23 The test runner part is optional. If a test module is built as
  24 an executable, the test runner is built-in. If a test module is built as a dynamic library, it is run by an
  25 [link boost_test.adv_scenarios.external_test_runner external test runner].
  26
  27
  28 [#test_body][h3 Test body]
  29 This is the part of a test module that actually performs the test.
  30 Logically test body is a collection of [link test_assertion test assertions] wrapped in
  31 [link test_case test cases], which are organized in a [link ref_test_tree test tree].
  32
  33 [#ref_test_tree][h3 Test tree]
  34 This is a hierarchical structure of [link test_suite test suites] (non-leaf nodes) and
  35 [link test_case test cases] (leaf nodes). More details can be found [link boost_test.tests_organization here].
  36
  37 [#ref_test_unit][h3 Test unit]
  38 This is a collective name when referred to either a [link test_suite test suite] or
  39 [link test_case test cases]. See [link boost_test.tests_organization this section] for more details.
  40
  41 [#test_assertion][h3 Test assertion]
  42 This is a single binary condition (binary in a sense that is has two outcomes: pass and fail) checked
  43 by a test module.
  44
  45 There are different schools of thought on how many test assertions a test case should consist of. Two polar
  46 positions are the one advocated by TDD followers - one assertion per test case; and opposite of this - all test
  47 assertions within single test case - advocated by those only interested in the first error in a
  48 test module. The __UTF__ supports both approaches.
  49
  50 [#test_case][h3 Test case]
  51 This is an independently monitored function within a test module that
  52 consists of one or more test assertions. The term ['independently monitored] in the definition above is
  53 used to emphasize the fact, that all test cases are monitored independently. An uncaught exception or other normal
  54 test case execution termination doesn't cause the testing to cease. Instead the error is caught by the test
  55 case execution monitor, reported by the __UTF__ and testing proceeds to the next test case. Later on you are going
  56 to see that this is on of the primary reasons to prefer multiple small test cases to a single big test function.
  57
  58
  59 [#test_suite][h3 Test suite]
  60 This is a container for one or more test cases. The test suite gives you an ability to group
  61 test cases into a single referable entity. There are various reasons why you may opt to do so, including:
  62
  63 * To group test cases per subsystems of the unit being tested.
  64 * To share test case setup/cleanup code.
  65 * To run selected group of test cases only.
  66 * To see test report split by groups of test cases.
  67 * To skip groups of test cases based on the result of another test unit in a test tree.
  68
  69 A test suite can also contain other test suites, thus allowing a hierarchical test tree structure to be formed.
  70 The __UTF__ requires the test tree to contain at least one test suite with at least one test case. The top level
  71 test suite - root node of the test tree - is called the master test suite.
  72
  73
  74
  75 [#test_setup][h3 Test setup]
  76 This is the part of a test module that is responsible for the test
  77 preparation. It includes the following operations that take place prior to a start of the test:
  78
  79 * The __UTF__ initialization
  80 * Test tree construction
  81 * Global test module setup code
  82 * ['Per test case] setup code, invoked for every test case it's assigned to, is also attributed to the
  83   test initialization, even though it's executed as a part of the test case.
  84
  85 [#test_cleanup][h3 Test cleanup]
  86 This is the part of test module that is responsible for cleanup operations.
  87
  88 [#test_fixture][h3 Test fixture]
  89 Matching setup and cleanup operations are frequently united into a single entity called test fixture.
  90
  91 [#test_runner][h3 Test runner]
  92 This is an ['orchestrator] or a ['driver] that, given the test tree, ensures the test tree is initialized, tests are executed and necessary reports generated. For more information [link boost_test.adv_scenarios.test_module_runner_overview see here].
  93
  94 [#test_log][h3 Test log]
  95 This is the record of all events that occur during the testing.
  96
  97 [#test_report][h3 Test report]
  98 This is the report produced by the __UTF__ after the testing is completed, that indicates which test cases/test
  99 suites passed and which failed.
 100
 101
 102 [endsect] [/ Glossary]