对“遗留”进行单元测试WPF应用程序
我一直在开发的产品已经开发了六年。它最初是作为一个通用数据输入门户进入一个极其复杂的部分 WPF/部分遗留应用程序。该系统已经开发了这么多年，没有进行过任何单元测试。现在，人们提出了一个全面的单元测试框架的观点。我最近被招募来从事该产品的工作，并负责按顺序进行“测试”。由于过去六年致力于该产品的团队采用了“敏捷”，因此该项目缺乏任何业务规则文档或任何设计文档。
我一直在尝试为某些模块编写单元测试。但我不确定要模拟什么，如何设置我的测试装置以及最终要测试什么，因为随意浏览这些方法并不能揭示其意图。另外，我还注意到代码的开发并没有考虑到特定的方法。
鉴于这种情况，我想知道 Stackoverflow 的好心人是否可以为我提供一些关于如何挽救这种情况的建议。我听说过《Working with Legacy Code》一书，其中对这种一般情况有话要说，但我正在考虑从在技术堆栈（C#、VB、C++、.NET 3.5）中遇到过类似情况的个人那里获取一些指导、WCF、SQL Server 2005）。
The product I have been working on has been in development for the past six years. It started as a generic data entry portal into an insanely complex part WPF/part legacy application. The system has been developed for all these years without a single Unit test in its fold. Now, the point has been raised for a comprehensive unit testing framework. I have been recruited recently to work on this product and have been tasked to get the 'Testing' in order. Since the team that worked on the product for the last six years adopted 'Agile', the project lacks any documentation of the business rules or any design documents.
I have been trying to write unit tests for some of the modules. But I am not sure what to Mock, how to setup my Test fixture and eventually what to Test for, since a casual glance of the methods does not reveal its intentions. Also, it has come to my attention that the code was not developed with a particular methodology in mind.
Given the situation, I was wondering if the good people of Stackoverflow could provide me with some advise on how to salvage this situation. I have heard about the book 'Working with Legacy Code' that has something to say about this general situation but I was thinking about getting some pointers from individuals who have encountered similar situations within the technology stack(C#,VB,C++,.NET 3.5,WCF,SQL Server 2005).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
在我看来，最好的方法是从使用集成测试“稳定”当前代码功能开始。尝试创建具有以后不太可能改变的起点的测试。使用集成测试，您可以确信稍后进行的单元测试重构不会破坏任何内容。
下一步是对代码进行单元测试。如果您可以自由地重构代码，您可以开始将逻辑与类分离（例如视图层中的额外逻辑）并向它们添加单元测试。通过这个过程，您还可以更好地了解产品的代码。
强烈建议阅读使用遗留代码，您将遇到的许多问题已经有了解决方案:) 对
遗留代码进行单元测试有时可能是一个挑战，具体取决于现有代码以及如何进行测试很多你可以改变代码。您可以使用一些工具，例如，为了编写集成测试，您可以使用 White 框架来自动化 GUI。您可以使用另一个工具来编写单元测试，而无需对代码进行重大更改，它是 Typemock Isolator（免责声明 - 我在 Typemock 工作），它允许伪造大部分无需更改生产代码即可实现依赖关系。还有许多其他工具可以简化这个过程，尝试找到并充分利用它们:)
In my opinion the best way is to start by "stabilizing" the current code functionallity using integration tests. Try to create tests that has start point which is not likely to change later. Using the integration tests you can gain confidence that refactoring that'll come later for the unit tests are not breaking anything.
The next step is to unit test the code. If you're free to refactor the code you can start separating logic to classes (e.g. extra logic in view layer) and add unit tests to them. Using this process you also get to know better the code of the product.
It is very recommended read Working with Legacy Code, many of the problems you're going to encounter already have solutions :)
Unit testing legacy code can be a challenge sometimes, depending on the existing code and on how much you can change the code. You can use some tools, for example for writing integration tests you can use White framework to automate the GUI. Another tool you can use for writing the unit tests without forcing major changes in the code is Typemock Isolator (disclaimer - I work at Typemock), it allows faking most of dependencies without changing the production code. There are many other tools which can ease the process, try to find and make best use of them :)
@sc_ray：我知道这听起来很明显，但我相信在开始针对现有代码库编写测试之前，您应该专注于确保在与 UI 交互时使用 MVVM 方法。
作为遗留应用程序并不意味着您有代码直接使用 if 语句更新 UI，但项目越旧，人们就越容易绕过更现代的软件开发风格。
我想说的是，我将确保优化绑定、命令以及 WPF 提供的所有出色基础设施的使用。否则，您的业务逻辑的重要部分将无法进行测试，并且您可能会针对不太相关的代码编写测试......
@sc_ray: I know this may sound pretty obvious, but I believe before you start writing tests against the existing code base, you should focus on making sure you are using an MVVM approach when interacting with your UI.
Being a legacy app does not mean you have code updating the UI directly with if statements, but the older the project the easier it is for people to bypass more modern software development styles.
All I'm saying is that I would make sure I am optimizing the use of binding, commanding, and all the wonderful infrastructure facilities WPF provides. Otherwise important pieces of your business logic would not be able to be tested and you could be potentially writing tests against less relevant code...