每個解決方案是單個還是多個單元測試項目？

Question

我的產品程序集和單元測試程序集之間通常有 1:1 的映射。 我通常盡量保持較低的程序集總數，典型的解決方案可能看起來像......

• 客戶端（包含視圖、控制器等）
• 客戶端測試
• 通用（包含數據/服務合同、通用實用程序等）
• 通用測試
• 服務器（包含域、服務等）
• 服務器.測試
• 服務器.WebHost

最近在工作中，人們一直在提到只有一個單元測試項目，而不是通過他們正在測試的程序集來分解它們。 我知道在那天，如果您將 NCover 等作為構建的一部分運行（當然不再重要），這會讓生活更輕松。

單個與多個 UnitTest 項目背后的一般理由是什么？ 除了減少解決方案中的項目數量之外，是否有具體的理由采取一種或另一種方式？ 我的印象是這可能是那些“偏好”之一，但谷歌搜索並沒有出現太多。

Answer 1

沒有明確的答案，因為這完全取決於您的工作以及個人品味。 但是，您肯定希望以某種方式安排事情，以便您可以有效地工作。

對我來說，這意味着，我想快速找到東西，我想看看什么測試什么，我想運行更小的東西來更好地控制，以防我想在測試中分析或做其他事情。 當您調試失敗的測試時，這通常很好。 我不想花額外的時間去弄清楚任何事情，它應該自己說明事物是如何映射的，什么屬於什么。

對我來說另一個非常重要的事情是，我想盡可能地隔離並有明確的界限。 您想提供一種簡單的方法來將大項目的一部分重構/移出到一個獨立的項目中。

就我個人而言，我總是圍繞我的軟件的結構來安排我的測試，這意味着類與其測試、庫和測試可執行文件之間的一對一映射。 這為您提供了一個很好的測試結構，它反映了您的軟件結構，從而為查找內容提供了清晰度。 此外，它提供了一個自然的分割，以防某些東西被獨立移出。

這是我嘗試了各種做事方式后的個人選擇。

在我看來，當東西太多時分組並不一定是件好事。 可以，但我相信在本次討論的上下文中，這是針對單個測試項目的錯誤論點。 太多包含許多文件的測試項目意味着只有一個包含大量測試文件。 我相信真正的問題是你正在研究的解決方案越來越大。 也許您還可以做其他事情來避免“同一個世界”？ :)

Answer 2

除了其他（好的）答案之外，請考慮在較大的項目團隊中，個別團隊成員可能會創建自己的解決方案，以僅包含他們正在處理的項目子集。

假設一個單一的解決方案，其中一個測試項目涵蓋了該解決方案中的所有內容，在這種情況下會崩潰。

Answer 3

我要說的部分原因是它迫使您只招募您正在測試的程序集。 所以你的單元測試不會意外地變成集成測試或更糟。 它有助於確保關注點分離。

Answer 4

如果您在架構的較低層中測試功能，那么擁有一個 UnitTest 項目可能會大大減慢您的速度。 你會花更多的時間等待編譯器完成而不是實際編寫代碼。 想象一個單元測試項目將依賴於所有項目。 這些項目相互依賴。 較低層項目的代碼更改可能會導致重新編譯該項目上層的項目。 如果您觸發單元測試，可能會發生這種情況

例如，如果您有依賴於模型項目的業務邏輯。 你改變你的模型項目。 測試項目取決於業務邏輯和模型。

單元測試 -> 模型

單元測試 -> 業務邏輯 -> 模型

但您只測試模型中的更改。 現在，盡管您只更改了模型，但模型和業務邏輯都可能會重新編譯。 這發生在我的一個更復雜的項目中，並更改為每個生產項目有一個測試項目有所幫助。

Answer 5

我不確定特定標准，但在我看來，將它們拆分為單獨的測試項目似乎是更好的做法。 在我看來，它與解決方案/項目級別的面向對象編程非常相似。 假設您的一個項目需要在某處重復使用，並且您希望能夠隨身攜帶您的測試。 如果它們與其他測試位於不同的項目中，並且僅適用於該特定項目，則您也只需將該項目也一起轉移即可。 否則，您必須通過大規模測試項目進行文件釣魚。

此外，項目的分離有助於在調試時保持整潔。 不必打開一個龐大的項目並去挖掘您需要的測試文件，如果您有功能項目的匹配測試項目，那就簡單多了……大大縮小了您的搜索范圍。

再說一次，我認為這是一種偏好，我從來沒有聽說過以某種方式確定的解決方案，但是我的兩分錢值...

Answer 6

我實際上可能會極端地說，如果您考慮將測試拆分為不同的項目來測試一個程序集，那么該程序集就太大了。 1 映射測試。 這當然可能會導致 DLL 溢出，並且對於某些項目（例如 Web 項目，將控制器拆分為不同的程序集在邏輯上不那么干凈）可能並不總是可能的。 只是一個想法。

Answer 7

我們正在嘗試一個單獨的測試解決方案，其中所有測試項目都與項目解決方案在 1-1 的基礎上進行。