使用Swift在Xcode中进行异步UI测试

bla*_*acx 2 testing xcode unit-testing ios swift

我正在编写一个提供大量网络请求的应用程序.像往常一样,它们是异步的,即请求方法的调用立即返回,结果通过委托方法或在一些延迟后的闭包中传递.现在,在我的注册屏幕上,我向我的后端发送了一个注册请求,并希望在请求完成时验证是否显示了成功UI.

有哪些选项可以等待请求完成,验证成功UI并且只有在离开测试方法之后?

还有比等待请求完成更聪明的选择吗?

提前致谢!

bla*_*acx 12

琐碎的方法

Apple在Xcode 9/iOS 11中实现了重大改进,使您可以等待UI元素的外观.您可以使用以下单行:

<#yourElement#>.waitForExistence(timeout: 5)
Run Code Online (Sandbox Code Playgroud)

先进的方法

通常,UI和单元测试(此处称为测试)必须尽可能快地运行,以便开发人员可以经常运行它们,并且不会因为每天多次运行慢速测试套件而感到沮丧.在某些情况下,(内部或安全相关的)应用程序可能会访问只能从某些网络/ IP范围/主机访问的API.此外,大多数CI服务提供相当糟糕的硬件和有限的互联网连接速度.

出于所有这些原因,建议以不进行实际网络请求的方式实施测试.相反,它们使用假数据运行,即所谓的灯具.一个聪明的开发人员以一种简单的开关(如布尔属性)切换数据源的方式实现了这个测试套件.此外,当开关设置为获取真实的后端数据时,可以自动从后端刷新/记录灯具.这样,更新假数据并快速检测API的变化非常容易.

但这种方法的主要优点是速度.您的测试不会产生真正的网络请求,而是针对本地数据运行,这使得它们独立于:

  • 服务器问题
  • 连接速度
  • 网络限制

通过这种方式,您可以非常快速地运行测试 - 这是编写代码的好方法("测试驱动开发").

另一方面,您不会立即检测到服务器更改,因为当后端数据更改时,伪数据不会更改.但这可以通过使用您实施的开关简单地刷新灯具来解决,因为您是一个聪明的开发人员,这使得这个问题成为一个可以告诉您的孩子的故事!

但是等等,我忘记了什么!为什么这是上述琐碎方法的替代品 - 你问?简单!由于您使用的是立即可用的本地数据,因此您也可以立即调用完成处理程序.因此,在执行请求和验证成功UI之间没有延迟.这意味着您无需等待,这使您的测试更快!

我希望这能帮助我的一些同伴.如果您需要有关此主题的更多指导,请不要犹豫,并回复此帖.

氰!