使您的UI测试再次变为绿色

加入BUX之前，我从未做过任何UI测试。在我以前的公司中，拥有事物总是一件好事，而且从来没有发生过当您可以执行非强制性的事情时我们能够达到目标的情况。基本上，这通常发生在早期初创企业中的大多数工程师身上。我真的很高兴在我们的BUX代码中看到UI测试，此外，他们设法在基本的Apple工具上构建了一些不错的抽象。我很高兴接球并积极参与改善我们应用程序质量的过程。

我不会试图说服您编写测试。您只需每天执行一次。这是与“我们应该使用版本控制系统吗？”相同的问题。答案是“是的，我们应该”。

如果您仍然需要一些启发，可以从我的一位同事撰写的文章开始。除了要点之外，您还会发现一些很棒的历史见解。

UI测试的主要目的是快速运行最重要的方案。我们应该能够从用户的角度跟踪是否破坏了某些内容。当然，我们应该不时看到测试失败！这就是测试如何帮助我们提高软件质量的方式。但是，在某些情况下，我们可以进行红色测试，而背后的原因对我们而言似乎毫无意义，因为我们无法采取任何措施对其进行修复。

在第二部分中，我想讨论使您的测试变成红色的主要原因：网络。

烦恼网络的原因

想象一下，您刚刚为应用程序流程的新部分编写了全新的UI测试。您击中Cmd-U时，看到Xcode的“测试成功”并提交时，微微一笑。您觉得一切都完成了。但是，当涉及到CI时，情况可能会发生变化。您一定会看到红色测试的一天。发生这种情况的原因可能很多：

CI环境与开发环境不同步（例如，需要更新Xcode）
证书已过期
网络/后端失败（最常见的情况）

后端通常有多种原因完全不响应或以意外方式响应：

服务器维护
网络可达性问题（如果您使用真实设备进行测试，并且该框中的WiFi信号较弱）
与数据相关的问题。我们不能总是知道要从后端接收什么数据

如果您的团队中有人要求您使用真实的服务器进行UI测试，请说“ 否” 。如果他们想在不付出额外努力的情况下测试API，则应该使用一些适当的集成测试，而不是移动应用程序。使用移动UI测试作为集成测试并不是最好的方法，因为我们引入了多个故障点，这使得测试对于移动端和后端均不稳定且无用。

即使一个应用程序可以一直访问其后端服务器（假设后端始终在运行），它仍然是一个巨大的依赖项，我们对它没有任何影响！因此，每次在配置项上看到红色测试时，都应确保我们使用新的提交破坏了测试。我们不会每次都检查后端/网络问题。归根结底，每个人都可以习惯于“红色”测试，而这并不是我们想要的方式。

解决方法

我们该如何克服呢？我们应该从不使用真正的UI测试后端开始。

我们决定从OHHTTPStubs开始，因为我们已经使用它进行了一些存根。这件事太神奇了，它为我们节省了很多时间。在BUX，我们决定走得更远，并包装此库以使事情更干净和可维护。

我们的目标是在决定“我是否有时间为该功能编写测试或……吗？”的情况下，轻松创建新的UI测试。

要求

我们对存根工具的主要要求是：

存根文件（很多，目前大约有300个）应该易于维护
系统应该有可能为同一端点返回不同的存根
我们应该能够以可预测和干净的方式对其进行修改以满足新的要求
单个测试流程应能够按特定顺序使用不同的存根

GitHub上有一些可用的库，我们已经对其进行了研究，因为没有人愿意重新发明轮子。经过调查，结果发现它们大部分覆盖了某些部分，但没有一个可以满足我们的所有需求。我们决定继续使用自己的工具。

简而言之，这是我们的UI测试类之一。易于阅读，易于更改。这里的OnboardingNinPage是上一篇文章中描述的这些页面对象模型 （POM）之一。

然后，我们仅使用启动参数将配置名称传递给存根。存根从配置文件夹中递归地读取所有文件，这些文件夹从文件夹层次结构，通配符和文件名中的一些元数据构建存根端点。

每次OHHTTPStubs拦截网络请求时，该Stubber都会在内存中的Stubs数组中进行搜索以尝试找到正确的数组。如果未找到，我们将使用fatalError使应用程序崩溃，以确保任何网络调用都到达了真正的后端。认真地说，我们在测试中不需要这个。

灵活性

当前，在我们的REST API中，我们有一些端点应该为相同的请求返回不同的响应。其中之一只是返回用户入职过程的当前状态。它以/applications/current结尾，并且始终不带任何参数使用。在一个UI测试中，当连续调用多次以测试应用程序如何执行状态更改时，它应该返回不同的状态。

我们通过在存根文件名中添加一些元数据来实现这种灵活性。通常，存根文件名包含三个部分：

存根触发时将应用的HTTP状态代码
“响应”部分，使其更易于阅读
元数据修饰符，使存根仅使用一次存根配置

因此，对于名为200_GET_response_runStubOnce.json存根，我们将获得200状态代码，该存根在使用后将被删除。这增加了很多灵活性，我们可以通过将小型，简单和可维护的存根配置组合在一起轻松地实现它。

容易修改

老实说，从构建它的那一刻开始，我们就不需要修改它。一旦开始使用第二个后端服务，我们就在主应用程序中添加了第二个存根实例。

用法

当我们定义存根配置覆盖来自BXTestCase的stubConfigurations时，它们堆叠在存根中。如果同一个端点有多个存根，则最后通过的存根具有最高优先级。通常，默认情况下我们会应用一些默认配置，并且有几个（不超过三个）存根应用到了其中，其中大多数带有run once修饰符。

最后，

现在我们应该怎么做才能为一个新屏幕编写UI测试？

将accessibilityIdentifier （在此进行描述）添加到UI元素
为屏幕添加POM包装器以将所有XCUITest内容隐藏在其中（UI元素快捷方式，可见性和可访问性断言，封装复杂的操作以在帮助器中到达一些棘手的UI元素）
添加存根配置（可以手动完成或将其复制粘贴或使用一些自动响应编写器）
创建UI测试类，覆盖stubConfigurations ，编写测试逻辑

听起来很简单，不是吗？

在这里您可以深入研究：HTTPRequestStubber.swift

附录

实际上，我们是第一次使用某种响应编写器创建所有存根。之后唯一需要注意的是用通配符替换真实ID的过程，以保持存根整洁和可靠。