2008-09-06 78 views
17

如果單元測試名稱會隨着時間的推移而過時,並且如果您認爲測試本身是最重要的,那麼選擇明智的測試名稱很重要嗎?單元測試名稱很重要嗎?

[Test] 
public void ShouldValidateUserNameIsLessThan100Characters() {} 

詩句

[Test] 
public void UserNameTestValidation1() {} 

回答

18

任何方法的名稱都應該清楚它的作用。

IMO,你的第一個建議有點長,第二個建議不夠豐富。在名字中加上「100」也許是個壞主意,因爲這很可能會改變。如何:

public void validateUserNameLength() 

如果測試更改,名稱應該相應地更新。

1

我不會把該測試需要在名稱滿足條件,因爲條件可能隨時間而改變。在你的榜樣,我建議命名像

UserNameLengthValidate() 

UserNameLengthTest() 

或類似的說明測試做什麼東西,但沒有假設測試/驗證參數。

2

我認爲如果找不到測試方法的簡明名稱,這是一個跡象表明此測試的設計不正確。同樣好的方法名稱可以幫助您在更短的時間內找出發生的事情。

0

該名稱需要在合理範圍內處理。我不希望構建電子郵件說測試389fb2b5-28ad3失敗,但只是知道這是一個用戶名測試而不是別的東西,這將有助於確保合適的人進行診斷。

1

是的,被測代碼的名稱(方法,屬性,任何)都可以改變,但是我認爲如果期望值改變,你現有的測試應該會失敗。這是構造良好的測試的真正價值,而不是閱讀測試名稱列表。話雖如此,有名的測試方法是獲取新開發人員的好工具,幫助他們找到「可執行文檔」,以便他們可以摒棄現有代碼 - 所以我會保持測試方法的名稱爲最新因爲我會保持更新測試方法的斷言。

我使用以下模式命名我的測試。每個測試夾具都試圖專注於一個類,通常是名稱{ClassUnderTest}測試。我將每個測試方法命名爲{MemberUnderTest} _ {Assertion}。

[TestFixture] 
public class IndexableFileTest 
{ 
    [Test] 
    public void Connect_InitializesReadOnlyProperties() 
    { 
    // ... 
    } 

    [Test,ExpectedException(typeof(NotInitializedException))] 
    public void IsIndexable_ErrorWhenNotConnected() 
    { 
    // ... 
    } 

    [Test] 
    public void IsIndexable_True() 
    { 
    // ... 
    } 

    [Test] 
    public void IsIndexable_False() 
    { 
    // ... 
    } 
} 
7

很。與選擇好的方法和變量名同等重要。
如果您的測試套件將在未來由新開發人員引用,則還有更多。

至於你的原始問題,絕對答案1。輸入幾個字符是一個小的代價支付

  • 的可讀性。爲了你和其他人。它會消除'我在這裏想什麼?'以及'跆拳道是這個人在這個測試中得到?'
  • 快速放大,當你在修復別人寫的東西
  • 即時更新任何測試套件訪問者。如果正確完成,只要查看測試用例的名稱就會通知讀者該單元的規格。
6

是的。

[Test] 
public void UsernameValidator_LessThanLengthLimit_ShouldValidate() {} 

把測試主題放在第一位,測試語句在下,測試結果在最後。
這樣,你得到它是做什麼的明確指示,你可以輕鬆地按名稱排序:)

+0

這就是我喜歡的方式! – 2009-05-20 12:59:52

2

是,測試名的整個的一點是,它會告訴你什麼不工作時,測試失敗。

0
[RowTest] 
[Row("GoodName")] 
[Row("GoodName2")] 
public void Should_validate_username() 
{ 
} 

[RowTest] 
[Row("BadUserName")] 
[Row("Bad%!Name")] 
public void Should_invalidate_username() 
{ 
} 

對於更復雜的確認類型,這可能更有意義。

10

是的,名稱是非常重要的,尤其是當您在控制檯或持續集成服務器上運行測試時。 Jay Fields寫了一個post about it

此外,把好的測試名稱與one assertion per test和你的套件會給你很好的報告,當一個測試失敗。

+0

+1對於每個測試的一個斷言 – 2009-05-20 12:59:14

1

具有非常具有描述性的名稱有助於即時查看哪些功能無法正常工作,因此您實際上不需要查看單元測試代碼。另外,所有單元測試的列表描述了單元的預期行爲,並且可以(或多或少)用作被測單元行爲的文檔。

請注意,這隻適用於單元測試非常具體且在單元測試中不會驗證太多的情況。

因此,例如:

[Test] 
void TestThatExceptionIsRaisedWhenStringLengthLargerThen100() 

[Test] 
void TestThatStringLengthOf99IsAccepted() 
5

Clean Code,第124頁,Robert C. Martin寫道:

這個故事的寓意很簡單:測試代碼是一樣的生產代碼一樣重要。它不是二等公民。它需要思考,設計和關懷。它必須像生產代碼一樣保持清潔。

相關問題