我的團隊正在開發已經運行好幾年的應用程序，但沒有單元測試曾經被編碼過。現在我們希望開始這樣做，我們意識到我們不可能通過所有現有的方法來測試它們，因爲這需要花費數年的時間。哪種方法絕對需要單元測試
現在的問題是：如何才能確定哪種方法絕對需要單元測試，哪些方法不需要？
你願意單元測試一個經常被調用的方法或者經常被修改的方法嗎？ 我讀過單元測試在DAO類上效率相當低。我應該將測試限制在包含邏輯的方法嗎？
最重要：只要部分應用程序是單元測試，測試是否會有用？
怎樣才能確定哪種方法絕對需要單元測試，哪個方法不行？
這是一個難以回答的問題，不知道您的代碼庫以及它的歷史和未來。但總的來說，編寫難以理解的代碼部分的測試將在不久的將來進行修改，或者已知存在錯誤。在測試遺留應用程序時，最好的方法就是進行測試，讓程序更容易維護，修復錯誤並防止舊錯誤再次發生。
你願意單元測試一個經常調用的方法或者經常修改的方法嗎？
如上所述，這取決於。被調用的方法通常微不足道？容易明白？爲了使未來的開發更容易，我可能會傾向於「經常修改」。但理想情況下，兩者都應該經過測試
我讀過單元測試在DAO類上相當低效。
我不知道你在哪裏閱讀。如果你使用模擬對象，單元測試可以非常有效地使用DAO。
只要部分應用程序是單元測試，測試是否會有用？
任何測試都很有用。測試只覆蓋10％的程序優於覆蓋率爲0％的程序。特別是如果這10％是該計劃最重要或最棘手的部分。
如果您還沒有讀過它，我強烈建議Michael Feather的與遺留代碼有效地工作，其中「遺留代碼」是指沒有測試的代碼。
我想你可能誤讀了「我應該將測試限制在包含邏輯的方法嗎？」。你似乎沒有意識到這是暴力協議;-) – 2014-11-25 14:43:43
關於DAO類，是不是模擬對象避免調用數據庫，這意味着最終你沒有真正測試它？正如鄧肯所說，我認爲最後一點有一個誤區:) – realUser404 2014-11-25 14:46:45
@ realUser404：是的，你說的沒錯。這裏的Dkatzel可能會誤解。與最後一點相同。也許你可以改進你的答案來回答*實際*點？ – 2014-11-25 14:49:15
有些人爲getter和setter創建單元測試，並堅持100％的代碼覆蓋率。
實用的人會測試那些需要測試的方法。這意味着什麼取決於你的智慧和對構成需要測試的方法的辨別力。
Some people然而，考慮一個單位的最小尺寸是類，並且測試應該被創建來測試一個類（有時它的相關類）。
簡而言之，忘記任何一種關於單元測試的教條原則，重要的是代碼的質量。就像敏捷開發一樣，它可以幫助你實現這個重要的目標。所以如果你覺得你的DAO對象不會從測試中受益，那就不要費神了 - 花那麼多時間，你會花更多的時間去做更高效的事情。
我回答了類似的問題[這裏]（https://stackoverflow.com/questions/26672866/refactoring-wpf-mvvm-for-increased-testability/26675374#26675374） - 也許它可以幫助。 – 2014-11-25 15:08:53