编写敏捷测试

使用Quick / Nimble进行更好的iOS测试

我们所有人都希望尽快构建和发布我们的移动应用程序。 但是，它们还需要高质量，稳定并具有用户喜欢的功能。 以下是在iOS应用程序上优先进行测试和使用Nimble可以如何帮助实现这一目标的方法。

为什么测试很重要

当测试花费更多时间时，为什么还要优先考虑编写测试？

软件不再是您可以运送和忘记的物品。 它必须维护并随时随用户需求的变化而发展。 在您的应用中拥有用户后，您需要保持高质量，并确保令人愉悦的用户体验。

使用移动应用程序时，您会额外增加一层复杂性。 连接弱或没有连接时会发生什么？ 如何处理不同尺寸的屏幕或微弱的GPS信号？ 如果您不考虑这些情况，您的用户将为您找到它们。

手动测试在用户发现问题之前起着重要的作用，但是您不能在每次更改后合理地测试每个功能。 这就是自动化测试的用武之地。

在哪里集中精力

尝试测试应用程序中的每一行都很繁琐，并且收益递减。 有用于检查特定代码段或功能的单元测试，用于查看部分或几个系统如何交互的集成测试以及采用UI测试形式的系统测试。

您首先要建立单元测试的基础。 它们是最快的开发工具，可在失败时准确告诉您问题出在哪里。 专注于在不同领域中使用的代码的核心部分。 实用程序和扩展程序是一个很好的起点。

每当发现错误时，您还希望编写一个测试，以免重新引入它。 没有比引入并必须多次修复的错误更令人沮丧的了。

此外，针对您可能想到的任何特定边缘情况编写测试。 如果您具有当某人刚好达到1000小时（或您测量的时间）时执行操作的功能，请编写涵盖0、999、1000和1001的测试，以确保您在正确的时间返回正确的事物。

敏捷的好处

Nimble是一个匹配器框架，这意味着它可以帮助您比较两个变量。 它取代了XCTest内置的XCTAssert函数，并具有一些重要的好处。

坦率地说，XCTAssertions使用起来很不方便

可读性是用Nimble代替XCTAssertions的最大好处。

Nimble使用了Expect函数，它完全按照您的想法进行操作。 在此示例中，我希望我的变量等于第二个变量，并且可以！

 期望（实际）到（等于（预期）） 

Nimble的另一个重要功能是默认失败消息。 使用XCAssert和Nimble，您都可以编写自己的故障消息，有时还是应该这样做。 但是，您有可能使该消息变得不正确。 一堆自定义消息使代码更难阅读，更新也更慢。 尽管您从XCTAssert中没有任何帮助，但Nimble会显示一条默认消息，告诉您期望值与实际值之间的关系。

Nimble还可以使用toEventually和waitUntil优雅地处理异步代码。

最终，该功能将定期检查并在expect解决或超时时继续运行。 UI测试和等待动画解析时特别方便。

  DispatchQueue.main.async { 
  ocean.add（“海豚”） 
  ocean.add（“鲸鱼”） 
  } 
 期望（海洋）。到最终（包含（“海豚”，“鲸鱼”）） 

函数waitUntil允许您等到测试用例完成之前调用完成，从而使您在进行API测试时具有灵活性。

  waitUntil {完成 
  ocean.goFish {成功 
 期望（成功）。到（beTrue（）） 
 完成（） 
  } 
  } 

轻松整合Nimble

您可以将Nimble作为子模块或与Cocoapods一起安装。 在名册上，我们已经使用Cocoapods将依赖项引入我们的iOS应用程序，因此我们选择也使用它来安装Nimble。 Cocoapods易于使用，并拥有一个有用的社区。 您想确保只将其添加到测试目标中，而不将其包括在主应用程序目标中。 我们的文件如下所示：

 平台：ios，“ 11.0” 

 目标“名册” 
  use_frameworks！ 
  hibit_all_warnings！ 

  ..主要应用程式广告连播.. 

  abstract_target“测试” 
  Pod'Nimble' 

 目标“ UnitTests” 
 目标'JsonApiIntegrationTests' 
 结束 
 结束 

那快呢？

Quick是一个具有行为驱动开发理念的测试框架。 它看起来与您在网络上看到的许多测试框架相似。 它是由同一社区构建的，许多人将其与Nimble结合使用。 Quick使用一个称为spec函数来定义测试。 在spec内，您已经describe ， context及其相关it 。 这提供了将不同案例组合在一起的灵活性。

另一方面，XCTest内置在XCode中并且非常简单，但是您确实需要学习如何正确使用setup和tearDown 。 我们目前仅使用Nimble和XCTest。 尽管Quick有很多好处，但思想上的转变和迁移现有测试的工作量还很大。 虽然迁移到Nimble通常很简单，就像用XCTAssert替换XCTAssert ，要了解Quick的优点，您需要花费更多时间进行重新思考和重写。

继续运送

始终需要在快速行动与彻底测试之间取得平衡。 最终，Nimble帮助花名册团队花费更少的时间进行测试，并花费更多的时间进行发布。