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