我應該更改單元測試的命名約定嗎？

我目前對我的單元測試使用了一個簡單的約定。如果我有一類名爲「EmployeeReader」，我創建了一個名爲「EmployeeReader.Tests測試類，然後我創建測試類的類的所有測試用的名字，如：我應該更改單元測試的命名約定嗎？

Reading_Valid_Employee_Data_Correctly_Generates_Employee_Object
Reading_Missing_Employee_Data_Throws_Invalid_Employee_ID_Exception

等。

我最近一直在閱讀有關BDD使用different type of naming convention，我喜歡這種命名的可讀性，T ø用的測試列表結束類似：

When_Reading_Valid_Employee（夾具）
- Employee_Object_Is_Generated（方法）
- Employee_Has_Correct_ID（方法）
When_Reading_Missing_Employee（夾具）
- An_Invalid_Employee_ID_Exception_Is_Thrown（method）

等等。

有沒有人使用過這兩種風格的命名？你能否提供任何建議，好處，缺點，疑難問題等來幫助我決定是否切換下一個項目？

來源

2009-06-19 BlackWasp

你的第二個例子（每個邏輯「任務」有一個夾具，而不是每個類的一個），其優點是你可以爲每個任務設置不同的SetUp和TearDown邏輯，從而簡化你的單獨測試方法並使它們更具可讀性。

您不需要將其中一個作爲標準。我們將兩者混合使用，這取決於我們必須爲每個班級測試多少個不同的「任務」。

來源

2009-06-19 15:17:29

我覺得第二個更好，因爲它讓你的單元測試對其他人更易讀，因爲長的代碼讓代碼看起來更難以閱讀或使其更難以瀏覽。如果您仍然覺得測試所做的任何含糊不清的事情，您可以添加註釋來澄清這一點。

來源

2009-06-19 15:23:33 mnuzzo

我一直在使用的命名規則是：

functionName_shouldDoThis_whenThisIsTheSituation

例如，這些將是一個堆棧的 '流行' 功能

pop_shouldThrowEmptyStackException_whenTheStackIsEmpty一些測試名

pop _shouldReturnTheObjectOnTheTopOfTheStack_whenThereIsAnObjectOnTheStack

來源

2009-06-19 15:29:34 ampersandre

部分您引用的第二個命名約定的理由是要創建在同一時間測試和行爲規範。你建立了事情發生的背景，以及在這種背景下實際發生的事情。（在我的經驗，意見/測試方法往往會開始「should_，」所以你得到一個標準的「When_the_invoicing_system_is_told_to_email_the_client」，「should_initiate_connection_to_mail_server」格式）。

有跡象表明，將反映在您的測試夾具和輸出工具很好地格式化的HTML規格表，剝離下劃線。您最終得到與實際代碼同步的人類可讀文檔（只要您保持測試範圍的高度和準確性）即可。

根據您工作的故事/功能/子系統，非程序員利益相關者可以向非程序員利益相關者展示和理解這些規範，以進行驗證和反饋，尤其是敏捷和BDD的核心。

來源

2009-07-03 04:28:13 Jay

我投調用測試用例類：EmployeeReaderTestCase並調用方法（）之類http://xunitpatterns.com/Organization.html和http://xunitpatterns.com/Organization.html#Test%20Naming%20Conventions

來源

2009-07-03 04:47:04

我用第二種方法，並與描述你的軟件應該做它確實有幫助。我也使用嵌套類來描述更詳細的上下文。

實質上，測試類是上下文，可以嵌套，方法都是一行斷言。例如，

public class MyClassSpecification 
{ 
    protected MyClass instance = new MyClass(); 

    public class When_foobar_is_42 : MyClassSpecification 
    { 
     public When_foobar_is_42() { 
      this.instance.SetFoobar(42); 
     } 

     public class GetAnswer : When_foobar_is_42 
     { 
      private Int32 result; 

      public GetAnswer() { 
       this.result = this.GetAnswer(); 
      } 

      public void should_return_42() { 
       Assert.AreEqual(42, result); 
      } 
     } 
    } 
}

，這將給我按照我的測試運行器輸出：

MyClassSpecification+When_foobar_is_42+GetAnswer 
    should_return_42

來源

2009-07-27 01:03:06

我一直在下降，你在你的問題描述了兩條道路，以及一些其他的...對於大多數人來說，你的第一個選擇非常簡單易懂。我個人更喜歡BDD風格（你的第二個例子），因爲它隔離了不同的上下文，並在這些上下文中分組觀察。唯一真正的缺點是它會生成更多的代碼，所以開始做這件事情會感覺稍微麻煩一些，直到你看到整潔的測試。此外，如果您使用繼承來重新使用燈具設置，則需要一個輸出繼承鏈的testrunner。考慮一個類「An_empty_stack」，你想重用它，所以你做了另一個類：「When_five_is_pushed_on：An_empty_stack」你想要的是輸出，而不是「When_five_is_pushed_on」。如果你的testrunner不支持這個，你的測試將會包含冗餘的信息，比如：「When_five_is_pushed_on_empty_stack：An_empty_stack」只是爲了讓輸出更好。

來源

2009-08-21 05:11:24 Cellfish

我應該更改單元測試的命名約定嗎？

回答

相關問題