将.net应用程序转换为测试驱动的应用程序

有一本书我经常看到推荐这个确切的主题，我没有读过它，但它似乎适合你的问题，虽然我不知道如果事实，它是WinForms复杂这个或不

"有效地使用遗留代码"

http://books.google.ie/books?id=CQlRAAAAMAAJ& q = +处理+遗留+ code& dq = +处理+遗留+ code& hl = en& ei = LnVXTrviCtSu8QPEwei0DA& sa = X& oi = book_result& ct = result& resnum = 1, ved = 0 cc0q6aewaa

在WinForms中很难进行单元测试，因为后面的代码与GUI本身紧密相连。一些自动化测试可能是你可以在WinForms应用程序上得到的最好的测试，而不需要费心去改变程序。

如果你的客户想要一个可测试的解决方案，我建议在WPF中制作，并使用像Caliburn这样的MVVM框架。强调单元测试的Micro。

不幸的是，这意味着重写整个应用程序。

简短回答

要么重写应用程序，要么就不要为单元测试费心了。

由于WinForms应用程序通常有一个与底层"数据模型"强耦合的UI，某种形式的自动化UI测试可能是你最好的选择——即一个外部应用程序模拟用户的点击和其他与UI的交互，并检查你的程序是否处于预期状态。

你可能想看一下:

http://smartbear.com/products/qa-tools/automated-testing/supported-testing-types/functional-testing/

要只做UI测试(因为它是基于。net的)，您可以使用。net轻量级的测试自动化功能。详情请点击这里http://msdn.microsoft.com/en-us/magazine/cc163864.aspx您不必使用外部工具来自动化它。但是，要测试底层或业务逻辑，您必须扩展测试用例。

我建议您将最关键的部分移到普通的c#类中并对其进行单元测试。然后只对GUI的复杂部分进行UI测试。我曾在一个遗留项目上工作过，但使用的是ASP。. NET Webforms而不是Windows Forms，我注意到系统的某些部分经常变化，是重构和单元测试的好选择，而其他部分从未改变，只是不值得测试。

如果这是一个大项目，那么这可能需要很长时间。工作的很大一部分是使代码可测试，并引入某种MVP(模型-视图-演示器)模式，以便能够将GUI代码与业务逻辑分离。

我强烈推荐Eoin Carroll所推荐的有效使用遗留代码。它描述了处理遗留代码的技术，并通过展示它可以完成来提供动力(您可能会遇到一些困难时期)。

还可以看看这两个StackOverflow问题(这里和这里)关于WinForms和MVP的讨论

这取决于你想测试什么，以及应用程序是如何编写的。

GUI很难测试，但可以看看其他一些答案。如果您只是想测试业务层，那就更简单了:

如果应用程序的业务和GUI解耦，那么你可以很容易地使用NUnit，要么通过从IDE将其集成到项目中，要么以NUnit自己的方式，然后编写测试来覆盖业务层向GUI暴露的功能。

如果应用程序没有解耦，而你在GUI中有很多逻辑，那么你真的需要重构和解耦。如果不这样做，您将被限制在通过GUI进行测试，这是困难的，并且不是真正完整的证明，这意味着对GUI的微小更改可能会使您的业务逻辑测试无效。