下面詳細說明，C++單元測試不支持reflection，所以，必須要做一些額外的工作，讓框架知道相關內容的存在。CppUnit的做法是用宏進行注冊。這種做法要求我們每添加一個測試，就要考慮用相應的宏進行注冊。
在這點上，CxxTest做得要好一些，有一個專門的腳本做這件事。通過這個腳本掃描這個自己編寫的文件，生成一些新的文件，完成這個工作。從代碼的表現力和可靠度來說，要好得多。
唯一的問題是引入了一個腳本，而且這個腳本一般是由某些動態語言寫成的目前的CxxTest有Perl和Python的腳本），從而引入了對這種語言的依賴。不過，由於C++語言本身的限制，從接口的角度來看，這種做法已經很不錯了。
語法
有一種C++單元測試框架叫TUT，Template Unit Test的縮寫。顧名思義，它是用模板完成的其實，CppUnit和CxxTest都有模板的部分）。隨著C++編譯器的進步，在大多數情況下，模板都是可以順利通過編譯的。
但是，不要忘了，還有一種環境叫嵌入式，那裡的編譯器基本上還是很原始的，模板並不見得能夠順利的通過編譯。此外，模板還會帶來另外一個問題，編譯時間的增長，相信有過模板編程經驗的人都會對此深有體會。編譯時間增長意味著什麼？我們接下來討論。
編譯時間
有一種敏捷實踐叫做測試驅動開發Test Driven Development）。測試驅動開發的基礎是單元測試。測試驅動開發希望達成的一個目標是快速反饋，所以，站在C++語言的角度，如果執行時間受限於代碼本身無法縮短，那麼我們希望編譯時間盡可能短，這樣，才不會把生命都浪費在等待代碼編譯上。
除了剛才提到的模板問題之外，CppUnit會把所有測試編譯生成一個可執行文件，這意味著什麼？幾乎修改任何一個文件都會造成這個文件的重新生成。隨著目標文件的增加，這個過程時間就會增長。相對於修改范圍可能只是某一個文件）。
是顯得有些長了。為什麼Java語言不會存在這種現象？因為Java是動態連接的，所以，Java生成.class就結束了。對應到C++上，這只是完成了目標文件的生成，而在C++我們不得不再進一步生成可執行文件。
從道理上，C++單元測試可以為不同的測試文件生成不同的可執行文件，不過這麼做又少了總體的過程，統計起來又顯得心有余力不足了，而且通常不會這麼做。個人而言，對這幾個單元測試框架都不是非常了解，如果前面的討論存在謬誤，歡迎有識之士指出。
