2010-06-28 62 views
5

我正在用VB.NET和NUnit學習TDD。我想知道什麼是最好的做法:在測試方法中使用很多Assert方法或使用每個方法的assert方法?VB.NET和NUnit - TDD

這是我的代碼。謝謝。

Imports NUnit.Framework 

<TestFixture()> _ 
Public Class CalculatorTest 
<Test()> _ 
Public Sub TestAdd() 
    Dim calculator As Calculator = New Calculator() 

    Assert.AreEqual(2, calculator.sum(1, 1)) 
    Assert.AreNotEqual(3, calculator.sum(2, 2)) 
    Assert.AreEqual(-1, calculator.sum(0, -1)) 
     Assert.AreNotEqual(3, calculator.sum(1, 1)) 
    End Sub 
End Class 

回答

5

普遍接受的「最佳實踐」是每個測試的一個斷言。 (據羅伊Osherove)

然而,這種特殊的測試可能做了一些更簡單地與NUnit的使用的TestCase:

<Test()> _ 
<TestCase(1, 1, 2)> _ 
<TestCase(1,-1, 0)> _ 
<TestCase(0,-1,-1)> _ 
Public Sub Calculator_Add_ReturnsExpectedResult(Integer a, Integer b, Integer expected) 
    Dim calculator As Calculator = New Calculator() 

    Assert.AreEqual(expected, calculator.sum(a, b)) 
End Class 

另外請注意我用那裏的命名,以澄清正是考驗正在測試。

「One As Per Per Test」實踐背後的原理是,您希望失敗的測試意味着非常具體的東西。也就是說,每個測試都會告訴你一個特定的事情是否正在工作。

+0

_:這是什麼意思?謝謝。 – Thomas 2010-06-28 12:45:38

+0

這意味着它會多次調用您的測試函數,每個函數都有不同的輸入(如註釋中所指定的)。在這種情況下,它會調用它三次,首先是(1,1,2),然後是(1,-1,0),最後是(0,​​-1,-1)。 – 2010-06-28 12:47:48

+0

謝謝,我明白了! – Thomas 2010-06-28 13:01:25

0

這是一個有趣的辯論,可以歸結爲一個風格問題。 我喜歡Roy Osherove的觀點,你應該只有一個斷言每單元測試。

請閱讀他對此問題的深入討論here

另外,檢查this了。

+0

這不是一個真正的「辯論」,更多的是一種風格的討論。我更喜歡在每個測試中使用多個斷言,並且發現大多數真實世界的單元測試都需要多個斷言來清除給定測試的所有假設。 – 2010-06-28 12:41:09

+0

謝謝,我會讀它! – Thomas 2010-06-28 12:46:05

7

想一想更好的方法就是一次測試一件東西。根據需要使用盡可能多的斷言來測試這件事,但通常只有一件。多次斷言可能表示您一次測試多件事,但在我看來,這不是一條堅強而快速的規則。最好的指導是你不想在獨立概念之間的測試中創建依賴關係。

在你的例子中,你實際上正在測試4件事,儘管你實際上可能只需要其中的兩件,因爲它們覆蓋了相同的地面。我建議測試當你添加兩個正數,兩個負數,一個負數和一個積極的負數和積極結果時會發生什麼。然後我會考慮數學性質和測試交換性以及附加標識(零)。最後,我會測試邊界條件 - 正面和負面溢出等。請注意,這可能是也可能不是全面的,即我認爲我已經涵蓋了基礎,但我並不努力要窮盡;我只想說明你如何去思考要寫什麼樣的測試,是的,我會用單個斷言來完成每個單獨的測試。

對於更復雜的事情,您可能有多個聲明測試相同的「事物」 - 例如,您可能想要檢查一行是否已正確插入到具有給定輸入集的數據庫中。我認爲完全可以接受的是,在單個測試中測試所有列都具有合適的值,而不是單獨測試每個屬性。其他人可能會有所不同,但我不認爲在這種情況下,通過測試所有屬性具有正確的值來創建任何依賴關係,因爲插入是原子操作。

+0

一個很好的解釋。謝謝! – Thomas 2010-06-28 13:03:19

0

奧舍羅夫的觀點含有原教旨主義。例如,如果一個函數返回一個結構體/類,那麼你要麼必須使用幾個斷言,要麼做一個自定義結構來比較斷言,這實際上只是做同樣的事情。

重要的是測試功能的功能。也許總是質疑「專家」。