Tag: Xcode 8

使用无构建测试，xctestrun和Fastlane加速iOS CI: PS：这篇文章最初发表在我的个人博客上； XCBlog 在这里在WWDC 2016上，有一个关于“高级测试和持续集成”的精彩演讲，其中提到了XCTest Framework，Xcode-Sever和xcodebuild命令行工具中的许多新功能。我们可以使用这些功能来加快iOS持续集成过程。当前的iOS CI限制在Xcode 8之前，我们必须在CI上运行单元测试和UI测试之前构建，编译和应用程序，这是正在运行的任务的重复。分布式测试非常耗时，而且我们已经在每台机器上构建和编译源代码。实际上，在CI Server上进行构建和编译需要花费大量的构建时间。 Xcode 8和xcodebuild功能 Xcode 8版本在“ xcodebuild”中购买了几个新功能，可以为iOS开发和测试过程增加很多价值。 “ xcodebuild”是用于从命令行构建，运行和执行我们的应用程序的命令行工具。在Xcode服务器中使用。 Xcode 8现在在xcodebuild命令行工具中进行了一些改进。测试构建 xcodebuild现在具有“ build-for-testing”选项，它像往常一样采用工作区方案和目标，但是最重要的是它将创建“ XCTESTRUN”文件。我们只需要执行“测试构建”操作 $ xcodebuild -workspace -scheme -sdk iphonesimulator -destination’platform = iOS Simulator，name = ，OS = 10.2’构建测试这应该构建用于测试的应用程序，并在DerivedData中创建xctestrun文件。无需构建即可测试 xcodebuid还具有另一个名为“ test-without-building”的选项，在这里我们不需要提供工作区，而是指定XCTESTRUN文件，该文件将注入该文件并运行所有测试。此功能对于分布式测试非常有用，因为我们可以在一台计算机上创建XCTESTRUN文件并分发到其他特定于测试的计算机。为了使用它，我们可以在不构建的情况下将此选项指定为ru测试 $ xcodebuild -workspace -scheme -sdk iphonesimulator […]

通过重新运行不稳定的XCUI测试来稳定iOS CI: Apple在WWDC 2015上发布了Xcode UI Testing aka XCUI Test framework，该框架无需使用Appium，Calabash或KIF等任何第三方工具即可直接从Xcode对iOS应用程序进行UI测试。这些工具自称为移动测试框架，但实际上只不过是UIAutomation或Instruments的包装器而已。随着Apple停止支持Instruments技术，iOS 10的发布打破了所有这些开源移动测试自动化框架。剩下的唯一选择是使用Apple的XCTest框架，或者等待那些工具围绕XCUITest构建包装器。 XCTest不是一个新的框架，但是随着Xcode发行版的发展，它发展得相当不错。您可以在此处阅读有关使用XCTest进行iOS应用测试的优缺点的更多信息 XCUITest +持续集成问题 XCUITest框架仍然是新的，有些用户已经抱怨它非常脆弱，尤其是当我们针对持续集成（CI）服务器运行时。 XCUI测试似乎在本地通过，但是这些测试对CI不确定。您可以在StackOverflow上找到许多有关XCUITest的问题。结果是，CI管道变得不可靠且不受信任。团队一直忽略失败的UI测试，每个人对这些UI测试失去信任，这可能成为持续集成失败的原因。损坏的UI测试始终被开发团队忽略。但是，持续交付将不允许将损坏的版本部署到生产中。现在，每个人都注意损坏的UI测试。为了解决问题，团队可能会执行以下操作以确保您的UI测试尽可能具有弹性。遵循“端口和适配器”模式，以覆盖域层的所有业务逻辑，而无需编写任何UI测试。很好的例子就是用Fitnesse编写更快的iOS验收测试或合同测试考虑使用存根后端或模拟Web服务器隔离测试UI，以防止意外数据替换真实Word UI测试。添加了XCUI计算的重试，以找到应用程序上的UI元素或循环运行，直到找到XCUIElement。在每个CI构建或每个测试套件上重置模拟器。向XCUITests添加了静态等待，以使测试可靠。经过所有这些努力，也许很少有测试仍不确定，并且随机失败，人们会感到沮丧。这是UI测试的常规行为，它们脆弱，易碎且难以维护，无论您付出了多少努力来进行修复，也无论您为防御它而付出了多少防御，运行时环境的特殊性都可能使您感到阴谋。现在，由于不稳定的UI测试，您的正式发布已被阻止。现在做什么？解在上述情况下，我们可以尝试一件明智的事情。让我们以失败的XCUITests为例，尝试重新运行它们，但是挂起一个，还有另一个问题。苹果的命令行工具“ xcodebuild”仍然没有从命令行运行单个XCTest的简便方法。可能需要使用Xcode方案进行测试，但是将单个测试传递给“ xcodebuild”有点棘手。新版本的“ xcodebuild”具有“仅测试”选项，但是使用脚本很难实现。幸运的是，有一个名为“ fastlane-plugin-setup_fragile_tests_for_rescan”的fastlane插件可以解决不稳定的XCUI测试问题。全部的感谢归功于插件“ lyndsey-ferguson”的作者。这个插件做以下事情从快速通道扫描生成的Junit报告中进行失败的测试修改指定的XCUITest方案以跳过通过测试和失败测试的方案重新运行“扫描” 3次以查看测试结果。 […]

XCFit：具有Swift 3.1和Xcode 8.3支持的iOS完整堆栈BDD框架: XCFit是Xcode中的全栈iOS BDD框架。 XCFit设置带有框架代码和目录结构的Xcode模板，这有助于我们开始使用BDD，而XCFit Swift Framework提供了许多预定义的BDD样式步骤，从而可以用更少的代码来实现自动化BDD。您可以在Github上阅读XCFit的详细信息。 XCFit 4.0已发布，具有很多功能，简短的发行说明可在GitHub上获得。让我们详细了解XCFit 4的新功能。 XCFit 4.0 XCFit 4.0是主要版本，对Swift框架进行了许多改进。 XCFit 4 .0具有以下主要更改。支持Swift 3.1和Xcode 8.3 添加了对带有集成Cucumberish库的XCFit框架的迦太基支持。为XCFit和Cucumberish添加了许多预定义步骤，以便我们可以将其直接用于我们的项目中。通过将XCFit和Fitnesse模板分别放在不同的命令中来改进Xcode模板。在Youtube上使用Video Demo改进了XCFit的README和Web页面文档。让我们简要地看到新的变化。 Swift 3.1支持苹果刚刚发布了Swift-3.1-dev快照，其中对XCTest框架进行了一些有用的更改。您可以在DZone博客上的XCUITests中阅读有关新添加的类的信息。基本上，XCUITest现在支持异步测试，并能够使用新类控制Siri。苹果已经添加了XCWaiter类，以使XCFit能够更好地等待服务员。 XCFit 4.0是完全基于Swift 3.1构建的，您可以在Cocoapods上看到Swift版本。这个想法是从XCFt 3.1开始完全支持XCFit Swift框架。如果尚未安装Swift 3.1，则可能需要等到Swift 3.1公开发行版才能使用XCFit 4.0的新功能。迦太基支持 XCFit Swift框架现在可以使用Carthage构建，以前它仅与Cocoapods一起使用，但是XCFit 4.0也为Carthage添加了支持。 XCFit依赖于Cucumberish框架，因此我们可以通过拉XCFit来获得这两个框架。只需在项目根目录中的Cartfile中添加以下内容 Github“ Shashikant86 / XCFit” 现在，我们可以使用以下命令下载并构建框架 $ carthage更新—平台iOS […]

使用Xcode 8的FastLane的新Build设置来理解: 我已经构建并负责管理我们iOS移动研究工作的构建管道。我们运行3个不同的版本： Alpha ， Beta ，将每个版本发布到不同的输出： HockeyApp，TestFlight，AppStore 这些释放点中的每一个均由对不同git分支的提交触发。提交开发内容将自动将构建版本发送给Microsoft HockeyApp ，提交给master的提交将自动构建应用程序的两个版本，一个版本自动发送给Apple TestFlight ，同时准备一个稍有不同的构建版本，我们可以手动将其部署到Apple App Store 。为了使事情变得更加有趣，我们的一些项目使用了两个独立的应用程序目标，这使我们共有六种不同的配置。当我将构建服务器和项目过渡到Swift 3和Xcode 8时，构建配置不再能很好地工作。苹果对新版本的Xcode中的代码签名和配置方式进行了一些更改，因此我不得不更新流程。构建通道的核心是快速通道，我们使用它来自动执行该过程的大多数步骤。手动签名我最初的希望是，可以将项目文件设置为“自动签名”，然后当它到达CI服务器时，服务器将重写项目文件中的所有必要字段，以将其转换为手动签名。这是可能的，但是如果您在项目中同时拥有框架和应用程序目标，则将变得相当困难-在某些软件中就是这种情况。因此，我们坚持使用手动签名进行所有操作。借助“手动签名”，我们需要手动管理我们的配置文件-可能会有些麻烦-但至少我们有一个很小的团队，因此目前可以管理。我的目标之一是确保快速通道过程是非破坏性的，这意味着您可以在开发机器上运行它，并且不会破坏您的项目。因此，高级流程是存储现有的构建设置，然后根据需要重新连接项目文件，进行构建，然后将项目还原到以前的状态。捆绑ID和其他唯一字段我们的三个构建路径中的每一个都有一组唯一的字段。例如，每个应用程序的捆绑ID必须是唯一的。另外，每个捆绑包ID都有其自己的唯一供应配置文件供应-连接到与该内部版本关联的Apple开发者帐户。因此，对于发行版，我们使用主要的开发人员帐户，而在beta和alpha测试中，我们使用企业帐户进行签名。现在，配置文件存储在以下构建设置中： PROVISIONING_PROFILE_SPECIFIER，因此使用xcodebuild，grep和awk的组合提取此值＃使用XcodeBuild | Grep | Awk | 提取提取配置文件名称的信息 EXISTING_PROFILE = sh（“ xcodebuild -project＃{PROJECT_FILE_PATH} -scheme＃{SCHEME} -showBuildSettings | grep PROVISIONING_PROFILE_SPECIFIER | sed […]

iOS与Xcode Server持续集成的入门指南: Apple在Xcode Server以及与OSX Server（应用程序）和Xcode Server（服务器应用程序内的Xcode）的持续集成方面拥有非常全面的文档。如果指南中记录了所有内容，您可能想知道这篇文章的意义是什么？但是，Apple指南仍比macOS Server读作OSX Server，但Apple发布了新的macOS Server（5.2），并对Automated Xcode Builds进行了一些改进。无论如何，这都是一个小教程，旨在设置Mac以使其作为具有Xcode Service的macOS服务器运行，以及为具有Xcode 8的macOS服务器设置基本Xcode Bot以执行持续集成。我们将介绍macOS Server的基础知识和设置配置Xcode以使用macOS Server的Xcode服务设置开发Xcode以在macOS服务器上使用Xcode Server 使用Github上的XCFit Swift Package示例创建Xcode机器人运行Bot集成并分析结果要求为了使用macOS Server和Xcode Service设置持续集成，我们需要安装了macOS Server 5.2应用程序的Mac或Mac Mini。从App Store下载服务器上安装了Xcode 8。从App Store下载确保已安装Swift 3 Github上托管的Xcode Project存储库（本教程可选）我们可以从中触发Xcode机器人的另一台开发Mac（本教程为可选） macOS Server 5.2的新功能 Apple已将其旧的OSX Server重命名为macOS Server，它具有许多新功能，例如配置文件管理器，缓存服务器，NFS，Xsan 5等，但让我们关注Xcode Service的新功能。 macOS Server不支持旧的Xcode版本。支持Xcode […]

使用XCUISiriService从XCTest控制Siri: 苹果已经发布了带有新Swift 3.1快照的新Xcode 8.3 beta 2，可以从Apple开发者帐户下载。 Xcode 8.3 beta 2中有很多新功能，如果您拥有Apple开发人员帐户，则可以阅读发行说明。在XCTest框架中添加了一个方便的类，以通过XCUI Test（即XCUISiriService）与Siri进行交互。在这篇文章中，如何启用与Siri的交互。 Xcode 8.3 Beta 2 Xcode 8.3 beta 2中提供了新添加的类XCUISiriService，如果您具有Apple Developer Account，则当前可以下载该类。您可以从开发者帐户的“下载”部分获得它。 Xcode 8.3需要macOS版本10.12及更高版本。您可以下载大约4.52 GB的压缩XIP文件。如果您已经具有以前版本的Xcode，请删除它或保留它，但是必须在Xcode DEVLOPER_DIR之间切换。下载完成后，您可以解压缩文件以安装Xcode 8.3 beta，并等待Xcode和命令行工具的安装。一旦使用所有命令行工具完全安装了Xcode 8.3 beta 2，我们可以将其拖到/ Applications路径中。现在，我们必须通过运行以下命令来切换到新的Xcode版本 $ sudo xcode-select —切换/Applications/Xcode-beta.app/ 这将设置新的DEVELOPER_DIR，我们准备使用Xcode 8.3。确保使用xcrun使用正确的工具链— find swift命令将显示您正在使用的当前工具链。 $ xcrun —快速查找 /图书馆/开发人员/工具链/swift-3.1-DEVELOPMENT-SNAPSHOT-2017–01–22-a.xctoolchain/usr/bin/swift 现在，请确保导出工具链并使用正确的Swift版本，此版本当前为Apple Swift版本3.1-dev。您可以通过运行以下命令轻松地做到这一点。 $ […]

如何制作iMessage贴纸包（Xcode 8）: 如果您的iPhone使用iOS 10，则您可能已经使用了一些很棒的iMessaging新功能，例如链接预览，用手指绘图，发送对照片的反应以及发送贴纸。制作iMessage贴纸包的过程很简单：第1步）制作一堆您想要成为贴纸的图像，第2步）将这些图像放入Xcode的iMessage扩展中，然后第3步）将它们准备好提交给App商店。步骤1：制作一堆您想要成为贴纸的图像我强烈建议您制作自己的图像，而不要从互联网上窃取它们。我不像我希望的那样艺术，所以我的贴纸图像是由我的才华横溢的朋友Lori Hoffman（使用Sketch）创建的。这里是要记住的关键事项：贴纸可接受的格式： .png，.apng，.gif，.jpeg。我将.png用于贴纸包。贴纸可接受的尺寸：小（300px x 300px），中（408px x 408px）和大尺寸（618px x 618px）。我选择使用小贴纸。命名很重要：贴纸名称不能包含任何特殊字符或下划线。（即使用hardshelledtaco.png代替hard_shelled_taco.png 。）步骤2：将图片放入Xcode的iMessage扩展中我制作了一个示例贴纸包：BlogStickerPack，以说明这些步骤。在Xcode（确保您具有Xcode 8.o +）中，打开一个新项目，然后选择“ Sticker Pack Application”。为项目命名后，单击导航区域中蓝色的Stickers.xcstickers文件夹，然后将贴纸图像拖到编辑器区域。现在，运行您的应用程序。模拟器应向iMessage打开。单击文本字段，然后选择iMessage应用程序按钮（蓝色）您甚至可以通过单击您的贴纸图像，然后将它们放入带有Kate Bell的假iMessage中来玩耍。步骤3：准备好将其提交到App Store。我假设，如果您的计算机上装有Xcode，则您对iOS编程比较认真，并且可能已经为Apple Developer帐户支付了99美元的年费。剩下要做的就是制作一个iMessage应用图标，您就可以存档并提交到App Store。对于应用程序图标，我使用MakeAppIcon，因为您可以拖放一张图像，MakeAppIcon会通过电子邮件向您发送所有iOS设备所需的所有尺寸。注意：请确保您的应用程序图标具有背景（否则它将显示为黑色背景，iTunes Connect将拒绝该图像）。这是我在App Store中的涂料标签包的链接。在下面对您的贴纸包发表评论！资源： iMessage应用程序-Apple文档

使用XCWaiter在Swift中进行异步iOS测试: 苹果公司最近为开发人员发布了Swift 3.1开发快照和XCode 8.3。 XCTest框架中添加了几个方便的类，以为iOS和macOS应用程序启用异步测试。在本文中，我们将看到如何使用XCWaiter执行异步测试。 Swift 3.1开发版 Xcode 8.3中提供了新添加的类，如果您具有Apple Developer Account，则当前可以下载该类。您可以从开发者帐户的“下载”部分获得它。 Xcode 8.3需要macOS版本10.12及更高版本。您可以下载大约4.52 GB的压缩XIP文件。如果您已经具有以前版本的Xcode，请删除它或保留它，但是必须在Xcode DEVLOPER_DIR之间切换。下载完成后，您可以解压缩文件以安装Xcode 8.3 beta，并等待Xcode和命令行工具的安装。一旦使用所有命令行工具完全安装了Xcode 8.3，我们就可以将其拖到/ Applications路径中。现在，我们必须通过运行以下命令来切换到新的Xcode版本 $ sudo xcode-select —切换/Applications/Xcode-beta.app/ 这将设置新的DEVELOPER_DIR，我们准备使用Xcode 8.3。确保使用xcrun使用正确的工具链— find swift命令将显示您正在使用的当前工具链。 $ xcrun —快速查找 /Applications/Xcode-beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swift 现在，请确保导出工具链并使用正确的Swift版本，此版本当前为Apple Swift版本3.1-dev。您可以通过运行以下命令轻松地做到这一点。 $ export TOOLCHAINS = swift $ swift —版本 Apple Swift版本3.1-dev（LLVM 40fb70e1b6，Clang 658ce8b57d，Swift d6c7fe1067）目标：x86_64-apple-macosx10.9 […]

在Swift 3或ObjC中的Xcode 8中查找非NSLocalized字符串: 本地化是一个过程，其中我们将所有要显示的字符串移动到一个位置，因此，如果有任何更改，例如，“确定”按钮现在将显示为“确定”，那么我们只需要在一个文件中进行更改。此过程也可以是使应用程序支持多种语言的第一步，以便可以在运行时更改字符串的显示语言。如果用户习惯（说）法语，则用户必须以法语查看所有内容。为此，您应该维护一个字符串文件，其中包含代码库中的所有硬编码字符串。众所周知，与许多开发人员同时工作会导致字符串处理不当，从而进一步导致代码库中本地化和非本地化字符串的混合使用。假设有一个新要求，要求您的应用程序支持多种语言。知道您的应用尚未准备好，因为我们从不关心字符串，这可能是您最大的噩梦。下一步将是什么？您可能希望尽快了解未本地化的字符串，因此可以计划对其进行本地化。在代码库中搜索NSLocalizedString并比较.strings文件中的每个字符串是您唯一的选择吗？好吧，Xcode提供了一种简洁而非常简单的方法来实现这一目标，而只需更改Xcode中的模式设置就可以实现。 #warning：如果您从未对任何字符串进行NSLocalization，则必须首先进行。然后，担心将其保存在本地化（.string）文件中。请注意，此解决方案适用于以下代码： label.text = NSLocalizedString（“某些字符串”，注释：“”）要么 label.text = NSLocalizedString（anyVariableName，评论：“”）不是这个： label.text =“某个字符串” 这是您的架构的样子：您可以按照以下步骤操作：在“运行目标”菜单中单击目标，然后选择“编辑方案”。在右侧，选择选项。选中“显示未本地化的字符串”复选框。单击关闭按钮。单击运行以此模式启动您的应用程序。或者，添加NSShowNonLocalizedStrings启动参数。在“运行目标”菜单中单击目标，然后选择“编辑方案”。在右侧，选择参数在“启动时传递的参数”中添加“ -NSShowNonLocalizedStrings YES ”。单击关闭按钮。单击运行以此模式启动您的应用程序。它是如何工作的：在Xcode中启用此设置，在运行时搜索NSLocalizedString。在字符串文件中查找键的相应条目。如果找不到任何匹配项，它将在UI上以大写形式显示文本，并在控制台上显示错误消息。将显示这种错误：在捆绑包CFBundle的字符串表“ Localizable”中找不到可本地化的字符串“ Key”

构建自己的Xcode 8 Source Editor Extension: 自WWDC 2016以来，我对Xcode 8中发布的新Xcode源代码编辑器扩展感到非常兴奋。你们中的某些人可能知道我曾经写过另一个名为VWInstantRun的Xcode插件，该插件是用一些运行时黑客制作的，又名老式/非官方方式。因此，自然而然地，我希望将此插件移植到全新的Xcode源代码编辑器扩展中。我在这个周末进行了尝试，但未能通过新方法实施InstantRun 。基本上有两个主要限制来实现它： API唯一向我们展示的是字符串缓冲区对象中当前文件的文本。根本无法访问某些与UI相关的组件。不可能像VWInstantRun那样将结果直接输出到调试区域。由于我们假设现在要在扩展内构建事物，因此这当然是一个沙箱。这意味着在运行时无法在CLI中运行build命令。好吧，因此我放弃了。但是我并不是说新的Xcode扩展不值得一看。相比之下，我认为这是一个很好的开始，它允许访问最重要的部分（源代码编辑器），该部分允许创建许多有用的功能，同时消除任何潜在的隐私和安全威胁。让我们建立一个我将在此处尝试提供一个简单的教程，向您展示如何轻松构建自己的Xcode扩展。让我们通过从AppCode借鉴一些想法开始做这件事，例如快速删除/复制所选行。 I.打开Xcode 8。（当前版本为Beta 1）创建一个新的macOS项目并激活相关方案。使用Xcode源代码编辑器扩展创建一个新目标。（由Xcode提出的激活方案）二。配置。在“ Info.plist”文件中打开“ NSExtension”对，“ XCSourceEditorCommandDefinitions”是一个包含几个“ item”的数组，一个“ item”代表自定义命令。在每个“项目”中，有3对。 1.`XCSourceEditorCommandClassName`：用于实现`XCSourceEditorCommand`协议的类的名称。 2.`XCSourceEditorCommandIdentifier`：您选择用来标识唯一命令的标识符 3.`XCSourceEditorCommandName`：命令的名称，将显示在Xcode菜单上。在这里，我们需要添加两个新命令：`delete_lines`和`duplicate_lines`。三，实施。直接进入`SourceEditorCommand`，实现协议方法：公共功能表演（带有调用：XCSourceEditorCommandInvocation，completionHandler：（NSError？）-> Swift.Void）是的，只有一种方法可以实现。根据描述，此方法将：使用调用中的信息执行与命令关联的操作。 Xcode将向代码传递完成处理程序，该处理程序必须调用该完成处理程序才能完成命令的执行，成功时传递nil，失败时传递错误。换句话说，您需要做的是基于给定信息的不同命令来操纵“文本缓冲区”。您将在`invocation`实例中找到所需的全部内容。完成后，调用完成处理程序，传递`nil`或`error`。请直接从Github上的代码源中检查实现的详细信息，该文件已被很好地证明。 IV。我们完了！ 🎉🎉 […]