2011-02-18 56 views
23

我的產品組件和我的單元測試組件之間通常有1:1映射。我一般儘量保持組件的總數量低,典型的解決方案可能是這個樣子......單個或多個單元測試項目每個解決方案?

  • 客戶端(包含瀏覽器,控制器等)
  • Client.Tests
  • 通用(含數據/服務合同,常用工具等)
  • Common.Tests
  • 服務器(包含域,服務等)
  • Server.Tests
  • Server.WebHos t

最近在工作中,人們一直在提及只有一個單元測試項目與他們正在測試的程序集進行分解。我知道當天回來的時候,如果你使用NCover等作爲你的構建的一部分,這會讓生活更輕鬆(當然不再重要)。

單個和多個UnitTest項目背後的一般理性是什麼?除了減少解決方案中項目的數量之外,是否有一個具體的理由去某種方式?我覺得這可能是這些「偏好」之一,但谷歌並沒有太多變化。

+1

另請參見類似於http://stackoverflow.com/questions/5197192/which-is-better-unit-test-project-per-solution-or-per-project?rq=1 – 2013-04-16 10:47:43

回答

15

沒有確定的答案因爲這一切都取決於你的工作以及個人的品味。然而,你一定想以某種方式安排事情,所以你可以有效地工作

對於我來說,我想快速找到東西,我想看看什麼測試什麼,我想運行更小的東西,以便更好地控制,以便在測試中配置文件或做其他事情。當你調試失敗的測試時,這通常是很好的。我不想花費額外的時間去思考什麼,它應該說明事物如何映射以及屬於什麼。

另一個對我來說很重要的事情是我想盡可能地隔離並且有明確的界限。你想提供一個簡單的方法來重構/移出你的大項目的一部分到一個獨立的項目。個人而言,我總是安排自己的軟件結構化測試,這意味着類和測試,庫和測試可執行文件之間的一對一映射。這爲您提供了一個很好的測試結構,它反映了您的軟件結構,從而爲查找事物提供了清晰度。另外,它提供了一種自然分割,以防某些東西獨立移出。

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

在我看來,分組的東西太多時不一定是件好事。它可以是,但我認爲在這個討論的背景下,它是單個測試項目的錯誤觀點。裏面有很多文件的測試項目太多意味着只有很多測試文件。我相信真正的問題是你正在開發的解決方案越來越大。也許還有其他的事情可以做,以避免「一個世界」? :)

+0

這幾乎與內聯我的想法也是如此。根據目前的答案,這絕對是一種喜歡的東西。我認爲我會堅持使用我的1:1映射,因爲它是我最喜歡的映射,我認爲它可以以可預測的方式更加強化/組織結構。感謝您的反饋(打算讓Q開放一點,但+1)。 – 2011-02-18 16:06:56

4

我想說的部分原因是它迫使你只徵集你正在測試的程序集。所以你的單元測試不會意外地變成集成測試或更糟。它有助於確保顧慮的分離。

1

我對某個特定的標準並不確定,但在我看來,將它們分解爲單獨的測試項目似乎是一種更好的做法。在我看來,在解決方案/項目級別上與面向對象編程非常類似。假設您的某個項目需要在某處重用,並且希望能夠隨身攜帶測試。如果他們與其他測試單獨在一個項目中,並且只對該特定項目具有排他性,則只需將該項目也一起轉移。否則,你必須通過批量測試項目進行文件捕魚。

此外,項目的分離有助於在調試時保持整潔。而不是不得不破解一個單一的大型項目,並去挖掘你需要的測試文件,如果你有一個匹配的功能項目測試項目,它會簡單得多......大大縮小你的搜索範圍。

同樣,我認爲這是一個優先的事情,我從來沒有聽說過一個明確的解決辦法的一種方式或其他,但我的價值兩分錢......

0

我實際上可能去極端如果你考慮在不同的項目中分割你的測試來測試一個程序集,那麼這個程序集就太大了..我通常把我的項目分成小的,可重用的組件,用小的1-1映射測試。這當然可能會導致DLL溢出,並且對於某些項目(例如Web項目,在這種情況下,將控制器拆分爲不同的程序集時,它不像邏輯上那麼幹淨)可能並不總是可能的。只是一個想法。

9

除了其他(良好)答案之外,請考慮在較大的項目團隊中,單個團隊成員可能會創建自己的解決方案,以僅包含他們正在開發的項目子集。

假設一個單一的解決方案,一個測試項目涵蓋該解決方案中的所有內容,在這種情況下會出現故障。

+0

非常真實的,我已經在一些較大的解決方案(70多個項目)上工作過,我認爲他們傾向於邪惡開始;無論如何,絕對是一個好點。 – 2011-02-26 16:24:40

相關問題