編寫測試重現錯誤的最佳做法

Question

我正在努力研究如何編寫重現尚未解決的問題的測試。

如果一個寫測試和使用錯誤的預期，一旦修復bug的開發者會看到該故障並調整預期或者應該只寫有正確的預期測試並禁用它。一旦修復，您必須重新啓用它。

我寧願錯定義的期望和評論中添加正確的人的方式，一旦我解決問題，我會立即得到它發生故障的通知。如果我禁用它，我不會看到它失敗，它可能會保持禁用，直到有人會發現這個測試。

有沒有其他方法可以做到這一點？

感謝您的意見。

馬丁

Answer 1

理想情況下，你會寫一個測試重現錯誤，然後修復所述錯誤。

如果無論出於何種原因，目前還不是一種選擇，我會說你錯誤期望的方法會比忽略測試更好。假設您使用了一些明確的變量名稱/方法名稱/註釋，則測試更多是佔位符，而不是期望的結果。

我做的一件事是寫一個測試，它是一個「定時炸彈」的提醒。我選擇一個從現在開始的幾個星期/幾個月的日期，我希望能夠回到它或者讓它修復。如果我最終不得不推出這個日期2到3次，我最終會刪除這個測試，因爲它一定不是那麼重要。

Answer 2

爲@Jarred說，最好的辦法是寫一個測試，表達正確的預期，檢查它是否失敗，然後修復的生產代碼，看看測試通過。

如果它不是一個選項，那麼請記住，測試不僅是爲了測試，而且是爲了文檔。所以編寫一個測試，記錄你的程序如何實際工作。如有必要，在測試中添加評論。並且不要編寫被忽略的測試 - 這是毫無意義的。將來你可以多次重構你的代碼，你可能會意外地修復這個測試，或者在這個領域引入更多的錯誤。編寫試圖被長期忽視的測試只是浪費時間。

不要怕，你會忘記那個特定的錯誤/測試，只需在您的問題跟蹤系統中創建一張票 - 這就是它的製作。

如果您使用支持組的測試框架，則可以添加所有這些測試，以便在需要時立即排除這些測試。

另外我真的不喜歡'定時炸彈測試'的概念。你的構建必須是可重複的 - 這是發佈管理，持續集成，將代碼傳遞給另一個團隊的基本假設。測試並不是要跟蹤和提醒問題，而是問題跟蹤系統的工作。嚴重的是，不要這樣做

Answer 3

其實我又想過了。我們使用JUnit，它支持通過@Test（預期= Exception.class）定義對異常的期望。

那麼，什麼人可以做的是寫與所需的期望測試，並與@Test（預期= AssertionError.class）定義測試。一旦測試得到解決，測試開始失敗，開發人員必須消除期望。