]> git.proxmox.com Git - ceph.git/blame - ceph/src/boost/libs/test/doc/tutorials/hello_world.qbk
bump version to 12.2.2-pve1
[ceph.git] / ceph / src / boost / libs / test / doc / tutorials / hello_world.qbk
CommitLineData
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:hello A testing framework, what for?]
9How should a test program report errors? Displaying an error message is an obvious possibility:
10
11[/snippet9 deleted]
12``
13if( something_bad_detected )
14 std::cout << "something bad has been detected" << std::endl;
15``
16
17But that requires inspection of the program's output after each run to determine if an error occurred. Since test
18programs are often run as part of a regression test suite, human inspection of output to detect error messages is time
19consuming and unreliable. Test frameworks like GNU/expect can do the inspections automatically, but are overly complex
20for simple testing.
21
22A better simple way to report errors is for the test program to return `EXIT_SUCCESS` (normally 0) if the test program
23completes satisfactorily, and `EXIT_FAILURE` if an error is detected. This allows a simple regression test script to
24automatically and unambiguously detect success or failure. Further appropriate actions such as creating an HTML table or
25emailing an alert can be taken by the script, and can be modified as desired without having to change the actual C++
26test programs.
27
28A testing protocol based on a policy of test programs returning `EXIT_SUCCESS` or `EXIT_FAILURE` does not require any
29supporting tools; the C++ language and standard library are sufficient. The programmer must remember, however, to catch
30all exceptions and convert them to program exits with non-zero return codes. The programmer must also remember to not
31use the standard library `assert()` macro for test code, because on some systems it results in undesirable side effects
32like a message requiring manual intervention.
33
34The Boost Test Library's Unit Test Framework is designed to automate those tasks. The library supplied `main()` relieves
35users from messy error detection and reporting duties. Users could use supplied testing tools to perform complex
36validation tasks. Let's take a look on the following simple test program:
37
38
39``
40#include <my_class.hpp>
41
42int main( int, char* [] )
43{
44 my_class test_object( "qwerty" );
45 return test_object.is_valid() ? EXIT_SUCCESS : EXIT_FAILURE;
46}
47``
48
49There are several issues with above test.
50
51# You need to convert `is_valid` result in proper result code.
52# Would exception happen in test_object construction of method `is_valid` invocation, the program will crash.
53# You won't see any output, would you run this test manually.
54
55The __UTF__ solves all these issues. To integrate with it above program needs to be changed to:
56
57``
58#include <my_class.hpp>
59#define __BOOST_TEST_MODULE__ MyTest
60#include <boost/test/unit_test.hpp>
61
62__BOOST_AUTO_TEST_CASE__( my_test )
63{
64 my_class test_object( "qwerty" );
65 BOOST_TEST( test_object.is_valid() );
66}
67``
68
69Now, you not only receive uniform result code, even in case of exception, but also nicely formatted output from
70__BOOST_TEST__ tool, would you choose to see it. Is there any other ways to perform checks? The following example test
71program shows several different ways to detect and report an error in the `add()` function.
72
73[import ../snippet/snippet12.cpp]
74[snippet12]
75
76
77[endsect] [/section:hello]