Home > Minimal testing facility
PrevNext

Part III. Boost Test Library: The minimal testing facility

Introduction

Boost.Test minimal testing facility provides the functionality previously implemented by the original version of Boost.Test. As the name suggest, it provides only minimal basic facilities for test creation. It have no configuration parameters (either command line arguments or environment variables) and it supplies a limited set of testing tools which behaves similarly to ones defined amount the Unit Test Framework Testing tools. The minimal testing facility supplies its own function main() (so can not be used for multi unit testing) and will execute the test program in a monitored environment.
Boost.Test 最小化測試設施提供 Boost.Test 之前版本實現的函數。 就像名字說明的,它只提供用於創建測試的最小基本工具。沒有配置參數 (無論是命令行參數還是環境變量),並且提供測試工具 (testing tools) 的有限集合,其行為同單元測試框架 (Unit Test Framework) 中的行為相似。 最小化測試設施提供了自己的 main() 函數 (所以不能應用於多個單元測試),並且將在被監控環境下執行測試程序。

As it follows from the name this component provides only minimal set of the testing capabilities and as a general rule the Unit Test Framework should be preferred. In a majority of the cases it provides you with much wider set of testing tools (and other goods), while still being as easy to set up.
就像名字顯示的,這個組件只提供最基本的測試能力集合,並且一般情況下 Unit Test Framework 會更合適。 在大多數情況下,它提供更廣泛 (和更好) 的測試工具,同時更容易使用。

Usage

The only change (other then including boost/test/minimal.hpp) you need to make, to integrate your test module with minimal testing facility is the signature of your function main(). It should look like this:
你想要將測試模塊集成最小化測試設施,唯一的變化 (除了包含 boost/test/minimal.hpp) 是 main() 函數的簽名。這看起來是這樣的:

int test_main( int argc, char* argv[] )
{
  ...
}

Once you apply the change test automatically starts running in monitored environment. Also you can start using testing tools provided by the minimal testing facility and get uniform errors reporting.
如果你做了這個變化,測試會自動在被監控環境下開始。 同樣你可以使用最小化測試設施提供的測試工具 (testing tools) 並提供統一的錯誤報告。

Example

Following example illustrates different approaches you can employ to detect and report errors using different testing tools
下面的示例展示了用不同的測試工具來檢測和報告錯誤

Example 4. Minimal testing facility application

#include <boost/test/minimal.hpp>

//____________________________________________________________________________//

int add( int i, int j ) { return i+j; }

//____________________________________________________________________________//

int test_main( int, char *[] )             // note the name!
{
    // six ways to detect and report the same error:
    BOOST_CHECK( add( 2,2 ) == 4 );        // #1 continues on error
    BOOST_REQUIRE( add( 2,2 ) == 4 );      // #2 throws on error
    if( add( 2,2 ) != 4 )
        BOOST_ERROR( "Ouch..." );          // #3 continues on error
    if( add( 2,2 ) != 4 )
        BOOST_FAIL( "Ouch..." );           // #4 throws on error
    if( add( 2,2 ) != 4 ) throw "Oops..."; // #5 throws on error

    return add( 2, 2 ) == 4 ? 0 : 1;       // #6 returns error code
}

//____________________________________________________________________________//
Source code | Show annotations | Show output

(1)

This approach uses the BOOST_CHECK tool, which displays an error message on std::cout that includes the expression that failed, the source file name, and the source file line number. It also increments the error count. At program termination, the error count will be displayed automatically by the minimal testing facility.
使用 BOOST_CHECK 工具,會在 std::cout 上顯示包含失敗表達式、源文件名和源文件行號的錯誤信息。 它同樣增加錯誤數量。在程序結束時,錯誤數量會被最小化測試設施自動顯示。

(2)

This approach using the BOOST_REQUIRE tool, is similar to #1, except that after displaying the error, an exception is thrown, to be caught by the minimal testing facility. This approach is suitable when writing an explicit test program, and the error would be so severe as to make further testing impractical. BOOST_REQUIRE differs from the C++ Standard Library's assert() macro in that it is always generated, and channels error detection into the uniform reporting procedure.
使用 BOOST_REQUIRE 工具,和 #1 類似,除了在顯示錯誤後會拋出一個異常,被最小化測試設施捕獲。 這在寫測試程序,並且並錯誤發生時後面的測試不再有意義時適用。 BOOST_REQUIRE 和 C++ 標準庫的 assert() 宏不同,它總是被生成,並且將檢測到的錯誤放到統一的報告過程中。

(3)

This approach is similar to #1, except that the error detection is coded separately. This is most useful when the specific condition being tested is not indicative of the reason for failure.
和 #1 類似,除了錯誤檢查是被單獨編碼的。當被檢查的測試不是特定情況下失敗的原因時是最有用的。

(4)

This approach is similar to #2, except that the error detection is coded separately. This is most useful when the specific condition being tested is not indicative of the reason for failure.
和 #2 類似,除了錯誤檢查是被單獨編碼的。當被檢查的測試不是特定情況下失敗的原因時是最有用的。

(5)

This approach throws an exception, which will be caught and reported by the minimal testing facility. This approach is suitable for both production and test code, in libraries or not. The error message displayed when the exception is caught will be most meaningful if the exception is derived from std::exception , or is a char* or std::string.
這種情況下拋出一個異常,會被最小化測試設施捕獲並報告。 這個方法同時適用時工業級和測試級代碼,代碼庫中或不在庫中。 如果異常是派生自 std::exception 或 char* 或 std::string,當異常被捕獲時顯示的錯誤信息可能是最有意義的。

(6)

This approach uses the BOOST_CHECK_MESSAGE tool, is similar to approach #1, except that similar to the approach #3 displays an alternative error message specified as a second argument.
使用 BOOST_CHECK_MESSAGE 工具,類似於 #1,除了類似於 #3 接受一個錯誤信息作為第二個參數。

**** no errors detected

Provided testing tools

The minimal testing facility supplies following four tools:
最小化測試設施提供如下四個工具:

BOOST_CHECK(predicate)
BOOST_REQUIRE(predicate)
BOOST_ERROR(message)
BOOST_FAIL(message)

Their behavior is modeled after the similarly named tools implemented by the Unit Test Framework.
行為同 Unit Test Framework 中實現的類似名稱工具 (similarly named tools) 相同。

Implementation

The minimal testing facility is implemented inline in one header boost/test/minimal.hpp. There are no special compilation instructions for this component.
最小化測試設施整個內聯實現在頭文件 boost/test/minimal.hpp 中。這個組件沒有特別的編譯指令。

There is a single unit test program that validates minimal testing facility functionality: minimal_test
有一個單獨的單元測試程序用來驗證最小化測試設施的功能:minimal_test

Last revised: , at


PrevUpHomeNext