UnitTest你如何組織你的測試文件？

目前，我正在通過包（項目）拆分所有測試。因此，如果我有12個項目，我將爲12個課程創建1個單元測試項目，這將測試我的所有包。UnitTest你如何組織你的測試文件？

你是否按照同樣的方式做了測試，還是你有1個班的測試班？你如何組織你所有的測試？

2008-11-19 Patrick Desjardins

像Pokus我的測試是在相同的程序集作爲要測試的類，所以我可以測試內部和私有。

在C＃中有Debug和Release版本，我用編譯器指令UNITTEST添加了另一個名爲UnitTest。然後，我可以在測試類的頂部添加指令（#if UNITTEST），以便在編譯Debug或Release時不會編譯測試，但是當我編譯UnitTest時它們是。

我添加了一個名爲Tests的文件夾，其中包含我的測試類。 Class1.cs有一個測試類Tests \ Class1UnitTest.cs。

也許更好的方法，但這對我有用。

來源

2008-11-19 13:47:58 xando

我們又組織這樣的（C++）：

package/Class.cpp 
package/Class.hpp 
package/test/ClassUnitTest.cpp 
package/test/ClassIntegrationTest.cpp 
test/unit-test/main.cpp 
test/integration-test/main.cpp 
test/data 
test/tmp

凡單元測試和集成測試只是在測試運行，測試/數據持有所使用的數據文件通過集成測試和test/tmp保存由相同測試創建的臨時文件，並針對每個測試套件進行清除。

來源

2008-11-19 13:21:09

因爲我傾向於做TDD，所以我爲每個類都有一個測試類，並將這些測試類分組爲一個直接測試類，以便將測試項目與實際項目進行匹配。根據解決方案的大小，測試項目要麼存在於相同的解決方案中（如果很小），要麼分解成單獨的解決方案（如果更大）

來源

2008-11-19 13:23:06

我將我的單元測試保存在他們測試的項目中的包中。通過這種方式，所有測試都通過應用程序代碼檢出版本控制。單元測試目錄基本上是源目錄的鏡像，因此兩者之間的包結構是相同的。

爲例（不是我真正的包名）：

src.com.app 
src.com.app.model 
src.com.app.view 
src.com.app.controller 

tests.com.app 
tests.com.app.model 
tests.com.app.view 
tests.com.app.controller

來源

2008-11-19 13:28:14

在Java/Maven的設置：

project/src/main/java/Package/Class.java 
project/src/test/java/Package/ClassTest.java 
project/src/main/resources/Package/resource.properties 
project/src/test/resources/Package/test_resource.properties

來源

2008-11-19 13:29:14 boutta

Maven非常適合幫助促進與項目結構的一致性，包括如何構建單元測試。 – rich 2008-11-19 13:45:05

我傾向於使用相同目錄中的資源來構建項目結構化的項目/ src /包和項目/測試用例/包，但我從Eclipse來到Maven而不是其他方式。無論如何，Maven允許我將源代碼目錄覆蓋到我的結構中。 – 2008-11-20 06:06:39

我有我的測試類在我的項目所在班級的。這樣我可以測試內部的東西。我將「Test」後綴添加到類名稱中。例如：MyClass.cs將MyClassTest.cs

來源

2008-11-19 13:35:37 Pokus

我們做一對一的測試程序集（C＃）。對於解決方案中的每個組件，我們都有相應的測試項目。每個項目都對相應項目中的每個班級進行測試。

例如：

Company.Product。特徵
ClassnameAlpha
ClassnameBeta
ClassnameDelta

Company.Product.Feature.UnitTests
ClassnameAlphaTests
ClassnameBetaTests
ClassnameDeltaTests

我把xando做得更進一步。我沒有使用默認的調試/發佈配置，而是針對我們用於Team Foundation Server中的構建配置的每個分支進行配置。所以，我有開發，集成和生產。沒有進入思維麻木無聊的細節，單元測試是爲開發和集成配置而構建的。它們包含在生產分支中，但未與生成一起編譯。它們包含的原因是因爲當我們必須分支生產（例如修補程序）時，可以運行，修改單元測試，並與修改的代碼進行反向集成。

由於我們正在從傳統產品和版本控制系統遷移過程中，目前我們只有一小部分使用此權利，但到目前爲止效果良好。到目前爲止，它的單元測試方面效果特別好。

來源

2008-11-19 14:07:38

我喜歡讓我的src和測試存在於同一個包中。所以我組織我的如下：

src/com/company/package/Class.java 
testsrc/com/company/package/ClassTest.java

來源

2008-11-19 14:32:21

我把它們放在整個產品的單獨包裝中。我不喜歡用單元測試代碼來混淆生產代碼。

 
Company/Product/Package1 
Company/Product/PackageN 
Company/Product/UnitTest/Package1/Class/Method1Fixture.cs 
Company/Product/UnitTest/Package1/Class/MethodNFixture.cs 
Company/Product/UnitTest/PackageN/Class/Method1Fixture.cs 
Company/Product/UnitTest/PackageN/Class/MethodNFixture.cs

我所有的方法都被宣佈爲公共虛擬，我也使用了很多嘲諷。當然，這主要來自於我單元測試的包通常是業務邏輯和數據層，所以他們很少有任何真正的內部方法。但我確實有一些有「內部」方法的項目。對於那些，如果他們是內部公司代碼，那麼使用公開所有方法不是問題。我相信如果你不想公開所有的方法，你可以使用強命名的程序集並進行設置，以便單元測試程序集可以訪問內部方法。最後，我有一個單元測試組件，它將包含整個項目的所有測試裝置。

來源

2008-11-19 17:39:12 Adrian

我喜歡讓它們保持接近它們支持的代碼，通常在一個單獨的子目錄中。這樣，我可以讓它們與代碼一起編譯，這使得它們可見 - 當僅有少數組件進行單元測試時，這一點很重要。

.../component/src/ 
       /include/ 
       /doc/ 
       /bin/ 
       /test/

我們通常每個二進制文件都有一個套件，但這有例外。我們可以用簡單的命令在任何目錄下運行所有的測試。

經驗法則是讓單元測試很容易找到，易於編譯和易於運行，使他們不會陷入困境。

來源

2008-11-27 08:03:48 philant

我有我的測試分類測試組織。如果我所有的單元測試文件都在1個目錄中。全部集成在1個目錄中。我有其他所有的持久性測試。所有文件夾都有許多文件供每個類似的測試項目使用。

來源

2008-11-27 21:10:22

UnitTest你如何組織你的測試文件？

回答

相關問題