復雜的 C/C++ 代碼中很可能有 bug，到代碼編寫(xiě)完成之后再來(lái)測試就像大海撈針。比較謹慎的辦法是，在編寫(xiě)各個(gè)代碼段時(shí)，針對特定的區域（例如，一些包含大量計算的 C 函數或聲明隊列等數據結構的 C++ 類(lèi)），添加專(zhuān)門(mén)的小測試（單元測試），以在編寫(xiě)代碼的同時(shí)進(jìn)行測試。按這種方式構建的回歸測試套件包含一套單元測試和一個(gè)測試驅動(dòng)程序，這個(gè)程序運行測試并報告結果。
對于文本編輯器這樣復雜的代碼，外部測試者無(wú)法生成針對特定例程的測試 — 測試者不太了解內部代碼組織。Boost 的優(yōu)勢就在于白箱測試 ：由開(kāi)發(fā)人員編寫(xiě)測試，對類(lèi)和函數進(jìn)行語(yǔ)義檢查。這個(gè)過(guò)程極其重要，因為代碼以后的維護者可能會(huì )破壞原來(lái)的邏輯，這時(shí)單元測試就會(huì )失敗。通過(guò)使用白箱測試，常常很容易找到出錯的地方，不必使用調試器。
請考慮 清單 1 中的簡(jiǎn)單字符串類(lèi)。這個(gè)類(lèi)并不健壯，我們使用 Boost 來(lái)測試它。
#ifndef _MYSTRING #define _MYSTRING class mystring { char* buffer; int length; public: void setbuffer(char* s) { buffer = s; length = strlen(s); } char& operator[ ] (const int index) { return buffer[index]; } int size( ) { return length; } }; #endif |
與字符串相關(guān)的一些典型的檢查，會(huì )驗證空字符串的長(cháng)度是否為 0，訪(fǎng)問(wèn)范圍超出索引是否導致錯誤消息或異常，等等。清單 2 給出了一些值得為任何字符串實(shí)現創(chuàng )建的測試。要想運行 清單 2 中的源代碼，只需用 g++（或任何符合標準的 C++ 編譯器）編譯它。注意，不需要單獨的主函數，代碼也不使用任何鏈接庫：作為 Boost 一部分的 unit_test.hpp 頭文件中包含所需的所有定義。
#define BOOST_TEST_MODULE stringtest #include <boost/test/included/unit_test.hpp> #include "./str.h" BOOST_AUTO_TEST_SUITE (stringtest) // name of the test suite is stringtest BOOST_AUTO_TEST_CASE (test1) { mystring s; BOOST_CHECK(s.size() == 0); } BOOST_AUTO_TEST_CASE (test2) { mystring s; s.setbuffer("hello world"); BOOST_REQUIRE_EQUAL ('h', s[0]); // basic test } BOOST_AUTO_TEST_SUITE_END( ) |
BOOST_AUTO_TEST_SUITE 和 BOOST_AUTO_TEST_SUITE_END 宏分別表示測試套件的開(kāi)頭和結尾。各個(gè)測試放在這兩個(gè)宏之間，從這一點(diǎn)來(lái)看，這些宏的語(yǔ)義很像 C++ 名稱(chēng)空間。每個(gè)單元測試用 BOOST_AUTO_TEST_CASE 宏來(lái)定義。清單 3 給出了 清單 2 中代碼的輸出。
[arpan@tintin] ./a.out Running 2 test cases... test.cpp(10): error in "test1": check s.size() == 0 failed *** 1 failure detected in test suite "stringtest" |
下面詳細討論如何創(chuàng )建前面清單中的單元測試?；舅枷胧鞘褂?Boost 提供的宏來(lái)測試各個(gè)類(lèi)特性。BOOST_CHECK 和 BOOST_REQUIRE_EQUAL 是 Boost 提供的預定義宏（也稱(chēng)為測試工具），用于驗證代碼輸出。
Boost 有一整套測試工具，基本上可以說(shuō)它們是用于驗證表達式的宏。測試工具的三個(gè)主要類(lèi)別是 BOOST_WARN、BOOST_CHECK 和 BOOST_REQUIRE。BOOST_CHECK 和 BOOST_REQUIRE 之間的差異在于：對于前者，即使斷言失敗，測試仍然繼續執行；而對于后者，認為這是嚴重的錯誤，測試會(huì )停止。清單 4 使用一個(gè)簡(jiǎn)單的 C++ 片段展示了這些工具類(lèi)別之間的差異。
#define BOOST_TEST_MODULE enumtest #include <boost/test/included/unit_test.hpp> BOOST_AUTO_TEST_SUITE (enum-test) BOOST_AUTO_TEST_CASE (test1) { typedef enum {red = 8, blue, green = 1, yellow, black } color; color c = green; BOOST_WARN(sizeof(green) > sizeof(char)); BOOST_CHECK(c == 2); BOOST_REQUIRE(yellow > red); BOOST_CHECK(black != 4); } BOOST_AUTO_TEST_SUITE_END( ) |
第一個(gè) BOOST_CHECK 會(huì )失敗，第一個(gè) BOOST_REQUIRE 也是如此。但是，當 BOOST_REQUIRE 失敗時(shí)，代碼退出，所以不會(huì )到達第二個(gè) BOOST_CHECK。清單 5 顯示了 清單 4 中代碼的輸出。
[arpan@tintin] ./a.out Running 1 test case... e2.cpp(11): error in "test1": check c == 2 failed e2.cpp(12): fatal error in "test1": critical check yellow > red failed *** 2 failures detected in test suite "enumtest" |
同樣，如果需要針對特定情況檢查某些函數或類(lèi)方法，最容易的方法是創(chuàng )建一個(gè)新測試，并使用參數和期望值調用這個(gè)例程。清單 6 提供了一個(gè)示例。
BOOST_AUTO_TEST(functionTest1) { BOOST_REQUIRE(myfunc1(99, ‘A’, 6.2) == 12); myClass o1(“hello world!\n”); BOOST_REQUIRE(o1.memoryNeeded( ) < 16); } |
經(jīng)常需要根據 “黃金日志” 測試函數生成的輸出。BOOST_CHECK 也適合執行這種測試，這還需要用到 Boost 庫的 output_test_stream 類(lèi)。用黃金日志文件（以下示例中的 run.log）初始化 output_test_stream。C/C++ 函數的輸出被提供給這個(gè) output_test_stream 對象，然后調用這個(gè)對象的 match_pattern 例程。清單 7 提供了詳細代碼。
#define BOOST_TEST_MODULE example #include <boost/test/included/unit_test.hpp> #include <boost/test/output_test_stream.hpp> using boost::test_tools::output_test_stream; BOOST_AUTO_TEST_SUITE ( test ) BOOST_AUTO_TEST_CASE( test ) { output_test_stream output( "run.log", true ); output << predefined_user_func( ); BOOST_CHECK( output.match_pattern() ); } BOOST_AUTO_TEST_SUITE_END( ) |
回歸測試中最棘手的檢查之一是浮點(diǎn)比較。請看一下 清單 8，看起來(lái)沒(méi)什么問(wèn)題 — 至少從表面看是這樣。
#define BOOST_TEST_MODULE floatingTest #include <boost/test/included/unit_test.hpp> #include <cmath> BOOST_AUTO_TEST_SUITE ( test ) BOOST_AUTO_TEST_CASE( test ) { float f1 = 567.0102; float result = sqrt(f1); // this could be my_sqrt; faster implementation // for some specific DSP like hardware BOOST_CHECK(f1 == result * result); } BOOST_AUTO_TEST_SUITE_END( ) |
運行這個(gè)測試時(shí)，盡管使用的是作為標準庫一部分提供的 sqrt 函數，BOOST_CHECK 宏仍然會(huì )失敗。什么地方出錯了？浮點(diǎn)比較的問(wèn)題在于精度 — f1 和 result*result 在小數點(diǎn)后面的幾位不一致。為了解決這個(gè)問(wèn)題，Boost 測試實(shí)用程序提供了 BOOST_WARN_CLOSE_FRACTION、BOOST_CHECK_CLOSE_FRACTION 和 BOOST_REQUIRE_CLOSE_FRACTION 宏。要想使用這三個(gè)宏，必須包含預定義的 Boost 頭文件 floating_point_comparison.hpp。這三個(gè)宏的語(yǔ)法是相同的，所以本文只討論 check 變體（見(jiàn) 清單 9）。
BOOST_CHECK_CLOSE_FRACTION (left-value, right-value, tolerance-limit); |
清單 9 中沒(méi)有使用 BOOST_CHECK，而是使用 BOOST_CHECK_CLOSE_FRACTION 并指定公差限制為 0.0001。清單 10 給出了代碼現在的樣子。
#define BOOST_TEST_MODULE floatingTest #include <boost/test/included/unit_test.hpp> #include <boost/test/floating_point_comparison.hpp> #include <cmath> BOOST_AUTO_TEST_SUITE ( test ) BOOST_AUTO_TEST_CASE( test ) { float f1 = 567.01012; float result = sqrt(f1); // this could be my_sqrt; faster implementation // for some specific DSP like hardware BOOST_CHECK_CLOSE_FRACTION (f1, result * result, 0.0001); } BOOST_AUTO_TEST_SUITE_END( ) |
這段代碼運行正?！，F在，把 清單 10 中的公差限制改為 0.0000001。清單 11 給出了輸出。
[arpan@tintin] ./a.out Running 1 test case... sq.cpp(18): error in "test": difference between f1{567.010132} and result * result{567.010193} exceeds 1e-07 *** 1 failure detected in test suite "floatingTest" |
生產(chǎn)軟件中另一個(gè)常見(jiàn)的問(wèn)題是比較 double 和 float 類(lèi)型的變量。BOOST_CHECK_CLOSE_FRACTION 的優(yōu)點(diǎn)是它不允許進(jìn)行這種比較。這個(gè)宏中的左值和右值必須是相同類(lèi)型的 — 即要么是 float，要么是 double。在 清單 12 中，如果 f1 是 double，而 result 是 float，在比較時(shí)就會(huì )出現錯誤。
[arpan@tintin] g++ sq.cpp -I/u/c/lib/boost /u/c/lib/boost/boost/test/test_tools.hpp: In function `bool boost::test_tools::tt_detail::check_frwd(Pred, const boost::unit_test::lazy_ostream&, boost::test_tools::const_string, size_t, boost::test_tools::tt_detail::tool_level, boost::test_tools::tt_detail::check_type, const Arg0&, const char*, const Arg1&, const char*, const Arg2&, const char*) [with Pred = boost::test_tools::check_is_close_t, Arg0 = double, Arg1 = float, Arg2 = boost::test_tools::fraction_tolerance_t<double>]': sq.cpp:18: instantiated from here /u/c/lib/boost/boost/test/test_tools.hpp:523: error: no match for call to `(boost::test_tools::check_is_close_t) (const double&, const float&, const boost::test_tools::fraction_tolerance_t<double>&)' |
Boost 測試工具驗證 Boolean 條件?？梢酝ㄟ^(guò)擴展測試工具支持更復雜的檢查 — 例如，判斷兩個(gè)列表的內容是否相同，或者某一條件對于向量的所有元素是否都是有效的。還可以通過(guò)擴展 BOOST_CHECK 宏執行定制的斷言檢查。下面對用戶(hù)定義的 C 函數生成的列表內容執行定制的檢查：檢查結果中的所有元素是否都大于 1。定制檢查函數需要返回 boost::test_tools::predicate_result 類(lèi)型。清單 13 給出了詳細的代碼。
#define BOOST_TEST_MODULE example #include <boost/test/included/unit_test.hpp> boost::test_tools::predicate_result validate_list(std::list<int>& L1) { std::list<int>::iterator it1 = L1.begin( ); for (; it1 != L1.end( ); ++it1) { if (*it1 <= 1) return false; } return true; } BOOST_AUTO_TEST_SUITE ( test ) BOOST_AUTO_TEST_CASE( test ) { std::list<int>& list1 = user_defined_func( ); BOOST_CHECK( validate_list(list1) ); } BOOST_AUTO_TEST_SUITE_END( ) |
predicate_result 對象有一個(gè)隱式的構造函數，它接受一個(gè) Boolean 值，因此即使 validate_list 的期望類(lèi)型和實(shí)際返回類(lèi)型不同，代碼仍然會(huì )正常運行。
還有另一種用 Boost 測試復雜斷言的方法：BOOST_CHECK_PREDICATE 宏。這個(gè)宏的優(yōu)點(diǎn)是它不使用 predicate_result。但缺點(diǎn)是語(yǔ)法有點(diǎn)兒粗糙。用戶(hù)需要向 BOOST_CHECK_PREDICATE 宏傳遞函數名和參數。清單 14 的功能與 清單 13 相同，但是使用的宏不同。注意，validate_result 的返回類(lèi)型現在是 Boolean。
#define BOOST_TEST_MODULE example #include <boost/test/included/unit_test.hpp> bool validate_list(std::list<int>& L1) { std::list<int>::iterator it1 = L1.begin( ); for (; it1 != L1.end( ); ++it1) { if (*it1 <= 1) return false; } return true; } BOOST_AUTO_TEST_SUITE ( test ) BOOST_AUTO_TEST_CASE( test ) { std::list<int>& list1 = user_defined_func( ); BOOST_CHECK_PREDICATE( validate_list, list1 ); } BOOST_AUTO_TEST_SUITE_END( ) |
可以在一個(gè)文件中包含多個(gè)測試套件。文件中定義的每個(gè)測試套件必須有一對 BOOST_AUTO_TEST_SUITE... BOOST_AUTO_TEST_SUITE_END 宏。清單 15 給出了在同一個(gè)文件中定義的兩個(gè)測試套件。在運行回歸測試時(shí)，用預定義的 –log_level=test_suite 選項運行可執行程序。在 清單 16 中可以看到，使用這個(gè)選項生成的輸出很詳細，有助于進(jìn)行快速調試。
#define BOOST_TEST_MODULE Regression #include <boost/test/included/unit_test.hpp> typedef struct { int c; char d; double e; bool f; } Node; typedef union { int c; char d; double e; bool f; } Node2; BOOST_AUTO_TEST_SUITE(Structure) BOOST_AUTO_TEST_CASE(Test1) { Node n; BOOST_CHECK(sizeof(n) < 12); } BOOST_AUTO_TEST_SUITE_END() BOOST_AUTO_TEST_SUITE(Union) BOOST_AUTO_TEST_CASE(Test1) { Node2 n; BOOST_CHECK(sizeof(n) == sizeof(double)); } BOOST_AUTO_TEST_SUITE_END() |
下面是 清單 15 中代碼的輸出：
[arpan@tintin] ./a.out --log_level=test_suite Running 2 test cases... Entering test suite "Regression" Entering test suite "Structure" Entering test case "Test1" m2.cpp(23): error in "Test1": check sizeof(n) < 12 failed Leaving test case "Test1" Leaving test suite "Structure" Entering test suite "Union" Entering test case "Test1" Leaving test case "Test1" Leaving test suite "Union" Leaving test suite "Regression" *** 1 failure detected in test suite "Regression" |
到目前為止，本文已經(jīng)討論了 Boost 測試實(shí)用程序和沒(méi)有層次結構的測試套件?，F在，我們使用 Boost創(chuàng )建一個(gè)測試套件，以外部工具用戶(hù)常見(jiàn)的方式測試軟件產(chǎn)品。在測試框架中，通常有多個(gè)套件，每個(gè)套件檢查產(chǎn)品的某些特性。例如，文字處理程序的回歸測試框架應該包含檢查字體支持、不同的文件格式等方面的套件。每個(gè)測試套件包含多個(gè)單元測試。清單 17 提供了一個(gè)測試框架示例。注意，代碼入口點(diǎn)必須是名為 init_unit_test_suite 的例程。
#define BOOST_TEST_MODULE MasterTestSuite #include <boost/test/included/unit_test.hpp> using boost::unit_test; test_suite* init_unit_test_suite( int argc, char* argv[] ) { test_suite* ts1 = BOOST_TEST_SUITE( "test_suite1" ); ts1->add( BOOST_TEST_CASE( &test_case1 ) ); ts1->add( BOOST_TEST_CASE( &test_case2 ) ); test_suite* ts2 = BOOST_TEST_SUITE( "test_suite2" ); ts2->add( BOOST_TEST_CASE( &test_case3 ) ); ts2->add( BOOST_TEST_CASE( &test_case4 ) ); framework::master_test_suite().add( ts1 ); framework::master_test_suite().add( ts2 ); return 0; } |
每個(gè)測試套件（比如 清單 17 中的 ts1）都是使用 BOOST_TEST_SUITE 宏創(chuàng )建的。這個(gè)宏需要一個(gè)字符串作為測試套件的名稱(chēng)。最終使用 add 方法，把所有測試套件添加到主測試套件中。同樣，我們使用 BOOST_TEST_CASE 宏創(chuàng )建每個(gè)測試，然后再使用 add 方法把它們添加到測試套件中。也可以把單元測試添加到主測試套件中，但是不建議這么做。master_test_suite 方法屬于 boost::unit_test::framework 名稱(chēng)空間的一部分：它在內部實(shí)現一個(gè)單實(shí)例對象。清單 18 中的代碼取自 Boost 源代碼本身，解釋了這個(gè)方法的工作方式。
master_test_suite_t& master_test_suite() { if( !s_frk_impl().m_master_test_suite ) s_frk_impl().m_master_test_suite = new master_test_suite_t; return *s_frk_impl().m_master_test_suite; } |
使用 BOOST_TEST_CASE 宏創(chuàng )建的單元測試以函數指針作為輸入參數。在 清單 17 中，test_case1、test_case2 等是 void 函數，用戶(hù)可以按自己喜歡的方式編寫(xiě)代碼。但是注意，Boost 測試設置會(huì )使用一些堆內存；每個(gè)對 BOOST_TEST_SUITE 的調用都會(huì )產(chǎn)生一個(gè)新的 boost::unit_test::test_suite(<test suite name>)。
從概念上講，測試裝備（test fixture）是指在執行測試之前設置一個(gè)環(huán)境，在測試完成時(shí)清除它。清單 19 提供了一個(gè)簡(jiǎn)單的示例。
#define BOOST_TEST_MODULE example #include <boost/test/included/unit_test.hpp> #include <iostream> struct F { F() : i( 0 ) { std::cout << "setup" << std::endl; } ~F() { std::cout << "teardown" << std::endl; } int i; }; BOOST_AUTO_TEST_SUITE( test ) BOOST_FIXTURE_TEST_CASE( test_case1, F ) { BOOST_CHECK( i == 1 ); ++i; } BOOST_AUTO_TEST_SUITE_END() |
清單 20 給出了輸出。
[arpan@tintin] ./a.out Running 1 test case... setup fix.cpp(16): error in "test_case1": check i == 1 failed teardown *** 1 failure detected in test suite "example" |
這段代碼沒(méi)有使用 BOOST_AUTO_TEST_CASE 宏，而是使用 BOOST_FIXTURE_TEST_CASE，它需要另一個(gè)輸入參數。這個(gè)對象的 constructor 和 destructor 方法執行必需的設置和清除工作?？匆幌?Boost 頭文件 unit_test_suite.hpp 就可以確認這一點(diǎn)（見(jiàn) 清單 21）。
#define BOOST_FIXTURE_TEST_CASE( test_name, F ) struct test_name : public F { void test_method(); }; static void BOOST_AUTO_TC_INVOKER( test_name )() { test_name t; t.test_method(); } struct BOOST_AUTO_TC_UNIQUE_ID( test_name ) {}; BOOST_AUTO_TU_REGISTRAR( test_name )( boost::unit_test::make_test_case( &BOOST_AUTO_TC_INVOKER( test_name ), #test_name ), boost::unit_test::ut_detail::auto_tc_exp_fail< BOOST_AUTO_TC_UNIQUE_ID( test_name )>::instance()->value() ); void test_name::test_method() |
在內部，Boost 從 struct F 公共地派生一個(gè)類(lèi)（見(jiàn) 清單 19），然后從這個(gè)類(lèi)創(chuàng )建對象。按照 C++ 的公共繼承規則，在函數中可以直接訪(fǎng)問(wèn) struct 類(lèi)的所有受保護變量和公共變量。注意，在 清單 19 中修改的變量 i 屬于類(lèi)型為 F 的內部對象 t（見(jiàn) 清單 20）。在回歸測試套件中可能只有幾個(gè)測試需要某種顯式的初始化，因此可以只對它們使用裝備特性。在 清單 22 給出的測試套件中，三個(gè)測試中只有一個(gè)使用裝備。
#define BOOST_TEST_MODULE example #include <boost/test/included/unit_test.hpp> #include <iostream> struct F { F() : i( 0 ) { std::cout << "setup" << std::endl; } ~F() { std::cout << "teardown" << std::endl; } int i; }; BOOST_AUTO_TEST_SUITE( test ) BOOST_FIXTURE_TEST_CASE( test_case1, F ) { BOOST_CHECK( i == 1 ); ++i; } BOOST_AUTO_TEST_CASE( test_case2 ) { BOOST_REQUIRE( 2 > 1 ); } BOOST_AUTO_TEST_CASE( test_case3 ) { int i = 1; BOOST_CHECK_EQUAL( i, 1 ); ++i; } BOOST_AUTO_TEST_SUITE_END() |
在 清單 22 中，在一個(gè)測試用例上定義和使用了裝備。Boost 還允許用戶(hù)通過(guò) BOOST_GLOBAL_FIXTURE (<Fixture Name>) 宏定義和使用全局裝備?？梢远x任意數量的全局裝備，因此可以把初始化代碼分割為多個(gè)部分。清單 23 使用一個(gè)全局裝備。
#define BOOST_TEST_MODULE example #include <boost/test/included/unit_test.hpp> #include <iostream> struct F { F() { std::cout << "setup" << std::endl; } ~F() { std::cout << "teardown" << std::endl; } }; BOOST_AUTO_TEST_SUITE( test ) BOOST_GLOBAL_FIXTURE( F ); BOOST_AUTO_TEST_CASE( test_case1 ) { BOOST_CHECK( true ); } BOOST_AUTO_TEST_SUITE_END() |
對于多個(gè)裝備，它們的設置和清除按照聲明的次序執行。在 清單 24 中，先調用 F 的構造函數，然后是 F2 的；對于銷(xiāo)毀函數也是這樣。
#define BOOST_TEST_MODULE example #include <boost/test/included/unit_test.hpp> #include <iostream> struct F { F() { std::cout << "setup" << std::endl; } ~F() { std::cout << "teardown" << std::endl; } }; struct F2 { F2() { std::cout << "setup 2" << std::endl; } ~F2() { std::cout << "teardown 2" << std::endl; } }; BOOST_AUTO_TEST_SUITE( test ) BOOST_GLOBAL_FIXTURE( F ); BOOST_GLOBAL_FIXTURE( F2 ); BOOST_AUTO_TEST_CASE( test_case1 ) { BOOST_CHECK( true ); } BOOST_AUTO_TEST_SUITE_END() |
注意，不能將全局裝備作為對象用在單個(gè)測試中。也不能在測試中直接訪(fǎng)問(wèn)它們的公共/受保護的非靜態(tài)方法或變量。
本文介紹了最強大的開(kāi)放源碼回歸測試框架之一：Boost。討論了基本的 Boost檢查、模式匹配、浮點(diǎn)比較、定制檢查、測試套件的組織（包括手工和自動(dòng)）和裝備。請通過(guò) Boost 文檔了解更多信息。本系列的后續文章將介紹cppUnit 等開(kāi)放源碼回歸測試框架。
聯(lián)系客服
