我一直在开发的产品已经开发了六年。它最初是作为一个通用数据输入门户进入一个极其复杂的部分 WPF/部分遗留应用程序。该系统已经开发了这么多年，没有一个单元测试。现在，已经提出了一个全面的单元测试框架。我最近被招募来从事这个产品的工作，我的任务是按顺序进行“测试”。由于过去六年从事该产品工作的团队采用了“敏捷”，因此该项目缺乏任何业务规则文档或任何设计文档。
我一直在尝试为某些模块编写单元测试。但是我不确定要模拟什么，如何设置我的测试夹具以及最终要测试什么，因为随便看一眼这些方法并不能揭示它的意图。此外，我注意到代码的开发并未考虑到特定的方法。
鉴于这种情况，我想知道 Stackoverflow 的好人是否可以为我提供一些关于如何挽救这种情况的建议。我听说过“使用遗留代码”一书对这种一般情况有话要说，但我正在考虑从在技术堆栈中遇到类似情况的个人那里获得一些指示（C#、VB、C++、.NET 3.5 ,WCF,SQL Server 2005)。
在我看来，最好的方法是从使用集成测试“稳定”当前代码功能开始。尝试创建具有以后不太可能更改的起点的测试。使用集成测试，您可以确信稍后为单元测试进行的重构不会破坏任何东西。
下一步是对代码进行单元测试。如果您可以自由地重构代码，您可以开始将逻辑分离到类（例如视图层中的额外逻辑）并向它们添加单元测试。使用此过程，您还可以更好地了解产品的代码。
非常推荐阅读使用遗留代码，您将遇到的许多问题已经有了解决方案:)
单元测试遗留代码有时可能是一个挑战，这取决于现有代码以及您可以更改代码的程度。您可以使用一些工具，例如编写集成测试，您可以使用White框架来自动化 GUI。另一个可以用来编写单元测试而不强制对代码进行重大更改的工具是Typemock Isolator（免责声明 - 我在 Typemock 工作），它允许在不更改生产代码的情况下伪造大部分依赖项。还有许多其他工具可以简化流程，尝试找到并充分利用它们:)
@sc_ray：我知道这听起来很明显，但我相信在您开始针对现有代码库编写测试之前，您应该专注于确保在与 UI 交互时使用 MVVM 方法。
作为一个遗留应用程序并不意味着您可以使用 if 语句直接更新 UI 的代码，但是项目越老，人们越容易绕过更现代的软件开发风格。
我要说的是，我将确保优化绑定、命令和 WPF 提供的所有出色基础设施的使用。否则，您的业务逻辑的重要部分将无法测试，并且您可能会针对不太相关的代码编写测试......