Tag: xctest

使用Swift枚举组织XCUIElement

使用XCUITest框架自动化iOS应用程序可以确保从用户的角度来看,该应用程序可以按预期运行。 自Apple在WWDC 2015中推出UI测试支持以来,此框架在iOS开发人员中广受欢迎,因为他们现在可以在Swift和XCTest框架中编写与单元测​​试相同的UI测试。 在这篇简短的文章中,我们将看到如何更好地使用Swift枚举在屏幕上组织XCUIElements(即定位器)。 这是我一个聪明的同事在工作中分享的一个简短技巧。 在Selenium或Appium世界中,您可能听说过一些用于抽象或存储UI元素的模式,例如页面对象或屏幕播放。 我们可以将UI元素存储在单独的类或Struct中,然后可以在测试或步骤定义等中访问这些元素。在Swift中,我们可以利用Swift枚举来存储我们的UI元素(也称为XCUIElements)。 Swift枚举比类和结构好得多,因为我们可以根据需要向枚举添加函数。 使用枚举的另一个好处是,我们可以在整个UI目标上访问枚举,而无需创建对象或引用为静态值。 假设我们的iOS应用程序有一个主屏幕,其中包含3个按钮,2个静态文本。 我们可以很容易地用这6种情况编写一个枚举。 导入XCTest 枚举HomeScreen:字符串{ 案例guestButton 案例寄存器按钮 案例loginButton 案例welcomeText 案例介绍 var元素:XCUIElement { 切换自我{ case .guestButton: 返回XCUIApplication()。buttons [“ Hello”] 案例.registerButton: 返回XCUIApplication()。buttons [“注册”] 案例.loginButton: 返回XCUIApplication()。buttons [“登录”] 案例.welcomeText: 返回XCUIApplication()。staticTexts [“ Welcome”] 案例.introText: 返回XCUIApplication()。staticTexts [“ app简介”] } } } 现在,我们已经使用可以在UI测试目标中任何位置使用的Swift枚举定义了主屏幕中的所有元素。 这是我以前采用的一种方法,在我之前编写的BDD工具XCFit中也对此进行了说明。 这种方法没有错,因为我们可以根据需要独立访问所有这些元素。 但是,有一种更好的方法可以使用Swift枚举,这样我们可以节省很多代码并仍然达到相同的结果。 在前面提到的方法中,我们已经分别定义了所有元素,我们可以通过以下方式重构上面的枚举 按类型对XCUIElement进行分组,例如按钮,静态文本 将值分配给枚举案例,通常是元素的可访问性标识符 然后,我们可以在XCUIElements中使用案例的原始值。 因此,我们可以重构上面的枚举,如下所示。 导入XCTest 枚举HomeScreen:字符串{ case […]

与Fastlane和Bluepill并行运行XCUITests

注意:Apple已发布了Xcode 9的并行测试功能,因此,本文中提到的Bluepill工具现在意义不大! LinkedIn最近开源了Bluepill,该工具可以并行运行iOS测试。 在LinkedIn工程博客上有Bluepill公告博客文章。 Bluepill并不从头开始支持Apple的XCTest和XCUITests框架,但是在最新版本v1.0.0中,我们可以使用Bluepill并行运行XCTest和XCUITests。 蓝丸功能 Bluepill具有一些很棒的功能,您可以在Github README上阅读全部详细信息,但总而言之,我们可以 与多个模拟器并行运行XCUI测试。 将测试分散到多个模拟器中,并允许以无头模式运行测试。 每个模拟器生成报告并重试失败的测试。 蓝丸限制 除了一些出色的功能,Bluepill还具有一些局限性,如下所示 Bluepill的安装过程很痛苦。 用户必须从Github手动下载二进制文件或下载源代码并构建框架以获取二进制文件。 理想情况下,它应该是像Homebrew一样的软件包或其他软件包管理系统,以使安装变得容易 有两个二进制文件“ bluepill ”和“ bp ”,运行测试需要同时进行。 目前,“ bluepill”二进制文件具有用于自制程序包的公式,但是“ bp”二进制文件没有任何公式。 Bluepill遍历了测试目标,但是可能存在更快的方法来解析.xctestrun文件以找到测试。 TravisCI构建长期未维护为红色。 Bluepill缺少用户文档。 撰写本文时,github上的文档目录仍然为空。 希望LinkedIn的Bluepill团队将在不久的将来为解决这些问题做出一些努力。 蓝丸和Fastlane婚姻 根据github上当前的Bluepill使用情况信息,我们必须使用xcodebuild’build for testing’操作通过XCTest构建应用方案,以便我们可以派生数据以与Bluepill一起使用。 然后,我们可以将’app_path’,’scheme_path’,’output_directory’和其他标志传递给bluepill以并行运行测试,或者使用配置有这些标志的use JSON文件将其传递给bluepill。 通过与Fastlane结合使用,我们可以使此过程更加动态,Fastlane是用于自动执行iOS开发任务的工具。 在这篇文章中,我们将看到如何配置Bluepill与Fastlane一起运行! 设置Xcode项目 让我们开始在Xcode中创建一个名为“ Single View Application”的新iOS项目,并将其命名为“ Bluepillar”,同时选中“ 包括UI测试”框。 不要选中“ 包含单元测试”或“将此示例使用核心数据 ”复选框。 现在,Xcode为我们生成了项目模板,让我们复制模板UI测试六次将其命名为OneBluepillarUITests.swift,TwoBluepillarUITests.swift等等。 不要忘记相应地更改类名。 在此阶段,我们的Xcode项目应如下所示: 现在,我们有六个测试在做相同的事情,但是对于并行测试演示来说,这无关紧要。 安装Bluepill 当前,我们可以通过运行以下命令使用Homebrew安装Bluepill $ brew安装bluepill […]

BDD使用XCUITest的XCTActivity功能吗?

苹果公司最近宣布了XCUITest框架的新功能。 活动的一项重要功能就是可以将XCTest操作组织为人类可读的活动。 新协议XCTActivity已添加到XCTest框架。 注意:本文最初发布在我的个人博客上 什么是XCUITests中的活动 通常,UI Tests在执行过程中会执行许多操作,例如,点击按钮,滑动等。到目前为止,Xcode中的XCTest报告显示了测试报告中的所有操作,这些操作不是特别可读。 活动是通过提供有意义的名称将这些操作分组的方式,因此XCTest结果将在结果中使用该活动名称以使其更具可读性。 您可以在此处阅读有关Apple官方文档中活动的更多信息。 我们可以在任何动作上进行活动 什么是BDD BDD aka行为驱动开发是通过使用Gherkin或类似格式的可执行规范来开发应用程序的过程,以便程序员可以将这些规范用于开发,而业务人员可以将其用于需求规范或实时文档。 BDD是一种由内而外的开发方法。 您可以在此处了解有关BDD的更多信息 我们可以使用XCTActivity进行BDD吗? 让我们尝试回答这个问题。 想象一下,我们将创建一个Greeter应用程序,该应用程序在输入时会向用户致意。 所以我们的应用有两个要求 应用程序应具有输入按钮 当用户点击输入按钮时,它应该显示问候消息 让我们来编写这个的Gherkin功能文件: 功能:招呼用户 场景:用户应该看到问候语 给定的应用程序启动 当用户点击输入按钮时 那我看一下问候语 现在,我们以人类可读的格式编写了所有需求。 让我们深入研究代码。 在Xcode内创建一个名为Greeter的新单视图应用程序,并包括UI测试。 在我们的UI测试中,我们可以添加带有方案名称的测试和带有步骤名称的“活动”,如下所示 func testUserShouldSeeGreetingsMessage(){ XCTContext.runActivity(名称:“启动应用程序”) XCUIApplication()。launch() } XCTContext.runActivity(名称:“当用户点击输入按钮时”) XCUIApplication()。buttons [“ enter”]。tap() } XCTContext.runActivity(named:“然后我应该看到问候消息”){_ XCTAssertTrue(XCUIApplication()。staticTexts [“ Welcome”]。exists) } 当我们第一次运行测试时,它将失败,因为没有按钮或静态文本。 我们可以轻松实现按钮和静态。 使用辅助功能标识符“输入”将按钮添加到主故事板,并添加标签“ welcomeText”。 现在创建IBAction到按钮以在点击时显示“欢迎”文本。 我们的ViewController将如下所示: @IBOutlet弱var welcomeText:UILabel! @IBAction […]

Xcode 9的动手XCUITest功能

注意:本文最初发布在我的个人博客上。 继续阅读此处,因为某些GIF尚未上传到Medium。 在WWDC 2017上,有一个关于“测试中的新增功能”的精彩会议,主要讨论XCTest和XCUITest框架的新功能。 苹果公司开发人员工具团队在使用XCUITest进行UI测试以及与Xcode Server进行持续集成方面进行了重大改进。 在本文中,我们将通过Xcode 9和命令行中的实际示例探索所有新功能。 探索过程中创建了Github存储库Xcode9-XCTest。 您可以将这篇文章引用到该GitHub存储库,以自己尝试一下。 宣布了许多与针对Apple平台(尤其是iOS和macOS)的测试有关的新事物。 其中一些如下。 XCUISiriService 本地化测试 异步测试 UI测试性能改进 活动,附件和屏幕截图 多应用测试 xcodebuild:无头测试 xcodebuild:并行测试 内置Xcode服务器 测试过程中有很多增强功能,包括Siri集成,XCTest中的Waiting,xcodebuild中的Core Simulators等。 让我们一一介绍。 XCUISiriService 使用XCUISiriService,我们现在可以与Siri界面进行交互。 我们可以通过传递来自XCUITests的语音识别文本来控制Siri,Siri将采取相应的行动。 想象一下,我们想使用XCUISiriService打开一个Apple News应用程序,我们可以从测试中做到这一点。 func testXCUISiriService(){ XCUIDevice()。siriService.activate(voiceRecognitionText:“打开新闻”) } 几个月前,当我与Xcode 8.3一起宣布使用XCUISiriService从XCTest控制Siri时,我写了一个详细的博客,它还在Github XCUISiriServiceDemo上创建了演示项目,但API语法有所变化,但示例仍然有效。 实际例子 在Xcode 9中打开Xcode9-XCTest项目,然后从Xcode9_XCTestUITests.swift文件运行testXCUISiriService()测试。 您可以看到Siri将打开Apple News应用程序。 本土化 使用Xcode 9,我们可以使用Xcode方案在不同的Language和Region中运行测试。 在编辑方案时,我们会看到“测试”选项,以使用特定的语言和区域运行测试。 通过更改方案设置,我们可以轻松地用不同的语言和地区测试我们的应用程序。 异步测试 在很多情况下,我们需要等到事情发生以进行测试执行为止,例如打开文档,等待服务器的响应等,但这在UI测试场景中最常见。 到目前为止,XCTest通过创建期望来处理异步测试,并且测试将一直等到期望得到满足。 XCTest超时将导致测试失败。 期望与XCTestCase紧密相关。 现在,XCTest具有新的类XCTWaiter,它使我们可以显式定义与XCTestCase分离的期望。 它具有作为公共API的初始化程序,然后涵盖了不同的等待条件。 XCTWaiter等待一组期望被实现。 我们现在可以这样定义期望: […]

Swift中XCTest和XCUITest的网络存根选项

原始文章:原始文章已发布在我的个人博客XCBlog上,继续阅读 此处 以获得更好的图形。 要阅读有关iOS DevOps和iOS CI / CD的更多有趣文章,请 在此处 访问我的博客 。 不要害怕没有广告! 每个iOS应用程序都要求数据显示在应用程序中。 不幸的是,我们无法将所有数据放入我们的iOS应用程序中。 iOS开发人员必须提出网络请求,才能从互联网获取此数据并在应用程序中使用它。 苹果提供了各种库和框架(例如URLSession,NSURLProtocol)来处理网络层,并且有一些第三方框架(如Alamofire)可用于处理网络请求。 但是,由于在测试网络层时使用了不同的方法,因此以网络请求形式测试异步代码变得非常复杂。 在这篇详细的文章中,我们将探索在Swift中测试网络层的所有可用选项,并涵盖可与XCTest框架一起使用的网络存根库的详细信息。 Swift中的网络测试 使用Swift编写的iOS应用的网络测试可以根据项目需求在单元,集成或UI级别执行。 单元和集成测试通常是快速而稳定的,而UI测试则是缓慢而脆弱的。 根据我在互联网上阅读的内容,人们正在使用各种方法在iOS中进行网络测试,其中一些常见方法如下 在单元测试或集成测试中使用协议模拟类 模拟是脆弱而艰苦的,到Swift时模拟变得更加困难。 Swift中没有可用的成熟模拟库来生成类似Java,Ruby,Python或其他语言的模拟。 开发人员必须手动编写所有模拟,并将测试代码与生产代码紧密耦合。 这里有一篇很棒的关于iOS网络测试的文章,以了解有关如何使用协议进行模拟的更多信息。 这种方法无疑使该应用程序更具可测试性,但是它涉及编写很多协议和模拟类。 在Swift中,我们需要模拟我们需要测试的大多数类和方法。 对于iOS开发人员而言,这将是繁重的工作,很快便陷入混乱。 记录和播放网络请求 Swift具有一些库,这些库使我们能够记录网络请求并进行回放,从而避免单元测试通过网络层。 它们将记录的数据存储在文件中,并且该数据被重用而不是进行网络调用。 最受欢迎的库是DVR,可对iOS应用发出虚假的NSURLSession请求。 还有另一个库Szimpla可以执行类似的操作。 您可以在这里在Szimpla上观看会议,在Realm学院中在DVR上观看会议。 使用库存根网络请求 网络层还有另一种方法,它是进行网络调用而不是模拟URLSession并返回存根或静态响应而不是真实响应。 使用存根,我们仍然可以实现网络测试的目标,并且不必将测试代码与生产代码紧密耦合。 我们将看到可用于通过Swift存根网络请求的库的详细信息。 一些最受欢迎的库是用于XCTest(unit)测试的OHHTTPStubs,Mockingjay,Hippolyte。 使用XCUITest框架与UI进行交互 用户界面测试贯穿网络层,涵盖了网络测试的所有方面。 苹果有XCUITest框架来涵盖Xcode UI测试。 我们可以使用一些库来为UITest存根网络。 一些流行的库是Swifter,SBTUITestTunel和XCUITest(UITest)的Embassy。 上面提到的所有方法都各有利弊,因此选择适合项目需求的方法至关重要。 在这篇文章中,我们将看到如何为单元和用户界面测试配置网络层。 Git定位应用 我们将在整个演示中使用GitHub API。 我们将向URL https://api.github.com/users/shashikant86发出网络请求,并从API获取位置并显示在应用程序中。 您可以通过在浏览器中访问JSON响应来查看它。 […]

XCFit 7.0发布:XCTActivity,新的Xcode模板和多个CI服务支持

XCFit-7.0的新版本刚刚发布,具有一些新功能。 XCFit在版本6.0发行版中已经支持Xcode 9和Swift 4。 XCFit是Xcode for iOS应用程序中Xcode的面向全栈协议的BDD,使用Swift使用XCUITest。 XCFit允许我们使用诸如Give / When / Then格式的工具以人类可读的语言编写Swift的BDD样式API /合同级别,UI和验收测试。 在这篇简短的文章中,我们将看到XCFit-7.0的新功能。 此版本具有一些新功能,例如XCTActivity,新Xcode模板和持续集成服务支持。 我们将详细介绍以下新内容 XCTActivity支持 Xcode 9和XCTActivity支持的新Xcode模板 对XCFit的多个持续集成服务支持 UI测试通常是长时间运行的,并且在那里发生许多动作,例如,点击按钮,滑动等。到目前为止,XCTest报告显示了测试报告中的所有动作,这些动作不是特别可读。 活动是通过提供有意义的名称来将这些操作组织到组中的方法,因此XCTest结果将在结果中使用该活动名称以使其更具可读性。 您可以在此处阅读有关Apple官方文档的更多活动。 我们可以将活动分散到任何一组操作上,例如以干净状态启动应用程序 XCTContext.runActivity(名称:“鉴于我已经以干净状态启动了应用程序”) XCUIApplication()。launchArguments = [“ -StartFromCleanState”,“ YES”] XCUIApplication()。launch() } 当我们运行测试时,然后在测试报告中,我们将看到“鉴于我已经以干净状态启动了该应用程序”,因此更具可读性。 我们仍然可以通过扩展活动来访问基本操作。 XCTActivity现在支持XCFit预定义步骤。 现在,所有步骤都包装在XCTActivities中,以便可以读取Xcode报告。 您将在本文结尾的演示视频中看到这一点。 如果您使用过XCFit,那么您可能知道XCFit提供了Xcode模板,以开始使用Xcode中的面向协议的BDD。 可以使用Rubygem安装XCFit模板 $ gem install xcfit 如果您正在使用系统(预安装)Ruby(2.0),则可能需要使用sudo。 XCFit gem将用于为Xcode设置所有Xcode模板。 当前的Xcode模板具有Xcode组结构,如下所示 Feature.swift 该文件具有您的功能,它将所有可以作为验收测试实现的需求(测试)。 该文件包含Swift协议。 FeatureSteps.swift 该文件包含模板代码,该模板代码如何在功能协议之上使用Swift扩展实现给定功能的步骤定义。 它还提供了一些示例,这些示例在实现步骤定义时如何使用XCTActivity。 FeatureElements.swift 该文件包含与功能有关的所有XCUIElement。 […]

单元测试和使用旧版代码

关于编写好的软件以及当您想要添加或删除功能时如何重构代码库的文章很多,但是大多数现有文献在示例中都使用C或Java。 在这里,我将尝试展示iOS开发人员如何使用XCTest来帮助维护旧版Swift代码。 什么是旧代码? 旧版代码基本上是任何现有代码-不管它有多旧。 但是它越老,即使您写了它,也不太可能熟悉它。 并且您希望能够对其进行修改,并且不会破坏现有功能。 我们要达到什么目标? 有很多原因需要接触遗留代码,但是它们通常分为以下几类: 修正错误 由于业务规则的改变而改变行为 扩展功能以支持新功能 如果幸运的话,我们不需要进行任何重大更改即可执行上述任何操作,但是通常我们需要重构代码以实现我们的目标。 这可能很简单,例如花费几行代码并将其提取到一个单独的函数中,或者复杂到将一个对象分解为几个单独的对象,从而导致无论从何处调用旧代码,都需要对整个代码库进行更改。 问题是,我们不想引入任何错误,除非我们对应用程序非常熟悉,或者代码库非常简单,否则我们很可能会破坏某些东西。 单元测试是我们的朋友 在更改任何代码之前,重要的是要确保我们先了解应用程序的功能,并知道更改代码后是否已更改该功能。 为了让我演示单元测试如何提供帮助,让我们想象一下我们有一个应用程序可以在UILabel中显示人员的姓名和地址。 我们将有一个简单的Person对象和一个带有返回标签文本的单个函数的视图模型。 Itty Bitty Apps 总部位于澳大利亚墨尔本, 为大小客户提供了出色的移动和Mac软件。 这也使 揭示   -适用于iOS开发人员的功能强大的运行时视图调试。

不起眼的TableView

我最近一直在考虑表视图。 表视图和集合视图已成为为许多类型的应用程序(尤其是内容驱动的应用程序)构建UI的默认方法。 但是,随着我们的表格视图变得越来越复杂,很难测试它们是否显示了正确的内容。 我认为创建可测试表的许多困难源于一种模式,在这种模式下,我们具有描述应用程序域的模型对象,然后尝试将其显示在表中。 尽管这些模型完美地描述了应用程序域的特定问题,但它们可能无法完全描述我们要在特定表单元格中显示的内容。 让我们看一个例子,然后看看如何改进。 我将使用表视图,因为它稍微简单一些,但是您也可以将这些技术应用于集合视图。 您的应用程序中可能有一些模型对象,它们描述了您的应用程序所关注的领域。 例如,如果您制作一个社交应用程序,则可能具有User , Friend和Message对象。 您可能是通过从api获得的Json表示形式创建对象来获得这些对象的,并在整个应用程序中使用它们来对应用程序的域进行建模。 在我们的示例中,我们可以想象一个音乐流应用程序,其中有一个特定艺术家的屏幕,其中显示了可以为该艺术家播放的所有曲目。 我们可能已经有一个域对象Track ,因此我们可以获取艺术家的所有Track ,并在表中显示它们: struct Track { let id:字符串 让标题:字符串 持续时间:双倍 让streamURL:URL } TrackCell类:UITableViewCell { func configure(track:Track){ //用轨道配置单元格 } } 好吧,还不错! 当用户打开艺术家页面时,我们将从MusicAPI获取Track ,并将其显示在表格中。 然后,该单元格可以显示曲目标题和持续时间,并且当用户按下播放时,我们可以开始流式传输。 通过此设置,我们直接从域模型( Track )转到UITableViewCell 。 但是,当我们必须在单元格中显示Track对象未描述的信息时,该策略就会Track 。 假设我们有一个新的要求–我们的应用程序现在可以下载轨道,并且需要在列表中显示每个轨道的下载状态。 我们的用户界面将如下所示。 在此示例中,已下载了第三首曲目,而其他未下载。 不幸的是,我们的Track模型现在无法完全描述TrackTableViewCell需要了解的所有内容。 我们是从MusicAPI获取Track的,但是我们需要参考DownloadsManager来确定是否在本地下载了轨道。 也许我们可以在创建单元格并将其分别传递给下载状态时调出给DownloadsManager ,甚至可以从单元格内部调用它,如下所示: TrackCell类:UITableViewCell { func configure(track:Track){ //用轨道配置单元格 downloadIcon.showDownloaded […]

Xcode 9的主线程检查器和XCUITests

苹果公司最近发布了Xcode 9的稳定版本,其中包含许多新功能。 大多数iOS开发人员都说Xcode 9是最好的版本,因为它具有iOS开发人员一直想要的强大新功能。 您可以在此处阅读有关Xcode 9功能的更多信息。 我们刚刚将现有的XCUITest套件迁移到Xcode 9,发现通过XCTest编写的单元测试通过了,但是XCUITests停止工作并出现以下错误。 主线程检查器:在后台线程上调用的UI API:-[UIApplication委托] PID:740,TID:51958,线程名称:(none),队列名称:FIRAnalyticsQueue,QoS:9 XCUITests根本无法启动代理测试运行器应用程序,并且测试套件崩溃了。 从错误消息中可以明显看出,这与Firebase SDK有关,并且与主线程检查程序有关。 你们中的某些人可能已经陷入这个陷阱,或者您将很快迁移到Xcode9。在本文中,我们将讨论该错误的全部原因,以及新的具有Xcode功能的主线程检查器将如何帮助捕获潜在的错误。在应用程序中。 在陷入错误之前,我们将学习WTF是Main Thread Checker,以及Apple为何将其作为Xcode 9的一部分引入的原因。根据文档,“ Main Thread Checker从后台检测到对AppKit,UIKit和其他API的无效使用”线。 “ 这是什么意思?。 iOS开发人员可以轻松理解这一点,但是对于其他人,我将尝试用简单的语言进行解释。 有一些Apple框架旨在仅在主线程中在iOS应用中使用,在后台线程中使用这些框架是一种罪过。 如果您在后台线程中使用这些框架,那么您可能会在下一生中下地狱。 如果iOS工程师在后台线程中使用这些框架,则会发生疯狂的事情,如UI响应迟钝,视觉缺陷,数据损坏和崩溃。 简而言之,在后台线程中使用这些框架将使您的iOS应用成为可能。 主线程检查器发现框架的这种无效用法,并在运行时警告工程师,不要这样做。 它可以检测出罪魁祸首,以便您在不解决问题时对其进行惩罚。 Main Thread Checker是方便的工具,可以尽快检测到代码中的错误。 默认情况下,它在Xcode 9中被激活。 XCUITest启动名为XCUIApplication的代理测试运行器应用程序,以在代理应用程序中启动测试。 相应方案的XCUITest的主线程检查器处于活动状态。 在启动应用程序的UI时,主线程检查器检测到Firebase SDK在后台线程中使用了UP API。 Firebase团队已修复了Github上存在的问题。 可能还有其他一些第三方框架可能存在相同的问题,例如Flurry用户也在此处在Github上报告了相同的问题,但在撰写本文时仍未解决。 我们几乎没有办法解决此问题并开始使用带有Xcode 9的XCUITests。 如果问题在应用程序内部,我们可以通过解决iOS框架无效使用的问题来修复XCUITests。 如果主线程检查器检测到Firebase SDK等第三方框架中的问题。 我们需要让他们立即解决问题。 如果主线程检查器检测到第三方框架中存在的问题,并且他们无法及时解决该问题,那么不幸的是,我们需要从该方案中禁用主线程检查器。 转到“产品”>“方案”>“管理方案”,搜索用于测试的方案,然后在左侧栏中按“编辑”,然后按“测试”,然后转到“诊断”并取消选中“主线程检查器”复选框 请记住,这不是理想的解决方案,这是我们不应该在代码中添加的hack。 我们应该专注于直接在代码中解决导致无效使用框架的问题。 我希望,当您遇到相同的问题并节省几个小时的调查时,您会发现这篇文章很有用。 您是否已将XCUITests迁移到Xcode […]

如何在iOS中将一个测试目标文件用于两个应用目标?

我搜索了许多解决此问题的方法之后写这篇文章。 但是我找不到解决我问题的合适方法。 实际上,问题是“我的应用程序中有两个目标分别为SampleB2B和SampleB2C 。 这两个目标相似,只是变化不大。 因此,当我尝试为两个目标编写XCTestCase时,我认为两个目标都有一个测试目标文件。 因为所有测试文件都是相似的。 因此,考虑为两个目标编写一个测试文件。 但是我找不到一种对两个目标使用相同的测试文件的方法。” 这是我在项目中使用测试用例文件的方法,以同时将测试用例文件用于两个目标。 请按部就班。 最初,我只有一个目标,后来又改变了要求。 因此,我需要再创建一个目标。 因此,我只是从现有目标复制来创建另一个目标,然后重命名以区分这两个目标。 完成后,将类似于下面的快照。 我有两个上述目标,有一个测试目标是在创建项目时创建的。 现在,我在“ SampleTests ”文件夹中有一个测试用例文件。 所以我需要使用相同的文件来测试两个目标。 所以我做了以下。 因此,现在,我们需要从上面的窗口中再创建一个测试目标。 不要从“文件”->“目标”创建测试目标。 如果要从中创建,则它将为新创建的创建测试目标文件夹。 实际上,在开始测试时,测试文件需要位于同一测试目标文件夹中。 这导致在两个测试目标中创建重复文件。 两个测试目标文件夹下的两个文件中的文件内容相同。 我想以更好的方式做到这一点。 因此,我尝试了其他任何方法来将相同文件用于两个测试目标。 因此,右键单击现有的目标SampleTests,然后单击重复。 然后重命名测试目标,以区分并重命名所有目标的Info.plist,并在“ 对应目标”->“构建设置”->“ Info.plist”文件名中提供相应的Info.plist文件路径。 一旦完成,它将像 现在,我有两个目标,其中两个是测试目标,一个是测试文件夹和测试文件。 2.为两个测试目标选择相应的主机应用程序,如下面的快照。 3.在两个测试目标的活动编译标志中添加标志,以在运行时区分当前目标。 选择测试目标->构建设置->活动编译条件,如下面的快照。 在B2B测试目标中添加B2B标志,在B2C测试目标中添加B2C标志。 它将在步骤5中使用。 4.在添加或创建新的测试用例文件时,请确保为两个测试目标都添加了文件。 也检查现有文件的目标成员资格 。 5.在测试文件顶部添加以下代码。 导入项目模块取决于当前的目标。 #if B2B @testable导入SampleB2B #其他 @testable导入SampleB2C #万一 如果要基于目标更改测试用例文件,我们可以使用同一段代码来区分。 6.单击目标和编辑方案,然后添加测试目标,如下所示。 对两个目标都执行此步骤。 为相应的应用目标添加相应的测试目标。 […]