如何用很少的單元對代碼進行單元測試

Question

如何爲現有的和已經實現的代碼編寫單元測試，這些代碼採用了過程實現而不是OOP實現。我們使用的是Java/Spring，但是對於不同的問題，沒有很多不同的bean，它們都被混合到每個主要功能的一個大類中。 （EG：我們對每個批處理作業都有類/ bean，對於我們的DAO和幾個util類型bean，就是這樣）。

爲了給出更多的細節，這些需要測試的主要類是大約1k-2k行代碼，並且他們使用的唯一依賴注入/ OOP是DAO和一些奇怪的實用程序。他們有大約1種公共方法，他們實現了他們共享的界面。

Answer 1

從重構開始。現代IDE將允許您安全地重構，而不會破壞或更改代碼語義。但你必須有意識地做到這一點，並做到明智。

從不是任何其他類的依賴關係的「外部」類開始。

第一步是儘可能多地提取方法。通常當你發現一個巨大的方法有大量的空行/評論分隔代碼塊，他們是很好的候選人提取。還應考慮循環，嵌套條件，長期等等。

一旦你有過多的好名字方法環顧四周，並嘗試通過上下移動他們。如果某些方法緊密耦合且邏輯相關，則將它們提取到單獨的類中。 IDE將協助您。

該過程可以在每個圖層上重複多次。如果你不能說出它的名字（例如，你必須用「和」來表達什麼方法/類正在做什麼），那麼它的目標就是小而緊湊的類，進一步提取。

當然，您可以按原樣進行測試 - 我猜測每個可能的執行路徑都可以通過不同的輸入參數集來達到。但這將是調試的噩夢。

Answer 2

一些指針在this鏈接。

如果你想超越這一點，我認爲"Working effectively with legacy code"必須閱讀。

Answer 3

只是爲了一些其他因素添加到從托馬斯Nurkiewicz偉大的答案（這是我第二次完全）：

• 有時（嗯，要真），它至少寫一個封裝「驗收測試是非常有用的「在開始重構之前（如果沒有現成的話）。一旦通過，你就可以開始重構，並確保你在每一步都沒有破壞任何「重要」的東西。在開始一個重要的重構任務之前，有這樣一個線束讓你保持理智是非常有用的:)

• 重構不僅僅是一項技術任務：你不僅想要將大類分解爲更小的類並提取代碼到方法。你想從代碼的角度思考你的代碼應該做什麼，並轉向更好的設計。從長遠來看，它會讓你的生活更輕鬆。作爲一個經驗法則，我嘗試沒有超過80-100行代碼（理想情況下低於50）的類。當然也有例外，但是當它變得更大時，我通常會嘗試將單獨的關注重構成注入主類的協作者對象。它使代碼易讀並且易於測試。