Question

我的任务是在UI级别提出有效的单元测试和集成测试解决方案。不幸的是，我们在Windows窗体中有很多代码隐藏。我们还有一个棕色区域项目，我们正在慢慢转向WPF（新功能在WPF中，并且当它们需要进行重大更改时将旧功能移至WPF）。

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

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

那就是说，我所指的测试需要在UI上进行。

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

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

我知道在一个问题上要吞下很多东西，但是有人有任何建议吗？

Answer 1

（这个答案是关于如何集成测试你的代码：WinForms和WPF。）

我没有专利的解决方案，只提供了大量的时间和精力来使测试易于维护。

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

必须为测试启动不同工具的额外负担可能足以让开发人员不要这样做（我已经看到它发生了）。因此，请尝试找到允许此项的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的自动测试（也称为功能测试）很有用，但它可能非常非常慢。（我已经看到运行需要几个小时才能完成。）如果你每天运行一次整个测试套件，你会发现反馈回路太长会导致误报，维护问题等。< / p>

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

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

2 个答案: