Home > The Unit Test Framework > Usage recommendations > Generic
PrevNext

Generic usage recommendations

Prefer offline compiled libraries to the inline included components
If you use only free function based test cases advance to the automatic registration facility
To find location of first error reported by test tool within reused template function, use special hook within framework headers
To test reusable template base component with different template parameter use test case template facility
Prefer BOOST_CHECK_EQUAL to BOOST_CHECK

Prefer offline compiled libraries to the inline included components
相對於內嵌包含的組件,優先使用離線的預編譯庫

If you are just want to write quick simple test in environment where you never used Boost.Test before - yes, use included components. But if you plan to use Boost.Test on permanent basis, small investment of time needed to build (if not build yet), install and change you makefiles/project settings will soon return to you in a form of shorter compilation time. Why do you need to make your compiler do the same work over and over again?
如果你只是想在之前未使用過 Boost.Test 的環境中寫快速簡單的瑣測試 - 是的,使用內嵌的組件。 但如果你計劃使用 Boost.Test 作為持久的基礎,用於生成 (如果還未生成) 的時間的投資是很小的, 安裝修改你的 makefiles/project 設置很快就會以更短的編譯時間帶給你回報。 你為什麼要讓編譯器一遍又一遍地做相同的工作呢?

If you use only free function based test cases advance to the automatic registration facility
如果你只使用基於自由函數的測試用例,推薦使用自動註冊工具

It's really easy to switch to automatic registration. And you don't need to worry about forgotten test case anymore
真的很容易切換到自動註冊。並且你不用再擔心忘記註冊用例。

To find location of first error reported by test tool within reused template function, use special hook within framework headers
在可復用的模板函數中,要找到測試工具報告的第一個錯誤的位置,使用框架頭文件中特定的勾子

In some cases you are reusing the same template based code from within one test case (actually I recommend better solution in such case- see below). Now if an error gets reported by the test tool within that reused code you may have difficulty locating were exactly error occurred. To address this issue you could either a add BOOST_TEST_MESSAGE statements in templated code that log current type id of template parameters or you can use special hook located in unit_test_result.hpp called first_failed_assertion(). If you set a breakpoint right on the line where this function is defined you will be able to unroll the stack and see where error actually occurred.
在某些情況下,你會在一個在測試用例中復用相同的模板代碼 (實際上我推薦更好的解決方案 - 見下面)。 如果在復用代碼中測試工具報告了一個錯誤,你可能很難找到錯誤發生的確切地點。 要定位這個問題,你可以在模板代碼中添加 BOOST_TEST_MESSAGE 語句記錄當前模板參數類型 id, 或者你可以使用位於 unit_test_result.hpp 頭文件內的特定的勾子,叫 first_failed_assertion()。 如果你將斷點設在這個函數被定義的行,你就可以解棧,並看到錯誤實際發生的地方。

To test reusable template base component with different template parameter use test case template facility
要用不同的模板參數測試基於可復用模板的組件,使用測試用例模板工具

If you writing unit test for generic reusable component you may have a need to test it against set of different template parameter types . Most probably you will end up with a code like this:
如果你為泛型可復用的組件寫測試用例,你可能需要為一系列不同的模板參數類型進行測試。 極有可能你會這樣完成代碼:

template<typename TestType>
void
specific_type_test( TestType* = 0 )
{
    MyComponent<TestType> c;
    ... // here we perform actual testing
}

void my_component_test()
{
    specific_type_test( (int*)0 );
    specific_type_test( (float*)0 );
    specific_type_test( (UDT*)0 );
    ... 
}

This is namely the situation where you would use test case template facility. It not only simplifies this kind of unit testing by automating some of the work, in addition every argument type gets tested separately under unit test monitor. As a result if one of types produce exception or non-fatal error you may still continue and get results from testing with other types.
這就是應該使用測試用例模板工具的情況。它不僅通過自動化一些工作簡化了這類的單元測試, 並且每個參數類型都在單元測試監控器下獨立進行。其結果是如果一個類型產生異常或非致使錯誤, 你仍然可以繼續運行,並從其它類型的測試中得到結果。

Prefer BOOST_CHECK_EQUAL to BOOST_CHECK
相對 BOOST_CHECK,優先使用 BOOST_CHECK_EQUAL

Even though BOOSK_CHECK tool is most generic and allows validating any bool convertible expression, I would recommend using, if possible, more specific tools dedicated to the task. For example if you need you validate some variable vs. some expected value use BOOST_CHECK_EQUAL instead. The main advantage is that in case of failure you will see the mismatched value - the information most useful for error identification. The same applies to other tools supplied by the framework.
雖然 BOOST_CHECK 工具是最通用的,允許驗證任意可轉換為布爾的表達式,我仍然推薦,如果可能, 使用更適合於任務的特定工具。例如,如果想要驗證某個變量和某個期望值,使用 BOOST_CHECK_EQUAL。 主要的優勢在於如果檢查失敗,你可以看到不匹配的值 - 錯誤辨認最有用的信息。 這同樣可以應用於框架提供的其它工具。


PrevUpHomeNext