我正在慢慢地對我的常規工作流進行git和unit testing部分測試。我很感激關於單元測試框架（不是測試本身，而是實際框架）是否應該包含在項目的git倉庫中的建議。一方面，它看起來不應該，因爲框架是a）在其他地方容易獲得的，b）對項目來說不是唯一的（我正在討論流行的框架，比如qunit for JS或PHP中的simpletest） 。在這種情況下，在回購中可能有一個簡單的自述文件，指出框架的版本以及在哪裏獲得它就足夠了。在git repo中包含測試框架？
另一方面，測試是項目的一部分（也是回購的一部分），並且確實需要運行框架，所以爲了完整性，也許應該包括框架？
謝謝。
閱讀這個問題的答案很有意思，因爲它顯示了對軟件開發許多不同方面的非常廣泛的解釋。我通常認爲任何類型的依賴關係都不應該存儲在VCS中（通過VCS，我指的是像git，hg，svn，cvs這樣的工具，而不是像Xcode那樣包含這些工具的更大的系統），因爲這是而不是VCS的工作。依賴性跟蹤最好留給打包工具。 （看起來很多人使用VCS作爲原始包裝工具，恕我直言，這是一個巨大的錯誤。）
我想你需要澄清你的意思是'測試框架'。對我而言，我的大多數測試套件都是由automake提供的框架調用的。我當然不會在我的git倉庫中包含automake，但未來版本差異沒有問題，因爲automake生成的所有測試框架都包含在分發tarball中。所以真正的問題是推回到一個更高的水平。如果您僅使用VCS來跟蹤您的版本，那麼您遇到了問題，因爲您確實需要在檢出舊版本的項目時使測試框架可用。如果VCS是檢索舊版本的唯一存儲機制（即，您未在tarball中使用任何排序存檔版本），那麼您似乎不得不將該框架放入VCS中。但坦率地說，將外部軟件放入VCS是很愚蠢的。這樣做的唯一原因是如果您使用VCS作爲您的分發工具。所以我想我的答案是：不要把框架放到你的VCS中，但是把框架放在你的發行版中。如果你的VCS是你的分佈工具，那麼沒有正確的方法來處理測試框架。
我會說不，因爲它們很容易在別處找到，而且任何有經驗的開發人員都應該已經有了這些庫。另外，一些現代的IDE（特別是eclipse）已經提供了你需要的單元測試庫，所以將它們與你的源一起發佈並不重要。
我幾乎總是包含框架（一個理智的應該是幾個庫和可執行文件，所以不是那麼大） - 源代碼和測試版本化，如果我回去從2001年獲取我的代碼的1.2版本，我希望在進行修復時運行測試 - 不要失敗，因爲我使用的是2006年更改爲的測試框架。
沒有源代碼控制中的測試框架，我添加了一件事匹配版本。哎呀，如果可行的話，我會在那裏版本編譯器和語言庫。
如果你有一個巨大的測試工具/平臺不能輕易放在一起（或者不能合法地放在一起），請確保包含某種類型的文檔以告知哪些工具，哪些版本，並可能如何將它與測試結合在一起。
有趣的問題。儘管如此，我認爲測試框架不應該包含在應用程序庫中。
在自述文件中命名項目的先決條件。如果您有多個使用相同測試框架的項目，那麼您已經安裝了該框架，並且您可能不希望爲每個項目再次下載或安裝該框架。
我使用單元測試在我的所有倉庫中包含NUnit DLL。我實際上包含了我需要編譯和運行測試的所有知識庫。當然，這對於一些項目來說是不可行的，但是如果可行的話，檢查倉庫並開始工作變得非常容易。無需安裝。
不，你不應該在你的倉庫中包含外部框架，除非你實際上修改框架來處理你的項目。
根據您使用的是什麼語言，您可能需要使用README文件或依靠您的打包工具;例如，Python的distutils和Perl的Module :: Build都允許指定運行測試所需的外部模塊，並且會爲用戶安裝依賴關係。
我們將全部引用庫到我們的存儲庫。
這樣做的好處是您可以將所有必需的組件放在一個位置。如果你有一臺新電腦，你只需要安裝你選擇的IDE，檢出版本庫，並且你已經準備好了。
這也使得構建服務器上的構建過程變得很容易，因爲您只需將其指向存儲庫即可，該存儲庫包含構建所需的所有內容（儘管使用.NET框架）。因此很容易創建一個沒有任何版本問題的舊版本版本。
從Python世界中，我會將依賴關係包含在我的setup.py文件中。開發人員可以獲取它們。
有了tarball，我有時會包含一個generated test file ，這樣人們在運行項目之前至少可以做一些健康測試。
VCS與分銷/包裝之間的區別很有趣，而且我之前沒有真正聽說過。我認爲這種區分捕捉到了我一直在努力的模糊性，所以我將其標記爲答案，即使我認爲許多其他答案也很好。 – 2011-04-08 16:00:49