重新启动失败的XCTests

UI测试是相当不稳定的事情，这对任何人都不是秘密。 通常，在实践中，我们必须想出各种方法使它们尽可能稳定。 一种这样的方法是重新启动失败的测试。

如果在此类情况下的JUnit中我们有TestNG中的RetryTestHelper — IretryAnalyzer，那么为了在XCTest中测试iOS应用程序，我们没有开箱即用的东西。

经过一番谷歌搜索之后，我们找到的第一个解决方案— setup_fragile_tests_for_rescan —这是Fastlane插件。 Fastlane是一款华丽而优雅的工具，可用于自动完成移动应用程序周围的所有操作（签名，生成，测试，屏幕截图，交付等）。 该插件目前已被弃用，但取而代之的是改进的新版本。

我真的很喜欢Fastlane，但是我坚信主版本中没有包含插件。 虽然，这是一个现成的解决方案，但您的选择很可能落在它上面。 如果您不想要其他依赖项，并且准备进行少量编码，那么我们将继续。 我将告诉您，如何使用相同的Fastlane通过自写解决方案实现失败的测试的重启。 从理论上讲，不用Fastlane就可以做同样的事情，但是有了它，一切看起来都会变得更加优雅，而且整个过程真的很愉快。

安装Fastlane以运行我们的测试：

  $宝石安装fastlane 

安装Nokogiri来解析测试结果：

  $ gem install nokogiri 

在我们开始之前，我想添加一些理论上的补充。 由于Fastlane是Ruby上的一种DSL，因此其语法将非常接近Ruby爱好者。 要配置可运行命令及其参数，我们将使用Fastfile。

在.xcodeproj的附近，我们创建了一个隐藏的Fastlane文件夹和一个Fastfile配置，在其中将保留运行测试的整个逻辑：

  $ mkdir -p .fastlane 
  $ touch ./fastlane/Fastfile 
  $打开./fastlane/Fastfile 

要运行测试，我们需要创建自己的Fastlane通道，并在其中调用名为scan的Fastlane操作：

现在，让我们编写一个Fastlane通道，它将重新启动测试指定次数。 为此，我们需要以易于解析的格式（例如.junit）生成测试报告。 运行测试一次并生成报告后，我们检查报告中是否有任何失败的测试。 如果存在，那么我们将测试循环预定次数，直到获得成功：

现在，要检查我们的重启，让我们编写两个测试：

• 首先，那将永远是绿色的
• 第二个总是红色

之后，与我们的测试运行程序一起运行Fastlane：

  $ fastlane测试 

该解决方案的唯一可能的缺点是，在最终的测试报告中，我们将仅看到上次重启时运行的测试。

失败的测试试图通过@test_retries时间，但是在我们的示例中，它注定要失败。

但是，应该注意的是，虽然强制执行了重新启动测试的操作，但这并不是维持稳定性的最佳方法，因为您的应用程序已成为海森堡的目标。 因此，重新启动测试，减少重新启动它们的频率。

到此为止。 谢谢大家，在接下来的笔记中见（