Home > The Unit Test Framework > User's guide > Test Output > Test log >

Test log output

The test log is produced during the test execution. All entries in the test log are assigned a particular log level. Only the entries with level that exceeds the active log level threshold actually appear in the test log output. Log levels are arranged by the "importance" of the log entries. Here is the list of all levels in order of increasing "importance":
測試日誌在測試執行過程中產生。測試日誌中所有條目被指定一個特定的日誌級別。 只有級別超過活動日誌級別閾值 (active log level threshold) 的條目才會實際出現在測試日誌輸出中。 日誌級別是由日誌條目的 "重要性" 安排的。 下面的列表是按照 "重要性" 遞增的順序排序的所有級別:

[Note] Note

The active log level works namely as threshold, not as selector. For the given active log level threshold, all test log entries with "importance" higher than threshold are enabled and all test log entries with "importance" below threshold are disabled.
活動日誌級別作為閾值工作,而不是選擇器。對於給定的活動日誌級別閾值,所有 "重要性" 高於閾值的日誌條目都被允許, 所有 "重要性" 低於閾值的都被禁止。

In addition to the levels described above the test log defines two special log levels. The current log level can be set to:

By default the active log level threshold is set to "non fatal error messages" and the test log output is generated in the human readable format. The active log level threshold and the output format can be configured at runtime during a test module invocation and at compile time from within a test module using the test log public interfaces. For example, for automated test module output processing it might be more convenient to use the XML based format.
活動日誌級別閾值默認被設置為 "非致命錯誤信息",並且測試日誌以可讀格式輸出。 活動日誌級別閾值和輸出格式可以在測試模塊調用過程運行過程中配置,或者在測試模塊編譯過程中使用測試日誌公共接口配置。 例如,對於自動的測試模塊輸出過程,基於 XML 格式的輸出可能更方便一些。

In most cases The UTF can't provide an exact location, where system error occurs or uncaught C++ exception is thrown from. To be able to pinpoint it as close as possible the UTF keeps track of checkpoints - the location a test module passed through. A test case entrance and exit points, a test tool invocation point the UTF tracks automatically. Any other checkpoints should be entered by you manually. The test log provides two macros for this purpose: BOOST_TEST_CHECKPOINT - to specify a "named" checkpoint and BOOST_TEST_PASSPOINT - to specify an "unnamed" checkpoint.
在大多數情況下,發生系統錯誤或未捕獲的 C++ 異常時,UTF 並不能提供準確的位置。 為了盡可能近地定位這點,UTF 保留了檢查點的軌跡 - 測試模塊經過的位置。 UTF 自動記錄測試用例的入口和出口點,測試工具調用點。其它檢查點需要你手動記錄。 為了這個目的,測試日誌提供了兩個宏: BOOST_TEST_CHECKPOINT - 定義 "命名的" 檢查點, 和 BOOST_TEST_PASSPOINT - 定義 "無名的" 檢查點。

Logging tool arguments

Most of the testing tools print values of their arguments to the output stream in some form of log statement. If arguments type does not support operator<<(std::ostream&, ArgumentType const&) interface you will get a compilation error. You can either implement above interface or prohibit the testing tools from logging argument values for specified type. To do so use following statement on file level before first test case that includes statement failing to compile:
大多數測試工具將它們的參數以某種日誌格式打印到輸出流中。 如果參數類型不支持 operator<<(std::ostream&, ArgumentType const&) 接口,你會得到編譯錯誤。 你可以實現上面的接口,或者阻止測試工具對特定類型的參數值作日誌。 想要這麼做,在包含不能編譯語句的第一個測試用例之前,在文件級別使用如下語句:



Try to comment out BOOST_TEST_DONT_PRINT_LOG_VALUE statement and you end up with compile time error.

#define BOOST_TEST_MODULE example
#include <boost/test/included/unit_test.hpp>
#include <utility>


typedef std::pair<int,float> pair_type;


    pair_type p1( 2, 5.5 );
    pair_type p2( 2, 5.501 );

    BOOST_CHECK_EQUAL( p1, p2 );

Source code | Show output
Running 1 test case...
test.cpp(16): error in "test_list": check p1 == p2 failed [ != ]

*** 1 failure detected in test suite "example"

Runtime configuration

The active log level threshold can be configured at runtime using the parameter log_level. The test log output format can be selected using either parameter log_format or the parameter output_format.
活動日誌級別閾值可以在運行時使用參數 log_level 配置。 測試日誌輸出格式可以使用參數 log_formatoutput-format 選擇。