命名單元和集成測試方法的最佳做法是什麼？

Question

我最近繼承了不同人在不同時間編寫的應用程序，並尋找關於如何標準化的指導。

Answer 1

假設NUnit的：

[Test] 
public void ObjectUnderTest_StateChanged_Consequence() 
{ 
    Assert.That(tra_la_la); 
} 

[Test] 
public void ObjectUnderTest_Behaviour_Consequence() 
{ 
    Assert.That(tra_la_la); 
} 

例如：

[Test] 
public void WifeIsTired_TakeWifeToDinner_WifeIsGrateful() 
{ 
    Assert.That(tra_la_la); 
} 

[Test] 
public void WifeIsTired_MentionNewGirlfriend_WifeGetsHalf() 
{ 
    Assert.That(tra_la_la); 
} 

Answer 2

我遇到了兩個很好的建議。鏈接在這裏：http://slott-softwarearchitect.blogspot.com/2009/10/unit-test-naming.html

http://weblogs.asp.net/rosherove/archive/2005/04/03/TestNamingStandards.aspx

http://openmrs.org/wiki/Unit_Testing_with_@should

Answer 3

在這種情況下我可能會發現，使用最多和重構代碼的其餘部分使用的命名約定。如果最常用的是真的很可怕，我仍然會看現有的代碼，並試圖找到一個可以與之共存的代碼。一致性比任意慣例更重要。

Answer 4

我使用FunctionTestCondition構造。如果我有兩個方法，Get和Set我也許會創建以下測試方法：

• GetTest是一個積極的測試（一切正常）。
• GetTestInvalidIndex測試傳遞給方法的無效索引。
• GetTestNotInitialized用於測試數據在使用前未被檢測的時間。
• SetTest
• SetTestInvalidIndex
• SetTestTooLargeValue
• SetTestTooLongString

Answer 5

它的啓發看看BDD（行爲驅動開發）和this blog post尤其如此。

BDD本質上集中在組件上，他們應該做什麼。因此，它會直接影響您如何命名/構建測試，以及它們用於設置條件和驗證的代碼。 BDD不僅允許開發人員讀/寫測試，而且團隊中的非技術成員（業務分析師等）可以通過指定測試和驗證測試來做出貢獻。

Answer 6

我只寫了它的用途。這不像是你必須在其他地方輸入名字，所以有testWibbleDoesNotThrowAnExceptionIfPassedAFrobulator不是一個問題。任何測試都是以「測試」開始的，顯然。

Answer 7

通過設置對您的測試進行分組，圍繞此設置製作一個測試類，名稱使用後綴Test或IntegrationTest。使用像JUnit或TestNG這樣的測試框架，您可以根據需要爲測試方法命名。我會將該方法命名爲它測試的內容，一個駱駝案例，而不是測試前綴。該框架使用一個@Test註釋將方法標記爲測試。

Answer 8

沒有標準正因爲如此，不同的人/地方都會有不同的方案。重要的是你堅持爲標準。

個人，我的下面的風扇 - 在C＃示例代碼，但非常接近的Java，適用同樣的規則：

[Test] 
public void person_should_say_hello() 
{ 
    // Arrange 
    var person = new Person(); 
    // Act 
    string result = person.SayHello(); 
    // Assert 
    Assert(..., "The person did not say hello correctly!"); 
} 

明確

該測試的名稱應該有的名稱被測試的類別。在這個例子中，被測試的類是Person。測試名稱還應具有正在測試的方法的名稱。這樣，如果測試失敗了，你至少知道在哪裏尋找解決方法。我還建議遵循AAA - Arrange, Act, Assert規則，這將確保您的測試易於閱讀和遵循。

場所的失敗消息

當涉及到斷言結果/狀態，其有用的是包括一個可選的消息。這使得測試失敗時更容易，特別是作爲構建過程的一部分運行或通過外部工具運行時。

下劃線

最後的（雖然是可選的）立場，我所遵循的是使用測試名稱中使用下劃線。雖然我並不喜歡生產代碼中的下劃線，但它們在測試名稱中的使用非常有用，因爲測試名稱通常要長得多。快速瀏覽一個使用下劃線的測試名稱，證明其可讀性更高，儘管這是主觀的，並且是單元測試實踐中爭論的焦點。

集成測試

同樣的標準適用於集成測試，唯一的區別是這樣的測試應是從單元測試分開的位置。在上面的示例代碼中，測試類將被稱爲PersonTests，並位於名爲PersonTests.cs的文件中。集成測試將以類似的方式命名 - PersonIntegrationTests，位於PersonIntegrationTests.cs。同一個項目可以用於這些測試，但確保它們位於不同的目錄中。