下面詳細(xì)說(shuō)明，C++單元測(cè)試不支持reflection，所以，必須要做一些額外的工作，讓框架知道相關(guān)內(nèi)容的存在。CppUnit的做法是用宏進(jìn)行注冊(cè)。這種做法要求我們每添加一個(gè)測(cè)試，就要考慮用相應(yīng)的宏進(jìn)行注冊(cè)。

在這點(diǎn)上，CxxTest做得要好一些，有一個(gè)專(zhuān)門(mén)的腳本做這件事。通過(guò)這個(gè)腳本掃描這個(gè)自己編寫(xiě)的文件，生成一些新的文件，完成這個(gè)工作。從代碼的表現(xiàn)力和可靠度來(lái)說(shuō)，要好得多。

唯一的問(wèn)題是引入了一個(gè)腳本，而且這個(gè)腳本一般是由某些動(dòng)態(tài)語(yǔ)言寫(xiě)成的（目前的CxxTest有Perl和Python的腳本），從而引入了對(duì)這種語(yǔ)言的依賴。不過(guò)，由于C++語(yǔ)言本身的限制，從接口的角度來(lái)看，這種做法已經(jīng)很不錯(cuò)了。

語(yǔ)法
有一種C++單元測(cè)試框架叫TUT，Template Unit Test的縮寫(xiě)。顧名思義，它是用模板完成的（其實(shí)，CppUnit和CxxTest都有模板的部分）。隨著C++編譯器的進(jìn)步，在大多數(shù)情況下，模板都是可以順利通過(guò)編譯的。

但是，不要忘了，還有一種環(huán)境叫嵌入式，那里的編譯器基本上還是很原始的，模板并不見(jiàn)得能夠順利的通過(guò)編譯。此外，模板還會(huì)帶來(lái)另外一個(gè)問(wèn)題，編譯時(shí)間的增長(zhǎng)，相信有過(guò)模板編程經(jīng)驗(yàn)的人都會(huì)對(duì)此深有體會(huì)。編譯時(shí)間增長(zhǎng)意味著什么？我們接下來(lái)討論。#t#

編譯時(shí)間
有一種敏捷實(shí)踐叫做測(cè)試驅(qū)動(dòng)開(kāi)發(fā)（Test Driven Development）。測(cè)試驅(qū)動(dòng)開(kāi)發(fā)的基礎(chǔ)是單元測(cè)試。測(cè)試驅(qū)動(dòng)開(kāi)發(fā)希望達(dá)成的一個(gè)目標(biāo)是快速反饋，所以，站在C++語(yǔ)言的角度，如果執(zhí)行時(shí)間受限于代碼本身無(wú)法縮短，那么我們希望編譯時(shí)間盡可能短，這樣，才不會(huì)把生命都浪費(fèi)在等待代碼編譯上。

除了剛才提到的模板問(wèn)題之外，CppUnit會(huì)把所有測(cè)試編譯生成一個(gè)可執(zhí)行文件，這意味著什么？幾乎修改任何一個(gè)文件都會(huì)造成這個(gè)文件的重新生成。隨著目標(biāo)文件的增加，這個(gè)過(guò)程時(shí)間就會(huì)增長(zhǎng)。相對(duì)于修改范圍（可能只是某一個(gè)文件）。

是顯得有些長(zhǎng)了。為什么Java語(yǔ)言不會(huì)存在這種現(xiàn)象？因?yàn)镴ava是動(dòng)態(tài)連接的，所以，Java生成.class就結(jié)束了。對(duì)應(yīng)到C++上，這只是完成了目標(biāo)文件的生成，而在C++我們不得不再進(jìn)一步生成可執(zhí)行文件。

從道理上，C++單元測(cè)試可以為不同的測(cè)試文件生成不同的可執(zhí)行文件，不過(guò)這么做又少了總體的過(guò)程，統(tǒng)計(jì)起來(lái)又顯得心有余力不足了，而且通常不會(huì)這么做。個(gè)人而言，對(duì)這幾個(gè)單元測(cè)試框架都不是非常了解，如果前面的討論存在謬誤，歡迎有識(shí)之士指出。