什麼時候可以更改「完成」單元測試？

Question

我已經將我的第一個寶貝步驟帶入單元測試，並且由於對領域有更好的理解，對已打破單元測試的領域模型進行了更改。所以這提出了一個問題：

什麼時候可以更改以前的工作單元測試？

我想我錯過了單元測試的一個重要方面，在不必問這個問題......

Answer 1

對於'正確'的TDD，你先改變測試，然後改變代碼。

所以其實你從來沒有有破的測試，只有破碼。你應該總是努力處在一個位置，在這個位置上，測試是正確功能的明確表達，因此，先驗正確。

Answer 2

當你打破測試的變化：

1）首先，如果發現測試現在已經失效，或者您的更改是否打破了它不應該有的測試。 2）。如果是前者，則修復測試。否則，修復您的更改。

Answer 3

每個特定的單元測試的重點並不是它從不中斷，而是隻要它測試的功能也起作用，它就會繼續工作。這樣，對測試功能的意外更改會導致您找到的測試失敗，而不是您的最終用戶。

如果功能有意改變，那麼您應該期望看到一些測試中斷。如果你不這樣做，那麼你在測試套件中沒有足夠的覆蓋範圍。

Answer 4

需求變更時。無論您是否更改代碼，然後查看哪些測試因爲什麼原因而中斷（如Mitch所建議的），或更改測試，然後更改代碼（如Visage暗示的那樣），測試只會在功能爲時纔會更改做一些不同的事情。

Answer 5

每次你需要。

• 如果測試結果不準確或不再遵循規範，應該更改測試。
• 如果測試變得無關緊要，應該刪除測試。

問題是，您的測試應該是您的軟件應該如何工作的準確圖片。當然，這將會有點難以維持，事實上，這是TDD更大的關閉之一，僅次於測試優先編程。

Answer 6

測試是程序行爲的規範。您需要更改規格時更改它們，因爲它們是規格。有些出現在我的腦海裏...

• 當代碼需求發生變化，測試與新行爲不匹配時，應更新它們。
• 當某些要求過時時，應該刪除指定該行爲的測試。

測試代碼需要具備的主要質量是可讀性。因此，您應該定期更改測試，因爲...

• 如果測試很難閱讀並且不會顯示程序員的每一個意圖，應該重構它以提高其可讀性。

然後還有一些情況，其中測試被破壞，例如脆弱測試的併發代碼，主要是通過，但是現在然後失敗，即使代碼是正確的。在這種情況下，測試應該修復得更加可重複（可能需要將代碼更改爲更容易測試 - 最好的方法是避免/限制合適的設計模式併發）。