Tag: xctest

五个针对iOS XCUITest的真实设备云测试服务: XCBlog上的原始博客在这里苹果在WWDC15中推出了Xcode UI测试解决方案，从那时起，它已成为iOS开发人员使用同一框架编写单元和UI测试的首选。以前，QA工程师使用诸如Appium和Calabash之类的框架来自动化iOS应用程序测试。这些框架允许使用疯狂的语言（如Java，Ruby等）编写用户界面测试，而这些语言与iOS应用程序开发无关。虽然，Appium和Calabash在质量检查世界中很受欢迎。它从未引起任何iOS开发人员的注意，这在开发人员和测试人员之间造成了巨大的技术鸿沟。苹果公司提供的XCUITests允许开发人员在Swift或Objective-C中编写测试，这有助于弥合技术差距并比以往更轻松，更快地创建UI测试。市场上有太多的云测试服务可用于在Web应用程序的云机中执行测试，例如Sauce Labs，BrowserStack等。最初，很少有服务关注XCUITest，因为许多公司仍在使用Appium和Calabash和他们已经支持这些工具在云中运行测试。但是，随着Apple不推荐使用诸如Appium和Calabash之类的工具的仪器技术，iOS 10版本改变了一切。这打破了所有的移动测试自动化框架，必须使用苹果公司的新技术XCUITest。然后，公司开始直接使用XCUITest，并且开始流行。云测试供应商还需要增加支持以保持市场竞争力。在本文中，我们将看到在云中的真实设备上运行XCUITest的选项。请注意，本文不是关于服务的速度，价格或使用情况的比较。 1.位栏 Bitbar具有专门针对移动测试自动化而设计的设备云，该设备云遍及欧洲的多个数据中心。作为仅限移动设备的测试服务，Bitbar是在云中支持XCUITests的先驱之一。很久以来，他们都在其官方博客上撰写有关XCUITest和iOS自动化的文章。它们与移动DevOps工具集成在一起，并具有远程调试功能。您可以在一段时间内免费试用Bitbar。 Bitbar有很多客户，包括Microsoft，Skype，EA，Asus，Paypal，T-Mobile等。 2. AWS设备场 Amazon Web Services提供了各种软件开发服务，包括Device Farm，用于针对AWS云中的实际移动设备进行测试。 AWS Device farm包含有关如何使用各种框架（包括XCUITest）执行测试的出色文档。我们可以将AWS服务与我们的免费套餐帐户一起使用进行试用。 AWS Device Farm已被包括Etsy在内的多个客户端使用。 3. Perfecto Perfecto是对移动Web应用程序进行基于云的连续测试的另一种选择。 Perfecto提供了在真实设备云中执行XCUITests的支持。他们拥有有关包括XCUITest服务在内的各种服务的文档，视频和代码示例的丰富信息。您可以在此处阅读有关配置XCUITests for Perfect cloud的更多信息。 Perfecto使用他们的服务有各种各样的客户。这里列出了超过100个客户。 4. BrowserStack BrowserStack是另一项服务，最近宣布在其真实设备云上支持runningXCUITests。这里有关于如何在BrowserStack上设置XCUITests的文档，它们还在此处与示例iOS项目共享了配置XCUITests的代码示例。 5.酱汁实验室 Sauce Labs在测试自动化社区中非常活跃，并举办多个活动和会议。 […]

使用工具链在Xcode中切换Swift版本: 原始文章发布在XCBlog上毫无疑问，Swift是开发iOS应用程序的出色编程语言。但是，由于Apple已将Swift开源，因此它正在经历重大的重大变化。 Swift每天都在发展，但我们必须确保我们的应用程序或库仍可在不断变化的Swift中工作。苹果一直都在用新版本的Swift发行新的Xcode版本，这通常要求iOS开发人员切换Xcode版本或同时保留多个版本的Xcode。在本文中，我们将看到如何在多个Swift版本之间切换而不更改Xcode版本。 Xcode和Swift 在进入更改Swift版本之前，让我们先谈谈Xcode和Swift版本是如何相互关联的。 Xcode的新版本始终具有Swift的最新稳定版本，例如Swift 4.1随附的Xcode 9.3。我们总是可以在发行说明中找到带有Xcode的Swift版本。默认情况下，位于/Applications/Xcode.app/Contents/Developer/的Xcode开发人员目录。但是，如果安装了多个Xcode版本，则可以使用xcode-select实用工具切换Xcode开发人员目录。例如，对于beta版本，我们可以使用切换到beta Xcode $ sudo xcode-select —切换/Applications/Xcode-beta.app/ $ export TOOLCHAINS = swift 检查当前使用哪个Swift版本也很重要。我们可以检查Swift版本，只需运行以下命令即可。 $ swift-版本 Apple Swift版本4.1（swiftlang-902.0.48 clang-902.0.37.1）目标：x86_64-apple-darwin17.5.0 这将打印最近Xcode版本正在使用的Swift的现有版本。我们可以使用以下命令检查Swift二进制文件的位置。 $ xcrun -f swift /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swift 如果我们还有其他Swift版本可用，则Xcode可以通过Xcode目标的build设置选项卡中的build设置$ SWIFT_VERSION使用不同版本的Swift。我们可以从终端使用以下命令快速扫描构建设置。 $ xcodebuild -showBuildSettings | grep SWIFT_VERSION 这将打印当前Xcode项目中正在使用的当前版本。请注意，此命令必须从iOS项目的根目录运行。获取新的Swift工具链由于Swift是开源的，因此所有更新的活动开发都发布在swift.org网站上。 Swift的最新快照始终可以从此处的网站下载。我们必须从那里在本地macOS机器上下载Swift快照，然后才能使用它。 […]

为iPhone和iPad构造iOS XCUITests: Apple的XCUITest框架是iOS应用程序UI自动化的热门且新兴框架，自从WWDC 2015推出以来，受到了广泛关注。 XCUITest允许我们在Swift中为iOS应用编写UI测试，这使iOS开发人员可以轻松为iPhone和iPad的iOS应用添加UI测试。必须同时考虑XCUITests的iPhone和iPad，因为使用iPad上的应用程序的用户不能被忽略。使用XCUITest，由于使用相同的框架（即XCTest）编写了单元和UI测试，因此持续集成和持续交付变得轻而易举。在XCUITest之前，Appium，Calabash等工具允许使用其他语言（如Ruby或Java）编写UI测试，这成为CI / CD和iOS开发流程的难题。 XCUITest可以为iOS应用编写，但是iOS设备具有不同的变体，例如具有不同屏幕尺寸的iPad和具有不同屏幕尺寸的iPhone。我们必须确保XCUITests可以在所有变体上完美运行，而不会引起很多重复。如果XCUITest的架构正确，那么我们可以避免重复代码，并且仍然能够在不同版本上运行所有XCUITest。在本文中，我们将介绍如何为iPhone和iPad构建XCUITest。 XCUI测试 XCUITest新手肯定应该观看WWDC视频，以了解XCUITest框架的基本功能。 XCUITest允许我们使用Apple自己的编程语言Swift为iOS应用编写测试。它与其他第三方框架（如Appium，Calabash等）有很大不同。如果您想将XCUITest与Appium进行比较，请阅读这篇文章，以更好地了解每个框架。如果您想了解所有新XCUITest功能的动手探索，请参考我以前的博客文章“使用Xcode 9的新XCUITest功能”，其中我已详细介绍了几乎所有功能。您可以按照DZone上这篇博文中提到的为XCUITests设置面向协议的体系结构，第二部分可以在这里获得。我们可以使用WWDC 2017演讲中有关可测试性工程的演讲中提到的一些技术来使XCUITest可扩展bu，重点是可测试代码。 UIDevice和XCUIDevice 苹果提供了UIDevice类来获取当前设备的表示，并提供了XCUIDevice类来模拟物理按钮和设备方向。如果我们正确地组织了XCUIElement，那么在iPhone和iPad上进行架构测试就变得如此容易。使用UIDevice API，我们可以使用以下代码获取当前运行测试的设备如果UIDevice.current.userInterfaceIdiom == .pad { //做iPad的东西 } 使用XCUIDevice，我们可以使用以下代码将设备方向设置为横向或纵向 XCUIDevice.shared（）。orientation = .landscapeRight 这两个API对在iPhone和iPad上设置XCUITests极为有用。避免两个套房在许多项目中，我看到人们为iPhone和iPad创建了两个单独的测试套件。在iPad和iPhone中，有两种单独的Xcode方案可以执行测试。在整个测试中也有条件执行，这对于管理测试套件很困难。我们不需要像使用本文中提到的方法那样进行操作。稍后，我们将尝试找到解决这些问题的方法。组织XCUIElement 在iPad和iPhone上构建XCUITests时，以适当的格式组织XCUIElement非常重要。我强烈建议使用Swift枚举来组织屏幕上的元素。请将此帖子参考XCUITest的面向协议的体系结构。在我最近的有关使用Swift枚举组织XCUIElement的文章中，我解释了如何按照屏幕组织元素。假设我们的iOS应用程序有一个主屏幕，其中包含三个按钮和两个静态文本。我们可以这样写枚举导入XCTest 枚举HomeScreen：字符串{ case guestButton =“你好” […]

单元测试: 单元测试提供了一段代码必须满足的严格的书面合同。结果，它提供了几个好处。单元测试会在开发周期的早期发现问题。理想情况下，每个测试用例都相互独立。单元测试通常由软件开发人员编写和运行，以确保代码符合其设计并按预期运行。单元测试的好处使流程敏捷当您敏捷开发产品时，更改是您需要牢记的最重要的事情之一。当您的应用程序功能不断增长时，更改已经测试的代码非常危险且成本很高。但是，如果我们在正确的位置进行了测试，则可以放心地进行重构。单元测试确实与各种口味的敏捷编程紧密结合，因为它内置测试，使您可以更轻松地进行更改。换句话说，单元测试有助于安全重构。 2.代码质量单元测试可以提高代码的质量。它确定在进一步发送代码进行集成测试之前可能出现的每个缺陷。在实际编码之前编写测试会使您对问题的思考更加艰辛。它暴露了极端情况，使您可以编写更好的代码。 3.尽早发现软件错误由于单元测试由在集成之前测试单个代码的开发人员执行，因此可以很早地发现问题，然后就可以解决问题，而不会影响其他代码。 4.促进变更并简化集成单元测试允许程序员在以后重构代码或升级系统库，并确保该模块仍然正常工作。单元测试检测可能会违反设计合同的更改。它们有助于维护和更改代码。单元测试可减少新开发功能的缺陷或减少更改现有功能时的错误。 5.提供文件单元测试提供了应用程序的实时文档。希望了解特定单元提供什么功能的开发人员可以参考单元测试以了解该单元的应用程序编程接口（API）。 API根据输入，输出和基础类型指定组件。 6.调试过程单元测试有助于简化调试过程。如果测试失败，则仅需要调试代码中最新的更改。 7.降低成本试想一下，在开发的后期阶段（例如在系统测试或验收测试期间）发现错误的代价。当然，较早发现的错误更容易修复，因为较晚发现的错误通常是许多更改的结果，并且您真的不知道是哪个原因导致了该错误。

重新启动失败的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时间，但是在我们的示例中，它注定要失败。但是，应该注意的是，虽然强制执行了重新启动测试的操作，但这并不是维持稳定性的最佳方法，因为您的应用程序已成为海森堡的目标。因此，重新启动测试，减少重新启动它们的频率。到此为止。谢谢大家，在接下来的笔记中见（

宣布iOS DevOps Book的预告片: 很高兴宣布我在iOS DevOps上写书的新冒险，该书涵盖了将优质应用交付给AppStore的几乎所有内容。本书旨在通过应用实用的Mobile DevOps和Continuous Delivery技术解决iOS开发方面的挑战。本书将帮助您的iOS团队自动化iOS应用程序的整个发行过程，包括分析，构建，测试，实现并分发到App Store。您还将了解如何处理复杂的iOS开发任务，例如Apple开发证书，供应配置文件，代码签名和分发到AppStore Connect。本书还介绍了iOS中流行的软件包管理器，以及如何为iOS应用选择合适的软件包管理器。我们还将介绍iOS持续集成（又名CI）的详细过程，以及如何为iOS应用设置持续集成。这本书将包含六个主要部分连续交付和移动DevOps的基础 iOS套件管理员 iOS部署管道 iOS持续整合 iOS代码签名和AppStore Connect Xcode UI测试（XCUITest）这将是本书的暂定结构，并可能随着我们写作的进行而改变。如果我们错过了本书要涵盖的内容，请告诉我们，我们很乐意在本书中涵盖有关DevOps，CI / CD或Test Automation的所有内容。如果您对此书感兴趣，请在此推文。阅读本书的全部内容，请点击此处如果您对iOS DevOps，CI / CD和Test Automation感兴趣，请发推文。像XCBlog的 XCTEQ 发布的帖子一样？您可能还喜欢我们的一些服务，例如访客博客或Mobile DevOps（CI / CD）或测试自动化。在 Github 上搜索我们的服务，开源项目，或者在 Twitter ， Facebook ， Youtube 和 LinkedIn 上关注我们 […]

iOS管道中DevOps友好XCTest的重要提示: 最初在这里发布在XCBlog上苹果已经引入了XCTest框架，可以为各种苹果平台创建单元，集成，性能和UI测试。 XCUITest是XCTest之上的一个性感扩展，它使开发人员可以为iOS和macOS应用编写UI测试。自从在WWDC 2015中启动以来，XCUITest受到了很多关注和增强。它使用Swift语言创建测试，这使iOS开发人员可以轻松地使用相同的编程语言为iOS应用程序添加UI测试。另一方面，DevOps和Continuous Delivery实践诱使企业在开发新功能后立即发布它们。根据权衡，单元和集成测试是轻量级的，并且速度更快。但是，UI测试非常缓慢，难以维护。许多移动测试金字塔表明，我们应该进行最少的UI测试，并涵盖业务逻辑较低级别的轻量级测试。但是，UI测试是不可替代的，并且如果执行得当，则可以在更高的级别上提供更多的价值。就发布应用程序的信心而言，单个UI测试可以击败数千个单元测试。为了混合使用DevOps和XCTests的实践，我们必须在不干扰CI / CD管道的情况下，就如何编写XCTest做出一些明智的决定。在本文中，我们将介绍一些对DevOps友好的XCTests的技术。为了允许频繁发布iOS应用，设置和维护CI / CD管道非常重要。 iOS开发中最痛苦的事情之一就是发布了该应用程序。它涉及许多活动，这些活动可能容易出错，重复且耗时。 CI / CD管道的作用是使所有无聊的任务自动化。典型的iOS发布管道包括以下内容查看源代码 Swift代码的静态分析（例如SwiftLint）编译和构建iOS应用运行各种测试，例如单元，集成，API，UI，性能，安全性代码签名和存档iOS应用将iOS应用分发到iTunes Connect或第三方测试服务创建标签或在Source Control上发布，例如Github Releases 最后但并非最不重要的一点是，通过发行说明通知人们有关新版本的信息可能有更多的东西正在筹备中，但上面列出了一些非常常见的东西。很明显，如果没有自动化测试，CI / CD管道将无法完成。自动化测试提供了释放iOS应用程序的价值和信心，而无需担心。现在，我们将看到如何精巧地编写XCTest，以在不影响iOS应用程序质量的情况下加速管道。用单元测试覆盖所有生产代码始终是一个好主意，这样Continuous Integration可以在生命周期的早期检测到错误。单元测试通常写得很快，而且琐碎。使用XCTest，我们可以通过编写单元测试来覆盖大多数代码。在某些情况下，我们必须编写集成测试，而单元测试不足以覆盖业务逻辑。进行轻量级和更快的测试的好处是生成速度更快，可以提供早期反馈。苹果在这里用XCTest框架编写单元测试的文档非常丰富 iOS应用程序使用后端或服务器端API是一种非常常见的做法。确保iOS应用使用的API遵循消费者驱动的合同，这一点非常重要。否则，他们可能会完全破坏iOS应用程序。 […]

没有人期望完成调查！: 如何测试非调用完成处理程序方案使用XCTestExpectation测试完成处理程序API幸福路径场景非常简单。如果您的测试用例必须验证给定的处理程序是否未被调用，事情就会变得复杂。如果在您模拟的其他事件之后同步调用它，则仍然很简单。但是，如果延迟执行时间呢？在本文中，我将向您演示一种解决方案，以100％确保不会调用给定的完成处理程序-快速可靠。我们来谈谈提供完成处理程序的一些异步任务的单元测试，比如说从服务器下载JSON。似乎很明显，我们必须验证在快乐路径方案中是否调用了完成。 XCTest提供了一个不错的API：只需创建一个期望，在完成时实现它，然后在测试结束时等待所有实现：天真的解决方案另一种方法是稍等片刻，并假设只要未完成完成（例如0.1s），它就永远不会执行。它有两个明显的缺点：您必须猜测要等待多长时间。是0.1s还是0.01s？如果设置不正确，很容易导致测试无效或不稳定。它增加了单个测试的持续时间，默认情况下默认应尽可能快。这两个缺点都可能导致危险的陷阱：当测试花费的时间太长或不稳定时，您的队友（或将来的您）就会开始忽略它们，而迟早就放弃它们。让我问一个问题：您何时能100％确定系统的某些外部部分永远不会调用完成？答：在没有人保留的情况下，不再有完成任务！为了验证没有什么延迟执行块，我们必须确保所有其他实例都丢失对完成的引用。好的，听起来很简单！但是如何实施呢？当然，我们不能定义对块的弱引用： ‘weak’ may only be applied to class and class-bound protocol types 。因此，让我们定义简单的类ReferenceObserver ，它仅通知其deinit ：目前，我们对ReferenceObserver实例有两个引用： reference和capturedReference （已完成）。注意：我们必须将虚拟分配添加到匿名变量 _ ，否则Swift根本不会捕获它。如您所料，让我们摆脱助手参考（只是调用reference = nil ）和voilà之一：只有完成处理程序块会保留对ReferenceObserver并且一旦从内存中删除了完成处理程序， deinitCompletion自动满足deinitCompletion期望：这是我们的最终测试：我们最终得到了一个解决方案，该解决方案是：不需要增加测试持续时间，因为在ReferenceObserver […]

在Swift中测试网络层-第2部分: 使用XCTest框架编写单元测试用例在上一篇文章中，我们讨论了如何编写可测试网络层。在本文中，我们将讨论如何为该网络层编写单元测试。基本上，要执行单元测试，我们必须知道给定输入的预期输出。请记住，我们从来没有真正在物理服务器上运行过测试，因此我们无法测试所有可能的情况。对于每个APIHandler，我们都有两种方法来执行测试，如第1部分所述。 func makeRequest（来自参数：[String： Any ]）->请求 func parseResponse（data：Data）抛出 -> LoginResponse 测试API请求：对于LoginAPI ，我们可以通过检查所有请求参数（例如http方法，http正文，url，标头字段等）来确认请求已正确准备。测试API响应：响应可能是成功，也可能是服务器返回的错误。对于LoginAPI ，以下是成功响应测试用例。我们可以如下测试服务器错误，例如状态203、400等，它们将返回ServiceError对象。

WWDC18：代码覆盖率，XCTest和XCUITest的新增功能: 在WWDC18上，有一个有关“测试中的新增功能”的会议，描述了代码覆盖率，XCTest和XCUITests中的新功能。它由Honzaand Ethan提出。本届会议包括以下内容 xccov的代码覆盖率从方案中选择测试随机检验并行测试并行测试技巧幸运的是，我已经在以前的博客文章中介绍了本次演讲中介绍的大多数内容。由于xccov已随Xcode 9.3一起启动，因此我在个人博客和Medium上都写了一篇详细的博客文章，内容涉及xccov的所有功能。 Xcode 10宣布了Xcode 10的并行测试功能，我已经在行动博客文章中介绍了Xcode 10中的大多数并行测试，该文章也发表在了Medium上。您随时可以随时在会话中观看实时演示。但是，我们将简要介绍本届会议上提到的功能。代码覆盖率苹果已经发布了带有Xcode 9.3的新命令行工具xccov，用于检查Xcode代码覆盖率报告的内容。我们可以通过编辑方案并在“测试”操作中选中“代码覆盖率”框来明确启用该方案的代码覆盖率。使用代码覆盖率数据运行测试后，Xcode会将代码覆盖率报告生成到默认的派生数据目录中，该目录位于〜/ Library / Developer / Xcode / DerivedData中，您将在Logs / Test目录中看到生成的代码覆盖率报告。我们将看到扩展名为.xccovreport和.xccovarchive的代码。在Logs / Test目录中，有覆盖率报告（扩展名为.xccovreport）和覆盖率存档（扩展名为.xccovarchive）。按照此实用程序的手册页，“覆盖率报告包含每个目标，源文件以及具有覆盖率信息的功能/方法的行覆盖率百分比。 Coverage存档包含报告中每个文件的原始执行计数”。目前，我们可以使用xccov实现以下目的从终端查看代码覆盖率报告从代码覆盖率报告中吐出JSON。列出所有已生成代码覆盖率的文件查看一个特定文件的代码覆盖率报告。观看如何查看实际的代码覆盖率。这减轻了使用第三方工具以美观的格式显示Xcode代码覆盖率报告的麻烦。我们也可以跳过不需要的目标的代码覆盖范围。 XCTest方案选项使用Xcode 10，我们可以从方案中选择特定的测试，将测试随机化并并行执行测试。我们可以通过更新方案来启用并行测试，并且在“测试”操作中，可以针对测试包选择“选项”以选择并行化选项。我们也可以选择位置。通过创建仿真器的克隆，测试可以扩展到并行化单个仿真器中的测试套件。 Xcode在后台创建了不同的运行程序流程，每个流程都分配了特定的测试。可以使用xcodebuild工具从命令行运行XCTest。使用Xcode […]