刪除或註釋掉非工作的JUnit測試？

Question

我目前正在構建遺留應用程序的CI構建腳本。有零星的JUnit測試可用，我將把所有測試的JUnit執行集成到CI構建中。但是，我想知道如何處理我在非維護的JUnit測試中遇到的100個故障。難道我：

1）註釋出來，因爲他們似乎有合理的，如果沒有維護，業務邏輯在他們希望有人最終取消註釋它們，將它們固定

2）刪除它們作爲其不太可能有人將修復它們，註釋掉的代碼只會被忽略或混亂不斷

3）追蹤那些在我手中留下這個爛攤子的人，並用代碼的打印輸出將他們打在頭上（這是由於長效氣味將足以滿足這項任務），同時宣揚維護良好且經過單元測試的代碼庫的好處

Answer 1

• 將它們註釋掉，以便稍後修復它們。
• 生成測試覆蓋率報告（例如Cobertura）。然後，將被指定爲由您註釋掉的測試覆蓋的方法將被指示爲不包含在測試中。

Answer 2

如果它們編譯但失敗：將它們放入。這將使您在使用CI時隨着時間推移改進測試的良好歷史記錄。如果測試不能編譯但是破壞構建，請將它們註釋掉，然後讓開發人員修復它們。

這顯然不排除使用選項3（將它們擊中頭部），無論如何，您都應該這樣做，無論您如何進行測試。

Answer 3

如果您使用Junit 4，則可以使用@Ignore annotation註釋該測試。

如果您使用JUnit 3，您可以重命名測試，以便它們不以test開頭。

此外，嘗試修復您正在修改的功能的測試，以免使代碼混亂更大。

Answer 4

我不知道你在公司的位置，但是如果有可能將他們留下並將問題存檔爲票務系統中的錯誤。留給開發者去修復它們或者移除測試。

如果這樣做不起作用，請刪除它們（您有版本控制權，對嗎？），然後用「刪除失敗的junit測試顯然不會被修復」或更有禮貌的註釋關閉票證。

關鍵是，junit測試是應用程序代碼，因此應該工作。這就是開發者獲得報酬的原因。如果測試不再合適（不再存在的東西已經過測試），開發人員應該發出信號並刪除測試。

Answer 5

按照no broken window原則和採取一些行動朝着問題的解決方案。如果你不能修復測試，至少：

1. 忽略它們從單元測試（有不同的方法來做到這一點）。
2. 根據需要輸入儘可能多的問題，並指派人員修復測試。

然後防止這種情況在將來發生的事情，在安裝一個類似插頭Hudson Game Plugin。人們在持續整合期間得到分配點，例如

• -10打破建立< - 壞
• -1打破了測試
• +1修復試驗
• 等

真是太爽了工具來創建感責任關於團隊內的單元測試。

Answer 6

你現在肯定應該以某種方式禁用它們。無論是通過評論，刪除（假設你可以從源代碼控制中恢復它們）或其他方式完成，取決於你。您不希望這些失敗的測試成爲嘗試提交新更改的人員的障礙。

如果您覺得自己可以修復它們的程度還不夠，那麼可以這樣做。如果它們太多，那麼我傾向於採用「衆包」方法。提交每個失敗測試的錯誤。嘗試將這些錯誤分配給測試/測試代碼的實際所有者/作者（如果可能的話），但如果難以確定，那麼只要您告訴人們重新分配錯誤分配給他們的錯誤，隨機選擇就沒有問題。然後鼓勵人們通過給他們一個截止日期或定期通知每個人進度並鼓勵他們修復所有錯誤來修復這些錯誤。

Answer 7

穩定的紅色CI系統是非常沒有價值的。主要好處是保持質量標準，如果沒有過渡來標記質量下降，這會變得更加困難。

因此，立即的努力應該是禁用失敗的測試，併爲每個測試創建一個跟蹤工單/工作項目。但是，如果沒有人關心測試，就可以解決這些問題。如果失敗表示需要在發貨前解決的問題，則請停用測試。

一旦處於這種狀態，您現在可以依靠CI系統告訴您需要採取緊急措施 - 回滾最後一次更改，或立即讓團隊解決問題或任何其他問題。

Answer 8

發生故障的JUnit測試表明，無論是

1. 被測源代碼已經制作而不被保持測試。在這種情況下，選項3絕對值得考慮，或者
2. 你有一個真正的失敗。

無論哪種方式，你需要修復/審查測試/來源。因爲你的工作聽起來像是創建CI系統而不是修復測試，所以在你的位置上我會在測試中留下一個定時炸彈。你可以很花哨與JUnit 4中（像@IgnoreUntil(date="2010/09/16")）和一個可定製的運行註解的方法，所以也可以簡單地添加一個if語句來每個測試的第一行：

if (isBeforeTimeBomb()) { 
    return; 
    } 

凡isBeforeTimeBomb()可以簡單地根據您選擇的未來日期檢查當前日期。然後，按照其他人的建議，並通知開發團隊，現在構建爲綠色，但可能會在X天內爆炸，除非經過時間測試的測試已修復。