單元測試長期以來一直被打入軟件開發的冷宮，究其原因，大概是意識形態的問題。如果詢問開發人員：為什么不采用單元測試？得到的回答十有八九是這種模式：寫代碼時間都不夠更何況去做測試了。（我原先也是屬于那八九中的一個）但是，有一個結論:寫單元測試可以節省開發時間。這也許令人匪夷所思，但是，經過切身體會，確實如此，不過有一個前提：在編碼前寫測試。很有些反其道而行之的韻味。當年在俠客島上，眾多中原頂尖俠客參悟“俠客行”無果，而不識字的少年卻窺探到武學精髓。很多事情往往是這樣的，按常理行不通，換個方向則行云流水。且說要編寫的代碼，就好比少林寺的武僧，在下山行俠之前要經過少林銅人陣的考驗。眾多武僧在銅人陣中因為一招稀奇古怪的招式敗下陣來比比皆是。如何才能通過銅人陣的考驗呢？如果從修行的開始就了解銅人陣，并在修行中不斷的接受銅人們的折磨，那么最后的通過將不成問題。本著以上的指導思想，在編寫代碼前先設計測試用例，之后再編寫代碼，這么做的好處是：從一開始就明白代碼的目的是什么，對于代碼將會受到的折磨了然于胸，用術語說就是：需求明確，代碼覆蓋率高。我的切身體會是在使用這種方法后犯低級錯誤的概率減小了，幾乎不會使用單步測試�，F在算是對Kent Beck大師所描述的那種十分鐘不做單元測試都會覺得心驚肉跳的心情有所體會了。還有一個好處，就是復用程度的提高。這個好處的論證有點詭辯的味道，首先，編寫出來的代碼本身就有一個用戶，那就是我們需要實現的軟件中的代碼，另外一個用戶則來自于測試用例，因此，這樣的代碼本身的重用性就較強。這點也不得不承認，在編寫代測試用例的時候，將會不自覺地考慮到在軟件中的嵌入，因此，這種情況下作出的設計會有較低的耦合性。將測試驅動與經典的先代碼后測試進行比較，很重要的一個將是面臨的心境的不同。寫好的代碼是自己的血肉，沒有人會希望它脆弱，也不愿意看到它的失敗，因此，在測試的時候，往往擔驚受怕，手指在回車鍵上方盤旋，繃緊的神經頻頻接受考驗。而對于測試驅動來說，出生于艱苦的環境，每天努力打拼，為的就是能夠出人頭地，成長為健壯的代碼，因此我們會毫不猶豫的按下回車鍵，讓暴風雨來得更猛烈些吧！
在進行測試驅動的過程中，有一點是很重要的，那就是保持它的旋律。好比一出精彩的電影，有黯然神傷的低谷，也有激情澎湃的高潮。測試驅動開發的旋律就是：設計測試用例，編寫最少的代碼通過測試，重構代碼，設計下一個測試用例。其中，在編寫代碼通過測試及重構代碼的過程往往需要幾個迭代過程，期間跌宕起伏，精彩刺激。在設計好測試用例后，對其進行編譯，這時將會遭遇到第一個低谷：編譯錯誤。我們的努力目標是通過編譯，這時候，我們編寫最少的代碼通過編譯，這樣迎來了第一個上升期，但是又將面臨則測試無法通過的問題，于是再接再厲，增加代碼的功能，這樣，我們通過了測試，也迎來了第一個高潮。美好的事情總是需要變得更美好，于是我們著手對代碼進行修整，使它更優雅，我們不允許任何的重復，copy&paste是我們的死敵，不允許看不懂的代碼，那是理解的障礙，不允許任何不新鮮的味道從代碼中飄出。重構將幫助我們達到盡善盡美，而這一切的代價僅僅是幾分鐘的時間。但是，不要操之過急，否則會燙壞舌頭的。一步一步的進行，每次的修改都要保證之前通過的測試，這樣，我們最終將穩步的達到幸福的彼岸！
人都是有惰性的，惰性常常與失敗，錯誤聯系在一起。但是，惰性也代來了很多的好處。又是一個反其道而行之的例子。在使用測試驅動的過程中，如果每次進行測試都需要組織測試的環境及輸出格式，并且比較屏幕上飛出來的數據，那么，再勤勞的人也無法堅持這項工作，測試驅動也將成為一個美麗的空中樓閣。要充分發揮測試驅動的威力，必須具備以下“必要非充分”條件：能夠方便建立測試環境；有良好的輸出形式；可以方便的比較測試結果。有了以上條件后，人們可以在彈指間建立測試環境，進行頻繁的測試，讓自己的代碼在出山前接受頻繁的考驗。JUnit是Kent Beck大師建立起的一套JAVA環境下的單元測試框架。它能夠滿足上述測試驅動的必要條件，提供了方便的測試環境，良好的屏幕輸出以及結果比對機制。雖然JUnit是JAVA的，但是測試驅動卻是所有開發者的。對于行走于CPP世界的人們，CPPUnit可以滿足他們的要求。 CPPUnit是Michael Feathers建立一個開放源碼的單元測試庫，是JUnit的C＋＋版本，同樣提供了便利的條件。它的老巢位于http://sourceforge.net/projects/cppunit/。在將CPPUnit應用于測試驅動開發之前，首先要明了幾個概念：CPPUnit按照層次管理測試。最底層的就是Test Case，這里是測試代碼存在的地方，換句話說，就是測試函數。當有了幾個Test Case以后，可以把他們組織成Test Fixture。在Test Fixture中，可以建立被測試的類的實例，并編寫Test Case對類實例進行測試。當有了多個Test Fixture后就可以使用Test Suite來對測試進行管理。借用CPPUnit上的例子，需要設計一個復數類，首先希望復數類能夠使用“==”進行判斷，因此，先構思一個Test Case：
class ComplexNumberTest : public CppUnit::TestCase {
public:
ComplexNumberTest( std::string name ) : CppUnit::TestCase( name ) {}
void runTest() {
CPPUNIT_ASSERT( MyComplex (10, 1) == MyComplex (10, 1) ); // note:1
CPPUNIT_ASSERT( !(MyComplex (1, 1) == MyComplex (2, 2)) ); //note:2
}
};
這個測試用例的意圖很明顯，就是對MyComplex類進行相等測試，根據復數的數學知識，能夠得到note:1處我們期望的是相等，而note:2處則是不等。有了這個測試用例后，對其進行編譯，由于MyComplex類沒有進行定義，因此將無法通過編譯，不過，這是單元測試中必然會遇到的問題。對于無法編譯的恐懼驅使我們盡快的完成下面的代碼：
//If we compile now ,we get compile error.So keep fixing it.
bool operator==( const MyComplex &a, const MyComplex &b)
{
return true;
}
//Now compile it again,Ok!Run it,we'll get some fail.
//This is because the operator==() doesn't work properly.Keep fixing it.
現在編譯沒問題了，可以松一口氣了，不過無法通過測試，于是再接再厲，寫下：
class MyComplex {
friend bool operator ==(const MyComplex& a, const MyComplex& b);
double real, imaginary;
public:
MyComplex( double r, double i = 0 )
: real(r)
, imaginary(i)
{
}
};
bool operator ==( const MyComplex &a, const MyComplex &b )
{
return a.real == b.real && a.imaginary == b.imaginary;
}
//If we compile now and run our test it will pass.
編譯，測試，通過了，這個世界清靜了，恍如來到了桃花源…
不過，我們要的盡善盡美，MyComplex不夠美麗，于是改了個名字CComplex，這下大功告成，但是，心里始終還是有個結，如何把它用在自己的項目中呢？欲知后事，請代下回分解。
參考文獻：
Wiki About TDD
http://c2.com/cgi/wiki?TestDrivenDevelopment
Unittests in extremeprogramming.com
http://www.extremeprogramming.org/rules/unittests.html
CPPUnit Wiki
http://cppunit.sourceforge.net/cgi-bin/moin.cgi/FrontPage
CPPUnit Cook Book
http://cppunit.sourceforge.net/doc/lastest/cppunit_cookbook.html
文章來源于領測軟件測試網 http://www.kjueaiud.com/
