WinUnit:簡化的本機C++應用程式單元測試

本文討論:

單元測試原理

設定 WinUnit

構建測試裝置

實施和自訂

本文使用了以下技術:

C++和Visual Studio

目錄

立即開始測試

WinUnit 入門

裝置：設定和清除

運行 WinUnit

實現詳細資料

深入學習...

目前，要想讓機器碼開發人員一點也感覺不到壓力可能是非常困難的- 好像使用 Microsoft® .NET Framework的開發人員擁有所有出色的工具！

我一直以來都對豐富的工程實踐經驗感興趣，但所謂的“工程專家”卻屢屢讓我失望，他們只會讚揚單元測試的優點，而在請他們為機器碼的測試載入器提點建議時他們卻表示無話可說。我認為能夠最簡便地整合到自動化產生系統中的工具是針對機器碼的NUnit 等效架構，這也是我真正需要的。也就是說，我希望能夠建立一個僅包含測試的DLL，有一個可以運行這些測試的正式發行前小眾測試運行程式，並且能夠進行報告和日誌記錄。我還希望能夠一次僅聲明一個測試，在我的測試 DLL中額外代碼儘可能少。

因此，我構建了名為 WinUnit的機器碼單元測試工具。稍後我將對其進行更詳細的介紹，在此先簡單看一下使用 WinUnit 建立和運行測試 DLL 多麼容易。首先，建立一個 CPP 檔案，我們在此稱為 DummyTest.cpp：

#include "WinUnit.h"
BEGIN_TEST(DummyTest)
{
　 WIN_ASSERT_TRUE(3 > 4, _T("You should see this error message."));
}
END_TEST

使用以下命令將其構建到 DLL中：

cl /EHsc /LD DummyTest.cpp

然後對其執行 WinUnit：

>WinUnit DummyTest.dll
Processing [DummyTest.dll]...
(DummyTest)
DummyTest.cpp(5): error : WIN_ASSERT_TRUE failed: "3 > 4". You should see this error message.
FAILED: DummyTest.
[DummyTest.dll] FAILED.　Tests run: 1; Failures: 1.
There were errors.
Tests run: 1; Failed: 1.

當然，將 3 > 4 更改為 True 運算式 4 > 3 將不會失敗。

WinUnit 將接受任意數量的DLL 或目錄，對它們進行處理，報告總體結果，並返回結束代碼。順便說一下，顧名思義，WinUnit 將僅在 Windows® 上運行。

我承認在我編寫自己的工具之前，世界上並不乏針對C++ 單元測試的其他選擇。但是，我發現現有的單元測試工具中存在一個問題，通常，與易於理解和可直接使用相比，它們為可移植性設定的優先順序更高。CppUnitLite 是我最喜歡的一種可移植裝置，但由於它的設計具有極高的可自訂性，因此在設定它時所需的開銷比預期的要高。由於測試回合程式與測試都在同一二進位檔案中完成，這兩者之間的界線已經模糊，因此需要編寫實際調用測試回合功能的代碼並將其放在某處。此外，由於很難向同事解釋清楚複雜的宏實現，導致宏實現很難被採用。但是，如果您需要能夠移植到其他動作系統，CppUnitLite 絕對值得一看。

在相當長的一段時間內，其他可用於C++ 單元測試的選項與可用於測試 .NET 代碼的選項是相同的，最值得一提的是 NUnit和Visual Studio® Team Test 單元測試架構。因為這兩種架構都可以執行任何具有適當屬性的.NET 程式集，所以可以將這些工具用於使用託管 C++（現在為 C++/CLI）編寫的測試。我發現這一做法的主要不便之處在於，這些工具是專門面向 .NET 開發的，而不是面向機器碼的。這一點可能並不出人意料。但是，很難將提供的大多數 Assert 方法用於本機 C++（因為這些方法需要 .NET 風格的對象），而作為開發人員，您至少需要非常熟悉 C++/CLI（或 C++的託管擴充）才能編寫測試。您可以從“Visual Studio 2005 產品功能比較”頁 (msdn2.microsoft.com/vstudio/aa700921.aspx)的腳註中找到有關此做法的局限性的更多詳細資料。如前所述，我發現“容易說服我的同事使用它”這一因素很重要，而使用託管工具則會在這一方面設定額外的障礙。