下面詳細說明，C++單元測試不支持reflection，所以，必須要做一些額外的工作，讓框架知道相關內容的存在。CppUnit的做法是用宏進行注冊。這種做法要求我們每添加一個測試，就要考慮用相應的宏進行注冊。

在這點上，CxxTest做得要好一些，有一個專門的腳本做這件事。通過這個腳本掃描這個自己編寫的文件，生成一些新的文件，完成這個工作。從代碼的表現力和可靠度來說，要好得多。

唯一的問題是引入了一個腳本，而且這個腳本一般是由某些動態語言寫成的（目前的CxxTest有Perl和Python的腳本），從而引入了對這種語言的依賴。不過，由于C++語言本身的限制，從接口的角度來看，這種做法已經很不錯了。

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

但是，不要忘了，還有一種環境叫嵌入式，那里的編譯器基本上還是很原始的，模板并不見得能夠順利的通過編譯。此外，模板還會帶來另外一個問題，編譯時間的增長，相信有過模板編程經驗的人都會對此深有體會。編譯時間增長意味著什么？我們接下來討論。#t#

編譯時間
有一種敏捷實踐叫做測試驅動開發（Test Driven Development）。測試驅動開發的基礎是單元測試。測試驅動開發希望達成的一個目標是快速反饋，所以，站在C++語言的角度，如果執行時間受限于代碼本身無法縮短，那么我們希望編譯時間盡可能短，這樣，才不會把生命都浪費在等待代碼編譯上。

除了剛才提到的模板問題之外，CppUnit會把所有測試編譯生成一個可執行文件，這意味著什么？幾乎修改任何一個文件都會造成這個文件的重新生成。隨著目標文件的增加，這個過程時間就會增長。相對于修改范圍（可能只是某一個文件）。

是顯得有些長了。為什么Java語言不會存在這種現象？因為Java是動態連接的，所以，Java生成.class就結束了。對應到C++上，這只是完成了目標文件的生成，而在C++我們不得不再進一步生成可執行文件。

從道理上，C++單元測試可以為不同的測試文件生成不同的可執行文件，不過這么做又少了總體的過程，統計起來又顯得心有余力不足了，而且通常不會這么做。個人而言，對這幾個單元測試框架都不是非常了解，如果前面的討論存在謬誤，歡迎有識之士指出。