您會說什麼是管理大型.net應用程序中單元測試的最佳方式？爲解決方案中的每個獨立項目添加測試項目還是爲其餘項目中的所有測試添加一個大型測試項目更好？.NET單元測試項目組織
例如，如果解決方案中有10個項目，是否最好有10個額外的測試項目或者一個大型測試項目足以滿足整個解決方案？
我知道模塊化測試程序集提供了一些好處，但使用測試類別可以實現非常相似的事情。對許多項目來說，編譯需要更長的時間，但是您可以排除當時不需要的項目，而如果只有一個項目，則無法執行此操作，但編譯所花費的時間會少一點。
請在您的答案中列出每種選擇的優點/缺點。
Phil Haack寫了一篇關於單元測試結構的好文章。編寫單元測試時這已經成爲我個人的最佳實踐。這裏是他的文章的鏈接http://haacked.com/archive/2012/01/02/structuring-unit-tests.aspx
至於你的問題，我會一直爲單元測試創建一個單獨的項目，並將其命名爲.UnitTests（我這樣做是爲了區分單元測試和集成測試）。例如，如果我的主項目是Sample.WebUI，則測試將是Sample.WebUI.UnitTests。
確實，單元測試增加了編譯時間，但我認爲這是一個小問題。我正在研究一個包含17個項目（不包括單元測試）的解決方案，編譯所有內容需要大約50-60秒。只需要足夠的時間讓我的眼睛離開顯示器，然後看看其他東西是否有變化:-)
關於類別，如果您有一些需要測試快速完成的日常構建，然後使用它們並區分它們從那些需要更長時間才能完成的測試（如集成測試）。另外，如果您使用TFS，則使用類別可以幫助自動化和測試您的簽入。
看看這個問題："Best Practice: Organize Unit Tests"
雖然問題解決方案的尺寸是不同的，書面的指導方針也仍然有效。
就個人而言，我更喜歡每個實際項目都有專門的測試項目。當談到構建新的功能/模塊/項目時，我發現能夠快速篩選出其他不相關的測試項目套件要好得多。它使TDD循環更加快速，能夠在我開發新項目時快速運行測試。
更重要的是，它可以幫助您根據需要爲您的燈具保持良好的各種測試/模擬類的組織，而不會混淆一大堆無關的代碼。它還使新開發人員更容易找到相關的測試。最後，它可以確保您的測試對特定項目的依賴性決不會意外地依賴於另一個不相關的項目。
+1縮短反饋循環：通過不依賴於不相關的東西來縮短構建時間。 – 2012-04-25 18:00:45
我個人的選擇是每個項目只有一個測試項目，只有單元測試。該測試項目的文件夾結構與正在測試的項目完全相同。除此之外，還可以根據需要進行多項集成測試項目。
這種方法的主要優點是，當您需要帶1個項目並將其用於不同的解決方案時，您總是將測試項目結合在一起，確保在新解決方案中有機會保持質量。
直到現在我還沒有發現任何缺點，除了必須使用一個測試項目更多的替代引用。
測試類別非常適合CI，特別是硒測試。您可以編寫給定工作項目的用戶案例，爲其生成硒測試，然後一旦工作項目完成，簽入時，工作項目的這些測試將與整個迴歸套件一起執行。這有助於防止在ci管道中進一步部署大量微小錯誤。現在我認爲我確信每個實際項目都會創建一個測試項目。 – alxbrd 2012-04-25 09:02:28