Boost logo

Boost Test Library: examples and tests

Home
Examples

Program Execution Monitor example
Test Execution Monitor example
Unit Test Framework example 1
Unit Test Framework example 2
Unit Test Framework example 3
Unit Test Framework example 4
Unit Test Framework example 5

Tests

The Program Execution Monitor test 1
The Program Execution Monitor test 2
The Program Execution Monitor test 3
The Test Execution Monitor test 1
The Test Execution Monitor test 2
The Test Execution Monitor test 3
The Test Execution Monitor test 4
The Test Tools Test
The Unit Test Framework online test
The Unit Test Framework output test stream test
The Unit Test Framework result report test
The Unit Test Framework extension test
The Unit Test Framework errors handling test
The Unit Test Framework automated registration feature test
The Minimal Testing facility unit test
The test for creating and using parameterized test cases
The floating point comparisons test

Examples

The following list provides cumulative summary information on all Boost Test Library examples. Summary contains rationale section describing the main purpose of an example. Input section describe what input is required for the example. Output section presents expected output from the example program run with the input specified in input section. To compile all example programs you could use Jamfile supplied in examples directory.

1. The Program Execution Monitor example

Rationale: to demonstrate that the only change you need to start using program execution monitor is the name of your main function
Input: This example does not require any input
Output: no errors expected
Source: prg_exec_example.cpp
reference to the top

2. The Test Execution Monitor example

Rationale: demonstrate how to write test programs using test execution monitor and six ways to detect and report the same error
Input: This example does not require any input
Output: *** No errors expected
Source: test_exec_example.cpp
reference to the top

3. The Unit Test Framework example 1

Rationale: this simple introductory example demonstrate several basic concepts of unit test framework:
  • usage of init_unit_test_framework to create and initialize test suite
  • test case creation based on free function
  • usage of basic test tools in test case
  • usage of "number of expected failures" feature
Input: This example does not require any input
Output: Running 1 test case...
.../unit_test_example1.cpp(17): error in "free_test_function": test 2 == 1 failed

*** No errors detected
Source: unit_test_example1.cpp
reference to the top

4. The Unit Test Framework example 2

Rationale: to demonstrate
  • an ability to construct multi-test case test suites
  • an ability of unit test framework to catch system level errors like floating point exceptions or dead loop.
  • usage of BOOST_CHECKPOINT test tool to mark exception risky places
Input: This example does not require any input
Output: The output depends on whether or not your system support setting test case timeout. For Win32 it will look like this:
Running 2 test case...
Exception in "force_division_by_zero": integer divide by zero
.../unit_test_example2.cpp(16) : last checkpoint: About to force division by zero!

*** errors detected in test suite "Unit test example 2"; see standard output for details
Source: unit_test_example2.cpp
reference to the top

5. The Unit Test Framework example 3

Rationale: to demonstrate
  • an ability to construct multi-level hierarchy of test suites
  • an ability to construct test cases based on user class's member function
  • an ability to fail test suite initialization.
  • usage of several different kinds of Test Tools
  • usage of floating point comparison algorithm
Input: This example require initial balance as a command line argument. Also during run it query deposit value. You may use 10 and 5 to get an output below.
Output: With the input described above the output looks like:
Running 3 test case...
.../unit_test_example3.cpp(63): error in "account_test::test_init": test m_account.balance() == 5.0 failed [10 != 5]
Enter deposit value:
5
.../unit_test_example3.cpp(87): fatal error in "account_test::test_deposit": test m_account.balance() >= 100.0 failed

*** 2 failures detected (5 failures expected) in test suite "Unit test example 3"
Source: unit_test_example3.cpp
reference to the top

6. The Unit Test Framework example 4

Rationale: to demonstrate how to construct parameterized test case based on free function test case and where to store the parameters
Input: This example does not require any input
Output: The output depends on whether or not your system support setting test case timeout. For Win32 it will look like this:
Running 1 test case...
.../unit_test_example4.cpp(20): error in "check_string": test s.substr( 0, 3 ) == "hdr" failed [3 != hdr]

*** No errors detected
Source: unit_test_example4.cpp
reference to the top

7. The Unit Test Framework example 5

Rationale: this moderately complex example presents test program for the family of trivial hash functions. On the way among other things it demonstrates:
  • an ability to construct parameterized test cases based on user class's member function
  • usage of shared instance of user test case
  • ability to store test case parameters in user test case
Input: This example not require input in a following format:
alphabet
string hash-value
string hash-value
...

hash-value is positive integer. hash-value -1 designate expected "wrong length" error.
hash-value -2 designate expected "non-alphabet letter in string" error. Here is an example input:
unit_test_example5.input
Output: If you use supplied input like this: unit_test_example5 < unit_test_example5.input, you will get:
Enter alphabet (4 characters without delimiters)

Enter test data in a format [string] [value] to check correct calculation
Enter test data in a format [string] -1 to check long string validation
Enter test data in a format [string] -2 to check invalid argument string validation

Running 1 test case...

*** No errors detected
Source: unit_test_example5.cpp
reference to the top

Tests

The following list provides cumulative summary information on all Boost Test Library tests. Summary consist of the following parts:

Rationale intent of the test
Type type of the test:
  • run-time - should succeed at run time
  • run-time-failure - should fail at run time
  • compile-time - should succeed to compile and link
Component needed Component of the Boost Test Library this test need to be linked with
Need Test Pattern yes/no depends on whether this test require pattern file name ass first command line argument. Pattern files are located in test directory along with test source file. Click on 'yes' and you will see it.
Expected Output expected output produced by test during run.
Result Code result code returned by the test
Source Link to the test source file.

To compile all test programs you could use Jamfile supplied in test directory.

reference to the top

1. The Program Execution Monitor test 1

Rationale: intended to check an ability of the Program Execution Monitor to catch a user exception
Type: run-time-failure
Component needed: the Program Execution Monitor
Need Test Pattern: no
Expected Output:
*** Error: C string: Test error by throwing C-style string exception

**** error return code 205
********** errors detected; see standard output for details ***********
Result Code: 205
Source: prg_exec_fail1.cpp
reference to the top

2. The Program Execution Monitor test 2

Rationale: intended to check an ability of the Program Execution Monitor to catch a system exception
Type: run-time-failure
Component needed: the Program Execution Monitor
Need Test Pattern: no
Expected Output:
*** Error: integer divide by zero

**** error return code 210
********** errors detected; see standard output for details ***********
Result Code: 205
Source: prg_exec_fail2.cpp
reference to the top

3. The Program Execution Monitor test 3

Rationale: intended to check an ability of the Program Execution Monitor to gracefully catch an asserts fired by the user
Type: run-time-failure
Component needed: the Program Execution Monitor
Need Test Pattern: no
Expected Output: Assertion failed: div != 0, file d:\source code\boost\libs\test\test\prg_exec_fail3.cpp, line 23

**** Error:

abnormal program termination


**** error return code 210
********** errors detected; see standard output for details ***********
Result Code: 210
Source: prg_exec_fail3.cpp
reference to the top

4. The Test Execution Monitor test 1

Rationale: intended to check an ability of the Test Execution Monitor to catch non-zero return code from test_main
Type: run-time-failure
Component needed: the Test Execution Monitor
Need Test Pattern: no
Expected Output: .../test_main.cpp(40): error in "call_test_main": test test_main_result == 0 || test_main_result == boost::exit_success failed

*** 1 failure detected in test case "call_test_main"
Result Code: 1
Source: test_exec_fail1.cpp
reference to the top

5. The Test Execution Monitor test 2

Rationale: intended to check an ability of the Test Execution Monitor to catch and report test errors using the Test Tools
Type: run-time-failure
Component needed: the Test Execution Monitor
Need Test Pattern: no
Expected Output: .../test_exec_fail2.cpp(25): error in "call_test_main": test v == 2 failed
.../test_exec_fail2.cpp(26): error in "call_test_main": sample BOOST_ERROR call
.../test_exec_fail2.cpp(27): fatal error in "call_test_main": test 2 == v failed

*** 3 failures detected in test case "call_test_main"
Result Code: 201
Source: test_exec_fail2.cpp
reference to the top

6. The Test Execution Monitor test 3

Rationale: intended to check an ability of the Test Execution Monitor to report test failures generated by BOOST_CHECK
Type: run-time-failure
Component needed: the Test Execution Monitor
Need Test Pattern: no
Expected Output: .../test_exec_fail3.cpp(24): error in "call_test_main": test v == 2 failed
.../test_exec_fail3.cpp(25): error in "call_test_main": test 2 == v failed

*** 2 failures detected in test case "call_test_main"
Result Code: 201
Source: test_exec_fail3.cpp
reference to the top

7. The Test Execution Monitor test 4

Rationale: intended to check an ability of the Test Execution Monitor to catch and report exceptions in tests
Type: run-time-failure
Component needed: the Test Execution Monitor
Need Test Pattern: no
Expected Output: .../test_exec_fail4.cpp(23): error in "call_test_main": Msg
Exception in "call_test_main": C string: Test error by throwing C-style string exception

*** 1 failure detected in test case "call_test_main"
Test case "call_test_main" was aborted due to uncaught exception, user assert or system error
Result Code: 201
Source: test_exec_fail4.cpp
reference to the top

8. The Test Tools test

Rationale: detailed self test for the Test Tools. Intended to check that every test tool is working properly, i.e. catch what is supposed to catch and report the way it is supposed to report. Due to self test nature the result code will always be non zero. The presence of errors is detected by presence of lines with errors
Type: run-time
Component needed: the Unit Test Framework
Need Test Pattern: no
Expected Output: Running 17 test cases...

*** No errors detected
Result Code: 0
Source: test_tools_test.cpp
reference to the top

9. The Unit Test Framework online test

Rationale: intended to demonstrate how to use the included version of the Program Execution Monitor (vs. linked as a separate library). It's compile-time check. Once compiled and linked it passed.
Type: compile-time
Component needed: none
Need Test Pattern: no
Expected Output: *** No errors detected
Result Code: 0
Source: online_test.cpp
reference to the top

10. The Unit Test Framework output test stream test

Rationale: detailed self test for output_test_stream Test Tool. Validate that all test mechanisms working properly. Include 5 test cases: test_constructor, test_is_empty, test_check_length, test_is_equal, test_match_pattern.
Type: run-time
Component needed: the Unit Test Framework
Need Test Pattern: no, but will generate 2 files automatically.
Expected Output: Running 5 test cases...

*** No errors detected
Result Code: 0
Source: output_test_stream_test.cpp
reference to the top

11. The Unit Test Framework result report test

Rationale: the Unit Test Framework reporting facilities testing. Check that all reports (short, conformation, detailed) are constructed as expected. To do this output is matched vs. pattern file. The pattern file result_report_test.pattern is located in test directory. It's name should be supplied as a first argument to program. To run test in a match mode (default) you does not need to provide any more arguments. To run test in save mode (this way you could generate pattern file) run test with the additional argument: --save_pattern=yes.
Type: run-time
Component needed: the Test Execution Monitor
Need Test Pattern: yes
Expected Output:
*** No errors detected
Result Code: 0
Source: result_report_test.cpp
reference to the top

12. The Unit Test Framework extension test

Rationale: intend to perform test functionality presented in a header unit_test_suite_ex.hpp
Type: run-time
Component needed: the Unit Test Framework
Need Test Pattern: no
Expected Output: Running 2 test cases...

*** No errors detected
Result Code: 0
Source: unit_test_suite_ex_test.cpp
reference to the top

13. The Unit Test Framework errors handling test

Rationale: intended to test that the Unit Test Framework properly handle different errors during different stages of testing. Testing output is matched the pattern file. The pattern file is located in test directory. To run test in a match mode (default) you does not need to provide any more arguments. To run test in save mode (this way you could generate pattern file) run test with the additional argument: --save_pattern=yes.
Type: run-time
Component needed: the Test Execution Monitor
Need Test Pattern: yes
Expected Output:
*** No errors detected
Result Code: 0
Source: errors_handling_test.cpp
reference to the top

14. The Unit Test Framework automated registration feature test

Rationale: intended to demonstrate and test automated registration of test cases feature of the Unit Test Framework. It's compile-time check. Once compiled and linked it passed.
Type: compile-time
Component needed: the Unit Test Framework
Need Test Pattern: no
Expected Output: *** No errors detected
Result Code: 0
Source: auto_unit_test_test.cpp
reference to the top

15. The Minimal Testing facility unit test

Rationale: intend to perform the detailed test and demonstrate usage of the minimal testing facility
Type: run-time-failure
Component needed: none
Need Test Pattern: no
Expected Output: .../minimal_test.cpp(56): test i == 2 failed
.../minimal_test.cpp(59): test bool_convertible1( false ) failed
.../minimal_test.cpp(62): test bool_convertible2( 0 ) failed
.../minimal_test.cpp(65): test bool_convertible3( NULL ) failed
.../minimal_test.cpp(67): Some error
.../minimal_test.cpp(69): test i == 4 failed

**** Testing aborted.
**** 6 errors detected
Result Code: 201
Source: minimal_test.cpp
reference to the top

16. The test for creating and using parameterized test cases

Rationale: test creation and usage of all kinds of parameterized test cases
Type: run-time
Component needed: the Test Execution Monitor
Need Test Pattern: no
Expected Output: *** No errors detected
Result Code: 0
Source: parameterized_test_test.cpp
reference to the top

17. The floating point comparisons test

Rationale: test floating point comparisons algorithms and tools. For some reason failing at the moment.
Type: run-time
Component needed: the Unit Test Framework
Need Test Pattern: no
Expected Output: Output differ depends on compiler
Result Code: 0
Source: test_fp_comparisons.cpp