如何確定現有的類是否可以進行單元測試？

最近，我取得了一些C++代碼的所有權。我將保留此代碼，並在稍後添加新功能。我知道很多人說現在的代碼通常不值得添加單元測試，但是我仍然想添加一些至少部分覆蓋代碼的測試。特別是，我想添加測試，重現我固定的錯誤。如何確定現有的類是否可以進行單元測試？

一些類的構造有一些非常複雜的狀態，這可能使單元測試更加困難。

我也願意重構代碼，使其更容易測試。

有沒有什麼好的文章可以幫助您找出更容易進行單元測試的指南？你有任何建議嗎？

來源

2011-01-25 zr.

「我知道很多人說，這是通常不值得補充單元測試，以現有的代碼......」 < - 你需要選擇不同的人聽。只是在說'。 – 2011-01-25 17:16:57

儘管Martin Fowler關於重構的書是信息的寶庫，爲什麼不看看「Working Effectively with Legacy Code」。另外，如果你打算處理那些存在大量全局變量或大量狀態轉換的類，那麼我會進行大量的集成檢查。分離出與重構代碼相互作用的代碼，確保按照接收順序輸入的所有期望輸入繼續產生相同的輸出。這是非常重要的，因爲它很容易「修復」可能在其他地方解決的細微錯誤。

做筆記了。如果你發現有另外一個函數/類期望並且正確處理的錯誤，你會想同時改變它們。除非你保存完整的記錄，否則這很困難。

來源

2011-01-25 16:33:52 wheaties

假設代碼是爲某個目的而編寫的，單元測試將檢查目的是否符合，即前提條件和後繼條件是否適用於這些方法。

如果公共類方法是這樣的，你可以從外部檢查狀態，它可以很容易地進行單元測試（黑盒測試）。如果類的狀態是不可見的，或者您必須測試棘手的私有方法，那麼您的測試類可能需要成爲朋友（白盒測試）。

一類，是很難進行單元測試將是一個

具有巨大的依賴關係，即緊密耦合
有意識地在高容量或者多線程環境中工作。在那裏你會使用系統測試而不是單元測試，實際的輸出可能不是完全確定的。

來源

2011-01-25 16:37:48 CashCow

我寫單元測試，不平凡的，C++代碼中有相當數量的博客文章：http://www.lenholgate.com/blog/2004/05/practical-testing.html

我也寫了很多有關加入測試，以現有的代碼：http://www.lenholgate.com/blog/testing/

來源

2011-01-25 16:48:01

幾乎所有的東西都可以並應該進行單元測試。如果不是直接的，那麼通過使用模擬類。

由於您決定重構您的類，請嘗試使用BDD或TDD方法。

爲了防止破壞現有功能，唯一的方法是進行良好的集成測試，但通常需要一段時間才能將它們全部用於複雜系統。

如果沒有更多的細節你做什麼，它不是那麼容易給更多的實施細節。有些是：

使用MVP或主持人首先爲開發GUI
使用設計模式，在適當情況下
使用功能和成員指針，或觀察者設計模式，打破依賴

來源

2011-01-25 17:08:18

的解決方法往往在於部署大量的TLA – CashCow 2011-01-25 17:10:15

我認爲，如果你不得不想出一些「測量」來測試一個類是否可測試，那麼你已經被fscked了。你應該能夠通過看看它來判斷：你能編寫一個獨立的程序來鏈接到這個類，並確保它可以工作嗎？

如果一個類是太龐大了，這樣你不能肯定只是看它......機會是它可能是不可檢驗。不知道如何製作小而獨特界面的人通常也不知道如何遵守任何其他原則。

在比賽的最後階段，該辦法找出如果一個類是可測試的就是儘量把它放在一個線束。如果你最終不得不把你的程序拉到一半，嘗試重構。如果你發現你甚至不能在不重寫整個程序的情況下執行最基本的重構，就要分析這樣做的開銷。

來源

2011-01-25 17:22:34

我們在IPL發表了一篇論文It's testing Jim, but not as we know it其中探討的測試C++中的實際問題，並提出了一些技術來解決他們很可能給你的問題的使用。這些技術在Cantata ++中也得到了很好的支持 - 我們的C/C++單元和集成測試工具。

來源

2011-01-31 11:32:57 Richard

如何確定現有的類是否可以進行單元測試？

回答

相關問題