.NET UI测试（单元和集成）

Question

我的任务是提出在UI级别上进行有效单元测试和集成测试的解决方案。不幸的是，我们在windows窗体中有很多代码隐藏。我们还有一个棕地项目，我们正在慢慢转向WPF（新功能在WPF中，当他们保证重大更改时，将旧功能移到WPF）。

WPF中的所有内容都是单元测试（数据库除外）。我使用MVVM方法，因此几乎所有的代码都在那里。

但是，在部署之前进行测试需要很长时间，我们需要一种自动化大部分时间的方法。

也就是说，我所指的这个测试需要在用户界面上进行。

Windows窗体部件必须进行集成测试，因为部分逻辑是在代码隐藏中完成的，部分在数据库中完成。

WPF窗口应该在UI级别进行单元测试，但也要进行集成测试。

我知道这对于一个问题有很大的吸引力，但是有没有人有任何建议？

Answer 1

（这个答案是关于如何整合测试代码：WinForms和WPF）

我没有给你一个专利解决方案，只是建议投入了大量的时间和精力投入使测试易于维护。

确保您可以在Visual Studio中修改并运行测试。

不得不为测试启动一个不同的工具的额外burdon可能足以让开发者不这样做（我见过它发生）。所以试着找到允许这个的UI testing tool。

不要记录测试。

舒适，记录测试的结果代码很难阅读和理解，并且很可能包含许多不重要的细节。如果您需要对测试进行更改，您可能需要重新录制它们。测试将更多地是关于系统如何工作的文档，而不是您希望如何工作的规范。

为您的测试创建共享基础架构。

为表示窗口行为的对象中的窗口/窗体创建抽象。通过这种方式，您可以隐藏这些对象中的实现细节，使实际测试更加紧凑并且易于阅读。一旦你有了这个基础设施，就可以很容易地添加新的测试。此外，如果实施细节发生变化，您只能在一个地方对测试进行更改：在基础架构中。

在网络测试世界中，这被称为page object pattern。在C＃中测试的

例子：

ApplicationFake application = new ApplicationFake(); 

// ApplicationFake.Start() starts the application resulting in that main form opens. 
// Start() returns an object that represents the actions that the user can perform on 
// the main form. 
// The Start() method might contain an assert that the main form was actually opened. 
MainFormFake mainForm = application.Start(); 

// Performing an action that opens a new form returns a representation of the new form, 
// in this case the object SomeFormFake. 
SomeFormFake someForm = mainForm.ClickOpenSomeFormButton(); 

// The form fakes exposes properties that returns the forms' observable state. 
Assert.That(someForm.Title, Is.EqualTo("Some Form's Title")); 

Answer 2

我完全Torbjorn的答案同意，但想补充几点：

开始小

页面对象图案是很好的方法来简化你的测试，但是你会发现获得抽象是需要很长时间的。首先抽取你需要的东西，然后慢慢加入。

增加价值

不要走极端，并尝试写终端到终端的回归测试。相反，专注于编写增值的测试。例如，一个演示应用程序启动没有错误的单个测试非常有用，可以为您的构建过程提供早期反馈。从那里出来。

平衡“深”与“浅”

有用于测试用户界面的几个不同的理念。建立它们之间的混合。

显而易见的方法是使用类似生产的设置来测试应用程序，以证明应用程序“从前到后”工作。这些是“深层次”的集成测试，可以锻炼代码的所有部分并且很有用。由于它们通常依赖于外部服务等，它们也可能会非常缓慢。通常，为了保证可靠性，应用程序必须在测试运行之间重新启动以确保有效的环境。

该方法稍作修改就是测试应用程序与残缺服务（假冒产品目录，假身份验证提供程序等）。这些是“浅”测试，它们表明用户界面在集成在一起时起作用。他们通常运行更快一点，因为他们不会有相同的物理约束，如网络延迟考虑。您可以更多地关注演示文稿细节和其他边缘案例。

进一步的修改是隔离部分用户界面并在测试工具中运行它们。这些测试的运行速度比以前的方法快得多，因为它们不会具有启动整个应用程序的相同开销。使用这些测试来确定颜色和高度专业化的演示问题。

迭代时稳定

如果您打算编写功能测试，以取代手工回归测试你可能会发现，最好等到发展为它编写自动化之前稳定该功能。如果您在开发过程中开始编写自动化程序，您将不断重新编写测试。如果您想在开发过程中自动化，请记住：从小处着手。

获取早期反馈

的UI（也称为功能测试）的自动化测试是有用的，但它可以是非常，非常缓慢。 （我已经看到运行需要几个小时才能完成。）如果你每天运行一次整个测试套件，你会发现反馈循环太长，导致误报和维护问题等。

尽可能将功能测试集成到构建过程中。如果测试套件花费太长时间，请找到一种方法来集成的一些测试，以便您的构建管道可以验证重要测试作为构建的一部分。