我剛剛開始使用TDD，並且很好奇其他人如何運行測試。作爲參考，我使用的是谷歌測試框架，但我相信這個問題適用於大多數其他測試框架和C/C++以外的語言。你如何運行你的單元測試？編譯器標誌？靜態庫？
我一般的做法至今一直做的三兩件事之一：
寫的大部分應用程序的靜態庫，然後再創建兩個可執行文件。一個可執行文件是應用程序本身，而另一個則是所有測試的測試運行器。都鏈接到靜態庫。
嵌入測試代碼直接插入應用程序本身，以及啓用或使用編譯器標記禁用測試代碼。這可能是迄今爲止我使用過的最好的方法，但會使代碼混亂一點。
嵌入給出的測試代碼直接插入應用程序本身，而且，某些命令行切換某一種運行該應用程序本身或運行嵌入在應用程序中的測試。
這些解決方案都不是特別優雅 ...
如何你辦呢？
我傾向於傾向於使用dll的靜態庫，所以我的大部分C++代碼都會以靜態庫的形式結束，正如您發現的，它們與dll一樣容易測試。
對於構建到exe中的代碼，我要麼有一個單獨的測試項目，它只包含測試中的源文件，這些文件通常內置在exe中，或者構建一個新的靜態庫，其中包含大部分exe文件，按照我測試所有其他靜態庫的方式來測試。當我對現有應用程序進行復古適配測試時，我發現我通常採用新項目中的'大部分代碼庫'方法和'將exe項目中的源文件拖入測試項目'方法。
我不喜歡你的選項2和3。管理2的構建配置可能比擁有一個單獨的測試項目更加困難，該項目只需將它需要的源文件拖入其中，並將所有測試包括到exe中，如您在第3章中所建議的那樣錯誤;）
我在他們的框架中使用第三方測試運行者，並在構建腳本中包含測試。測試不在生產代碼（外部DLL）之外。
什麼框架？此外，這並不能解釋測試如何訪問您的應用程序代碼。這是黑匣子還是系統測試？ – kurige 2010-04-21 07:30:21
主要是，我使用.net進行開發，所以無論是NUnit（如果項目無法承受測試suppost的Visual Studio）或MS單元測試框架。我聽說過有關向MS單元添加C++支持的一些信息，但不確定。 問題的第二部分：是的，這是黑匣子測試。 – 2010-04-21 08:04:04
您的方法沒有。 1是我總是用C/C++和Java完成的。大多數應用程序代碼位於靜態庫中，我儘量將應用程序所需的額外代碼量降至最低。
我在Python等動態語言接近TDD的方式是在稍有不同，我離開的源代碼的應用程序和測試躺在身邊和測試運行發現測試和運行它們。
我使用了兩種方法，對於dll我只是將我的單元測試與dll鏈接起來，很簡單。對於可執行文件，我包括可執行項目和單元測試項目中正在測試的源文件。這稍微增加了構建時間，但意味着我不需要將可執行文件分離爲靜態庫和主函數。
我使用boost.test進行單元測試和cmake生成我的項目文件，我覺得這是最簡單的方法。此外，我正在慢慢地將單元測試引入一個大型的遺留代碼庫，所以我正在嘗試引入最少量的更改，以防其他開發人員帶來不便，並阻止他們進行單元測試。我擔心只爲單元測試使用靜態庫可能被視爲不採用它的藉口。
話雖如此，我認爲靜態庫的方法是一個很好的，特別是如果你從頭開始。
我喜歡簡單地重新編譯相關源文件的想法，但你是正確的，它確實增加了相當多的時間來構建。 對於較大的項目，這將是不切實際的。 – kurige 2010-04-23 10:19:58
對於C/C++應用我嘗試有儘可能多的代碼儘可能在一個或多個DLL，與主應用程序是最低限度的，以啓動和越區切換到該DLL。 Dll測試起來要容易得多，因爲它們可以輸出儘可能多的入口點，以便讓測試應用程序使用。
我使用一個單獨的測試應用程序鏈接到Dll（s）。我強烈支持將測試代碼和「產品」代碼保存在不同的模塊中。
我去＃1，部分原因是
對於C++構建和測試，我喜歡使用CMake，它可以運行一系列目標可執行文件作爲測試並打印結果摘要。
Personnally，I use另一種依賴於你的方法：
我保持項目對測試不變。如果它是可執行文件，它應該保持可執行文件。您只需創建後期構建操作即可將所有obj文件聚合到靜態庫中。
然後，您可以創建測試項目，將測試框架和以前生成的靜態庫鏈接起來。
下面是對應你的問題的一些主題：
的共識似乎是，＃1是最好的。這似乎並不像它可能那樣優雅。我想如果我想要優雅，我應該改用腳本語言。 ：p – kurige 2010-04-23 10:17:00