對“舊版” WPF應用程序進行單元測試

Question

我一直在研究的產品已經開發了六年。 它最初是作為通用數據輸入門戶進入瘋狂復雜的WPF /零件遺留應用程序的。 這些年來，該系統一直在開發，無需進行任何單元測試。 現在，已經提出了全面的單元測試框架的要點。 我最近被錄用從事此產品的工作，並受命按順序進行“測試”。 由於過去六年中從事產品工作的團隊采用了“敏捷”，因此該項目缺少任何業務規則文檔或任何設計文檔。

我一直在嘗試為某些模塊編寫單元測試。 但是我不確定要模擬什么，如何設置測試夾具以及最終要測試什么，因為隨便看看這些方法並不能揭示其意圖。 另外，引起我注意的是，該代碼並不是在開發時就考慮了特定的方法。

考慮到這種情況，我想知道Stackoverflow的好人是否可以為我提供一些有關如何挽救這種情況的建議。 我聽說過《使用傳統代碼》一書，其中談到了這種一般情況，但我當時正在考慮從技術堆棧（C＃，VB，C ++ 、. NET 3.5）中遇到類似情況的個人那里獲取一些建議。 ，WCF，SQL Server 2005）。

Answer 1

在我看來，最好的方法是開始使用集成測試“穩定”當前代碼的功能。 嘗試創建起點不會在以后更改的測試。 使用集成測試，您可以確信單元測試稍后將進行的重構不會破壞任何內容。

下一步是對代碼進行單元測試。 如果您可以自由地重構代碼，則可以開始將邏輯分離為類（例如，視圖層中的額外邏輯），並向其中添加單元測試。 使用此過程，您還可以更好地了解產品代碼。

強烈建議閱讀使用遺留代碼 ，您將要遇到的許多問題已經有了解決方案:)

有時，對現有代碼進行單元測試可能是一個挑戰，具體取決於現有代碼以及可以更改代碼的數量。 您可以使用一些工具，例如用於編寫集成測試的工具，可以使用White框架自動化GUI。 可以用來編寫單元測試而又無需強制對代碼進行重大更改的另一個工具是Typemock Isolator （ 免責聲明-我在Typemock工作 ），它可以偽造大多數依賴關系而無需更改生產代碼。 還有許多其他工具可以簡化流程，嘗試查找並充分利用它們:)

Answer 2

@sc_ray：我知道這聽起來似乎很明顯，但是我相信在開始針對現有代碼庫編寫測試之前，您應該集中精力確保在與UI交互時使用MVVM方法。
成為舊版應用程序並不意味着您具有使用if語句直接更新UI的代碼，但是項目越舊，人們越容易繞過更現代的軟件開發風格。
我要說的是，我將確保我在優化綁定，命令以及WPF提供的所有出色基礎結構功能方面的使用。 否則，您的業務邏輯的重要部分將無法進行測試，並且您可能會針對不相關的代碼編寫測試...