我應該把我的測試代碼放在哪個班級？

Question

所以我寫了一個類，我有代碼來測試它，但是我應該把代碼放在哪里？ 我可以為類創建一個靜態方法Test（），但是在生產過程中不需要那樣，並且會使類聲明變得混亂。 一些搜索告訴我將測試代碼放在一個單獨的項目中，但該項目的格式到底是什么？ 一個靜態類，每個類都有一個方法，所以如果我的類被稱為Randomizer，那么該方法將被稱為testRandomizer？

有關組織測試代碼的最佳實踐是什么？

編輯：我最初使用我認為相關的各種語言來標記問題，但似乎問題的總體答案可能是“使用測試框架”，這是特定於語言的。 ：d

Answer 1

無論您是否使用測試框架（我強烈建議這樣做），單元測試的最佳位置是單獨的程序集（C / C ++ / C＃）或程序包（Java）。

您只能訪問公共和受保護的類和方法，但是單元測試通常只測試公共API。

我建議您為每個現有項目/程序集/包添加一個單獨的測試項目/程序集/包。

項目的格式取決於測試框架 - 對於.NET測試項目，使用內置在測試項目模板中的VS或VS版本中的NUnit不支持單元測試，對於Java使用JUnit，對於C / C ++可能是CppUnit （我沒試過這個）。

測試項目通常包含一個靜態類初始化方法，一個靜態類拆除方法，一個用於所有測試的非靜態初始化方法，一個用於所有測試的非靜態拆除方法和一個用於每個測試的非靜態方法+任何其他方法加。

靜態方法允許您復制dll，設置測試環境並清除測試環境，非靜態共享方法用於減少重復代碼以及用於准備測試特定輸入，預期輸出和比較它們的實際測試方法。

Answer 2

放置測試代碼的位置取決於您打算如何處理代碼。 如果它是一個獨立的類，例如，您打算讓其他人下載和使用，那么測試代碼應該是解決方案中的項目。 測試代碼除了提供類正在執行您希望它執行的操作的驗證之外，還會為您的類的用戶提供示例，因此它應該有詳細記錄並且非常清晰。

另一方面，如果您的類是庫或DLL的一部分，並且只能在該庫或DLL的生態系統中工作，那么應該有一個測試程序或框架將DLL作為一個實體進行操作。 代碼覆蓋工具將證明測試代碼實際上是在執行代碼。 根據我的經驗，這些測試程序與單個類程序一樣，構建為構建DLL或庫的解決方案中的項目。

請注意，在上述兩種情況下，測試項目都不是作為標准構建過程的一部分構建的。 你必須專門構建它。

最后，如果您的類要成為更大項目的一部分，那么您的測試代碼應該成為為更大團隊定義的任何框架或流程的一部分。 例如，在我當前的項目中，開發人員單元測試維護在一個單獨的源控制樹中，該樹的結構與發貨代碼的結構平行。 開發和測試團隊需要進行單元測試以通過代碼審查。 在構建過程中（現在每隔一天），我們構建運輸代碼，然后是單元測試，然后是QA測試代碼集。 單元測試在QA代碼之前運行，所有必須通過。 這幾乎是一個冒煙測試，以確保我們沒有打破最低級別的功能。 需要進行單元測試以生成故障報告並使用負狀態代碼退出。 但是，我們的流程可能比許多流程更正式。

Answer 3

在Java中，您應該使用Junit4，或者使用IDE（或者我認為更好）使用IDE。 我們使用了三種環境：Eclipse，NetBeans和Maven（使用和不使用IDE）。 如果不系統地部署，這些之間可能存在一些輕微的不兼容性。

通常，所有測試都在同一個項目中，但在不同的目錄/文件夾下。 這樣一堂課：

org.foo.Bar.java

會考試

org.foo.BarTest.java

它們位於同一個包（org.foo）中，但會在目錄中組織：

src/main/java/org/foo/Bar.java 

和

src/test/java/org/foo/BarTest.java 

這些目錄被Eclipse，NetBeans和Maven普遍認可。 Maven是最挑剔的，而Eclipse並不總是強制嚴格。

你可能應該避免調用其他類TestPlugh或XyzzyTest，因為一些（舊的）工具會將它們作為包含測試的選擇，即使它們沒有。

即使您只對您的方法進行一次測試（並且大多數測試機構希望更多地測試邊緣情況），您也應該安排這種類型的結構。

編輯請注意，Maven能夠創建沒有測試的發行版，即使它們位於同一個包中。 默認情況下，Maven還要求在部署項目之前通過所有測試。

Answer 4

我見過或使用的大多數設置都有一個單獨的項目，其中包含測試。 這使得它更容易和更清潔。 作為一個單獨的項目，您可以輕松部署代碼，而無需擔心測試是實時系統的一部分。

隨着測試的進行，我看到了單元測試，集成測試和回歸測試的單獨項目。 其中一個主要思想是盡可能快地運行單元測試。 由於測試的性質（連接到數據庫等等），集成和回歸測試往往需要更長的時間。

Answer 5

我通常在同一個項目中的不同源代碼樹中創建並行包結構。 這樣，您的測試可以訪問被測試類的公共，受保護甚至包私有成員，這通常很有用。

例如，我可能有

myproject
    src
        main
            com.acme.myapp.model
                User
            com.acme.myapp.web
                RegisterController
        test
            com.acme.myapp.model
                UserTest
            com.acme.myapp.web
                RegisterControllerTest

Maven做到了這一點，但這種方法與Maven沒有特別的聯系。

Answer 6

這取決於您使用的測試框架。 JUnit，NUnit，還有其他什么？ 每個人都會記錄一些組織測試代碼的方法。 此外，如果您使用持續集成，那么這也會影響您放置測試的位置和方式。 例如， 本文討論了一些選項。

Answer 7

在與代碼相同的解決方案中創建新項目。

如果您正在使用c＃，那么Visual Studio將為您執行此操作，如果您選擇測試>新測試...它有一個向導將指導您完成整個過程。

Answer 8

哼。 你想測試隨機數生成器...可能會更好地創建算法正確性的強大數學證明。 否則，您必須確保生成的每個序列都具有所需的分布

Answer 9

對於C＃和Visual Studio 2010，您可以從模板中創建一個測試項目，該模板將包含在項目的解決方案中。 然后，您將能夠指定在項目構建期間要觸發的測試。 所有測試都將存在於單獨的程序集中。

否則，您可以使用NUnit程序集 ，將其導入到您的解決方案中，並開始為您需要測試的所有對象創建方法。 對於更大的項目，我更喜歡將這些測試放在一個單獨的程序集中。

您可以生成自己的測試，但我強烈建議您使用現有的框架。

Answer 10

為單元測試，集成測試和功能測試創建單獨的項目。 即使您的“真實”代碼有多個項目，您也可以為每個測試類型執行一個項目，但區分每種類型的測試很重要。

對於單元測試，您應該創建並行命名空間層次結構。 所以如果你有crazy.juggler.drummer.Customer，你應該在crazy.juggler.drummer.CustomerTest中進行單元測試。 這樣很容易看出哪些類是經過適當測試的。

功能和集成測試可能更難以放置，但通常您可以找到合適的位置。 數據庫層的測試可能屬於my.app.database.DatabaseIntegrationTest。 功能測試可能需要它們自己的命名空間：my.app.functionaltests.CustomerCreationWorkflowTest。

但提示＃1：要分開各種測試是很難的。 特別要確保將單元測試集合與集成測試分開。