在單元測試設計中，很容易陷入實際調用實現邏輯的陷阱。設計一個強大的單元測試 - 以幾種不同的方式測試相同的邏輯？
例如，如果測試一個整數應該比另一個（2,4,6,8等）高的兩個整數的數組，它真的足以從該方法獲得返回值，並斷言這模式是這樣嗎？
我錯過了什麼嗎？它看起來像是一個單一的單元測試方法需要通過幾種方式測試相同的期望更健壯。所以上述期望可以通過檢查兩個增加的情況來確定，但下一個數字可以被2整除。或者這只是多餘的邏輯？
因此總之，單元測試應該以幾種方式測試一個期望？例如，如果我想測試我的褲子是否適合我，我會/可以測量其長度，將它放在我的腿旁邊並查看比較等。這是單元測試所需的邏輯嗎？
感謝
你的單元測試應該檢查所有的假設。無論您是在1項測試中進行還是多項測試都是個人偏好。
在上面所述的例子中，您有兩個不同的假設：（1）每個值應增加2.（2）所有值均應爲偶數。
應該（-8，-6，-4，-2）通過還是失敗？
請記住，確保您的代碼失敗時，它應該是同樣重要的，如果不是更重要，那麼確保它在應有的時候通過。
_你是否在1次測試中做到這一點，或者多次測試是個人偏好。我不同意。測試應儘可能小，儘可能簡單，專門命名，並測試一件事。 – 2010-10-01 01:15:08
@託尼恩尼斯：我同意你的意見，但不打算開始一場神聖的戰爭:-) – Snekse 2010-10-01 14:46:21
嘿沒有戰爭的意圖;-) – 2010-10-01 17:26:05
如果斷言你的數組包含2,4,6,8 - 那麼你的測試邏輯可能是缺陷，因爲你的測試會通過，如果你剛回到那些元素的數組，但與，比如6,8,10,12。您需要測試該計算是否正確。所以你需要用多個數組來測試它，在這種情況下。
我發現，要確保測試失敗，則使測試通過，在TDD的真正精神，有助於沖洗出正確的測試是什麼...
您正在測試的數組必須以某種邏輯生成。測試此邏輯以確保生成的數組始終滿足您的要求會更好嗎？
例如，如果測試的 整數數組，它都應該是比其他（2，4，6，8，等）兩個較高 ，是 它確實足以讓從返回 值該方法並斷言 這種模式是這樣嗎？
也許你需要考慮更多關於如何使用函數。它會用於非常大的數字嗎？如果是這樣，你可能想要嘗試一些非常大的數字。它會與負數一起使用嗎？
我錯過了什麼嗎？它看起來似乎是 就像一個單元測試方法需要 通過在幾個方面測試相同的期望更健壯。所以 以上的期望可以斷言 通過檢查增加兩個是 的情況發生，而且下一個數字是 整除2.或者這只是 冗餘邏輯？冗餘邏輯？
嗯......好吧1,3,5,9會通過assertEachValueIncrementsByTwo測試，但它不會通過assertValuesDivisibleByTwo測試。他們可以被2整除是否重要？如果是這樣，那麼你真的應該測試。如果沒有，那麼這是一個毫無意義的冗餘測試。
您應該嘗試爲您的方法找到超過1個測試，但爲了進行更多測試而進行的冗餘測試不會對您有所幫助。如果真的不需要添加assertValuesDivisibleByTwo測試，只會讓後來嘗試修改代碼的開發人員感到困惑。
如果您不能想到更多的測試，請嘗試編寫隨機輸入函數，每次運行測試時都會生成100個隨機測試數組。當您只檢查一個或兩個輸入設置時，您會驚訝地發現有多少錯誤在雷達下面逃脫。
我推薦多個測試。如果您需要改變行爲，您希望儘可能少地進行測試。這也使得更容易找到問題所在。如果你真的打擊了實現並得到[1,3,4,5]，那麼你的一個測試將會失敗，但是當實際上存在兩個不同的問題時，你只會首先測試一個失敗。
嘗試命名您的測試。如果你不能用一個明確的方法名稱說明你正在測試的是什麼，那就分解測試。
testEntriesStepByTwo
testEntriesAllEven
另外不要忘記邊緣情況。空列表可能會通過'每個條目比以前多2個'，'所有條目都是'測試，但是它應該如何？
因此，上述期望可以通過檢查兩個增加的情況來確定，但下一個數字也可以被2整除。或者這只是多餘的邏輯嗎？這是多餘的。也可能是錯誤的 - 如果規範說「兩個多」，那麼5 7是正確的。但7不能被2整除（均勻，yadda） – 2010-10-01 01:10:18