如何將單元測試加載到代碼庫中？

Question

你有沒有將單元測試加載到當前沒有單元測試的代碼庫上的策略？

Answer 1

閱讀Working Effectively With Legacy Code by Feathers。

吉米·博加德有good blog series on SOC。

Answer 2

這裏的another great article上測試。特別是，它的一個有點相關的引用：

這是一個可怕的想法 - 決定你將花費整整一個星期爲你的項目建立一個測試套件。首先，你可能會感到沮喪，並在測試中被燒燬。其次，你可能會首先寫出不好的測試，所以即使你寫了一堆測試，你也需要回頭重寫它們，你會發現它們有多慢，很脆弱或者不可讀。

我認爲在修正bug或添加新功能時，您最好一次性構建測試1 ...不要嘗試構建缺少的測試用例，您應該爲每個測試設定一個最終目標，而不僅僅是爲了改善覆蓋面。

Answer 3

改造現有的項目沒有任何單元測試的最佳方法是修復bug什麼時候做。編寫一個測試，其中包含錯誤的邏輯以及重現錯誤的步驟。然後重構代碼直到測試通過。現在您可以確信bug已經修復，並且不會在後面的循環中引入，並且您開始將單元測試引入到項目中。

Answer 4

戴爾被投票了。是的，將單元測試添加到正在工作的代碼中沒有任何好處。可以說有兩個未知的錯誤X & Y.在某些時候，X通常被現場使用。你修復它，添加一個單元測試，然後繼續。現在讓我們假設Y永遠不會在程序的整個生命週期中被發現。由於Y從來沒有透露過它就好像它從未存在過;無需浪費資源。乘以數百或數千個潛伏的錯誤，爲您節省大量的多餘維護。

Answer 5

要是你正試圖單元測試添加到老Perl代碼我由Ian Langworth和色彩強烈建議

Perl Testing: A Developer's Notebook。

它測試遺留代碼和「不可測試」代碼有一些非常好的技巧。

Answer 6

爲什麼要添加單元測試？你覺得代碼有錯誤嗎？你只想做點什麼嗎？你打算開始一項新功能嗎？

如果是已經發布了一段時間，然後我會跟其他人同意，只有當我發現一個bug添加測試或添加新功能的舊產品。

如果它是尚處於發展階段，並沒有公佈或只在最近發佈的一款產品，那麼我會通過審查代碼開始。如果我看到一些不太正確的東西，我會爲它添加一個測試。我可能會做一些測試來創建一些示例數據。創建示例數據似乎爲您提供了相當大的壓力，並且它也可能很有用。

我認爲有利於書寫，即使你沒有來測試一個bug測試 - 當你添加新的功能或更高版本修復bug，你的測試確認您還沒有引入新的Bug。

Answer 7

是否有可能我們處於恐慌之中，並在單元測試和性能測試之間感到困惑？是否您的應用程序對少數用戶正常工作，但在負載較重時開始發生錯誤？如果是這樣，單元測試不是答案。單元測試！=負載測試。

如果單元測試實際上是答案，那麼改進單元測試是一個好主意，因爲它有助於清理代碼。只是準備重構很多東西。使用TDD編寫的代碼看起來與使用TDD編寫的代碼看起來有很大不同。在我的情況下，我有一個方法HandleDisposition（），它處理了很多情況。如果我們用TDD編寫代碼，這種方法就不存在了。當對單元測試進行改進時，我們重構了該函數，並且現在具有像XDisposition（），YDisposition（），ZDisposition（）這樣的方法，這對於編寫單元測試來說更容易。