我已经编写了一个 Windows 窗体应用程序，现在我想为它编写一些单元测试（不完全是测试驱动的开发，因为我在开发之后才编写测试，但最好晚一点再不要！）我的问题是考虑到几乎所有方法和事件都是私有的，这样的应用程序如何编写单元测试？我听说过 NUnit Forms，但我也听说过它的好与坏，而且该项目已经有一段时间没有真正的开发，所以它看起来已经被废弃了。如果我为用户通过单击/按下按钮触发的所有事件编写单元测试用例，或者我必须为所有事件编写单元测试用例，是否普遍认为该项目已经进行了足够的单元测试？方法并找出测试我的私有方法的方法？
编辑：我的业务逻辑与我的表示逻辑是分开的，我的业务逻辑公开了 1 或 2 个公共方法，因此表单可以访问它们，但是其中的所有私有方法呢业务逻辑？
【问题讨论】：
标签： c# winforms unit-testing
单元测试图形应用程序的关键是确保所有大部分业务逻辑都在一个单独的类中，而不是在后面的代码中。
Model View Presenter 和 Model View Controller 等设计模式可以在设计这样的系统时提供帮助。
举个例子：
public partial class Form1 : Form, IMyView
{
MyPresenter Presenter;
public Form1()
{
InitializeComponent();
Presenter = new MyPresenter(this);
}
public string SomeData
{
get
{
throw new NotImplementedException();
}
set
{
MyTextBox.Text = value;
}
}
private void button1_Click(object sender, EventArgs e)
{
Presenter.ChangeData();
}
}
public interface IMyView
{
string SomeData { get; set; }
}
public class MyPresenter
{
private IMyView View { get; set; }
public MyPresenter(IMyView view)
{
View = view;
View.SomeData = "test string";
}
public void ChangeData()
{
View.SomeData = "Some changed data";
}
}
如您所见，表单只有一些基础架构代码将您的所有内容组合在一起。你所有的逻辑都在你的 Presenter 类中，它只知道一个视图接口。
如果您想对此进行单元测试，您可以使用像 Rhino Mocks 这样的 Mocking 工具来模拟 View 界面并将其传递给您的演示者。
[TestMethod]
public void TestChangeData()
{
IMyView view = MockRepository.DynamickMock<IMyView>();
view.Stub(v => v.SomeData).PropertyBehavior();
MyPresenter presenter = new MyPresenter(view);
presenter.ChangeData();
Assert.AreEqual("Some changed data", view.SomeData);
}
【讨论】：
我要做的第一件事是确保您将业务逻辑与表单正确分离。基本上，使用MVC 模式。然后，您可以轻松地测试表单之外的所有内容，就好像表单根本不存在一样。
现在，这仍然会留下一些未经测试的特定于表单的功能。即，表单是否正确连接到服务？为此，您仍然可以考虑使用 NUnit Forms 或其他替代方法。
【讨论】：
将所有业务逻辑分解为一个单独的项目并对其进行单元测试。或者至少将表单中的所有逻辑移到单独的类中。
【讨论】：
您有几个选择。
使用 Coded UI 之类的工具通过您的用户界面进行测试。这不是一个好选择，因为它比单元测试慢，而且测试往往更脆弱。
将业务逻辑与表示逻辑分开。如果您有很多私有方法在您的 UI 中执行业务逻辑，那么您的业务逻辑与您的演示文稿紧密耦合。开始识别这些并将它们移出到具有您可以测试的公共接口的单独类中。阅读 SOLID 原则，它可以帮助您保持代码松散耦合和可测试性。
【讨论】：
使用approvaltests（www.approvaltests.com 或nuget）对视图进行单元测试非常简单。这里有一个视频：http://www.youtube.com/watch?v=hKeKBjoSfJ8
但是，您似乎也担心为了能够测试功能而将函数设为默认或公开。
这些通常被称为接缝；进入代码进行测试的方法。 他们很好。有时人们将私有/公共与安全性相混淆，并且害怕将私有函数公开，但反射会调用其中任何一个，因此它并不真正安全。其他时候，人们担心类的 API 接口。但这只有在你有一个公共 API 时才重要，如果你有一个 winform 应用程序，它可能意味着是顶级的（没有其他消费者调用它。）
您是程序员，因此可以将您的代码设计为易于测试。这通常意味着改变一些公共方法并创建一些允许传递依赖关系的便利方法。
例如：
buttonclick += (o,e)=> {/*somecode*/};
很难测试。
private void button1_Click(object sender, EventArgs e) {/*somecode*/}
仍然很难测试
public void button1_Click(object sender, EventArgs e) {/*somecode*/}
更容易测试
private void button1_Click(object sender, EventArgs e) { DoSave();}
public void DoSave(){/*somecode*/}
真的很容易测试！
如果您需要活动中的一些信息，这会加倍。即。
public void ZoomInto(int x, int y)
更容易测试对应的鼠标点击事件，并且透传调用仍然可以是一个可忽略的单行。
【讨论】：
可以使用带有 Reactive.UI 的 MVVM（模型-视图-视图模型）模式来编写可测试的 WinForms 代码。要获得真正需要的关注点分离。请参阅：Reactive.UI https://reactiveui.net/ 使用 Winforms / MVVM / Reactive.UI 的主要缺点是没有很多使用示例（用于 WinForms）。好处是它适用于几乎所有桌面框架和语言。您为一个人学习它，但这些原则适用于所有人。当你有很多私有方法时，没关系。恕我直言：尝试使用公共方法开始您要测试的业务流程。您可以使用 tell-don't-ask：https://martinfowler.com/bliki/TellDontAsk.html 并仍然将所有这些方法保密。
也可以通过驱动 UI 来测试代码，但不那么强烈建议这样做，因为结果测试 (1) 非常脆弱，(2) 更难工作，而且恕我直言，(3) 不可能编写在与纯代码测试相同的细粒度水平； (4) 最后：如果你使用数据库，你需要考虑用测试数据填充它，而且，因为在每次测试之前你的数据库必须处于干净、定义明确的状态，(5) 你的测试可能运行得更慢比您重新初始化每个测试的数据时的想法。
总结：使用良好的 SoC 编写代码（例如通过应用 MVVM），那么您的代码将具有更好的可测试性。
【讨论】：