Tag: 持续集成

快照XCUI测试: 本教程向您展示如何将流行的测试库iOSSnapshotTestCase与XCUITests一起使用。如果您已经知道如何创建项目并安装一些Pod，请随时跳过。设置项目然后在项目的根目录中，运行pod init 。这将在项目的根目录中创建一个Podfile。打开它，然后将pod ‘iOSSnapshotTestCase’添加到Test和UITest目标，如下所示：然后运行pod install 。这会将所需的文件添加到这些目标。接下来，您将要编辑方案以添加必要的环境变量。您可以从iOSSnapshotTestCase存储库中复制粘贴的前两个，除路径的最后一部分外，第三个将相同。 FB_REFERENCE_IMAGE_DIR是该工具将存储参考图像的位置。该工具将在IMAGE_DIFF_DIR中存储差异以检查故障。 FAILED_UI_TEST_DIR是我们的自定义目录，我们将在其中存储XCUITest故障的快照添加一个XCUITest 现在我们需要测试。在Main.storyboard添加带有一些文本的UILabel 。还要添加一个UIButton ，以一种不同的感觉与新的UIViewController结合。例如：在预先生成的SnapshotUITestingUITests ，将生成的代码替换为：很好如果将recordMode切换为false（或删除该行），则下一次运行会将屏幕截图与刚拍摄的截图进行比较。在项目目录中找到存储的图像应该没有问题。解决状态栏问题我将为您省去发现的旅程，只告诉您有问题。以这种方式做事需要整个模拟器的屏幕截图。不用担心我们可以解决这个问题。将新文件添加到UITest目标，并将其UIImageExtensions 。添加以下代码。结论：尚未使用太多，但看起来确实很有希望。让我知道您的想法，如果您最终使用它！您可以在这里找到完成的项目：https://github.com/joesus/SnapshotUITesting

Swift —在Bitbucket上的持续集成: 本文是同时介绍TDD和多个CI概念的指南的一部分。您可以在此处查看介绍性文章。当使用位桶时，我们将使用CircleCI来满足CI的需求，因为它与TravisCI非常相似且易于配置。不幸的是，它仅适用于对我们不起作用的Linux机器（因为我们需要一台macOS机器来构建我们的xcode项目）。但是CircleCI确实提供了为期两周的免费试用，因此您可以签出它，看看它是否值得。让我们开始工作：首先在CircleCI网站上创建一个帐户，然后对您的Bitbucket帐户进行配对（您也可以使用您的BitBucket凭据直接登录Travis，从而无需进行配对过程）。从项目列表中选择所需的项目，以便CircleCI可以为其生成Webhook。现在，CircleCI已挂接到您的项目上，并且当您的代码更改时，它会收到通知（默认情况下，它被设置为在每次推送以及合并时都运行）。现在是时候告诉CircleCI每次对代码进行推送更改时要做什么。为此，我们必须将一个文件添加到项目的根目录，并将其circle.yml 。 CircleCI的配置方案需要更多的指令（与Travis相比），如果被多个文件分割，则更容易做到，这就是我们要做的。首先在项目的根目录下创建一个Scripts文件夹。现在创建以下文件（每个要点底部的文件名）： 7.现在配置CircleCI并准备就绪！提交并推送您的更改（确保包括.yml文件和所有脚本），应该通知CircleCI，它将开始构建您的项目并运行测试！如果一切顺利，您应该得到一个类似于以下的屏幕：有些不对劲？请在下面发表评论，我将尽力帮助！ 9.随着CircleCI的启动和运行，我们现在应该利用它的功能并使我们的CI工作流更加强大。 SwiftLint Swiftlint是一种工具，可以帮助您识别和标记代码的某些部分，这些部分可能不遵循社区或您的团队所遵循的样式规则。因此，它将帮助您坚持简洁的代码惯例，并在整个团队之间保持共同的风格。 Swiftlint可以在本地或CI服务器上运行。让我们先在本地运行它：首先在控制台上运行brew update和brew install swiftlint ，然后在转到项目的根文件夹后，运行swiftlint 。而已！短毛猫会检查您的代码并提出可能发现的任何问题！ 2. SwiftLint的另一个优点是，您可以配置XCode来运行它，以便在每次构建后进行编码时都能得到实时警告！为此，我们必须在Xcode的构建过程中添加一个新的“运行脚本阶段”，并包含以下脚本：尽管非常有用，但SwifLint有时还是会有些干扰。在某些情况下，您可能会收到您确实不想更改的代码的警告（例如上面的AppDelegate甚至是测试类，它们本来就很长）。为避免这种情况，您可以配置.yml文件以指定文件排除项。我希望您更明确一些，并像 // swiftline:disable:next line_length 有了SwiftLint的本地部分，现在该让CircleCI处理它了。首先，将新文件添加到Scripts文件夹中：现在是时候创建一个CodeCov帐户了。使用您的Bitbucket帐户注册，然后从列表中添加您的存储库。您应该看到类似于此屏幕。记下令牌ID，因为稍后我们将需要它。最后，我们现在可以配置CircleCI，以便每次构建项目时也可以检查覆盖范围。我们必须在yml文件中添加两件事： […]

Bitrise现在支持Xcode 9的新exportOptions属性！: 我们已经发布了新的Xcode Archive步骤版本（2.2.0），该版本能够自动检测新的exportOptions属性，因此不再需要两周前提供的解决方法。 👻但是，您仍然必须进行一些设置。问题… 在Xcode 9中，引入了新的必需exportOptions属性： provisioningProfiles ，它描述了应该使用哪个配置文件来签名项目中的哪个目标。即使Xcode 9在测试版中，我们也使用它创建了一个堆栈，以使我们的用户可以使用Xcode 9测试他们的项目。但是，即使您可以在Bitrise上使用Xcode 9，我们的Xcode存档步骤也无法自动检测到配置文件–捆绑包ID映射（这是新的exportOptions属性），因此导致多个构建失败。 …现在已整理👨 该步骤将像以前一样归档您的项目，此部分没有更改。步骤从您的项目中生成.xcarchive文件后，它开始收集exportOptions（如果xcode版本> 6）。从存档导出IPA文件时，您需要定义该步骤应如何导出。有两个选项，让我们看一下相关示例：如果设置了custom_export_options_plist_content输入，则该步骤将使用您提供的exportOptions。故事结束🙂 如果未设置此项，并且export_method设置为auto-detect ，则该步骤将使用嵌入到.xcarchive文件中的配置文件来确定导出方法（如前所述），从现在开始，项目中的每个目标都将是使用此个人资料签名。（第二）故事的结局。如果您为export_method输入指定了任何其他导出方法，则此步骤将列出为签名应用程序而配置的每个已安装的配置文件，然后该步骤过滤此列表以查找与指定的导出方法匹配的配置文件。如果该步骤仅找到1个匹配的配置文件（每个目标），则此配置文件将用于对目标进行签名。（3.故事的结尾。）如果多个概要文件与目标和指定的导出方法匹配，则该步骤无法决定要使用哪个概要文件，因此它将失败。在这种情况下，您应该按照此博客文章中的说明指定custom_export_options_plist_content 。（3.b故事结束）编码愉快！ 🚀

WWDC 2018 NativeDeveloper和DevOps Tools的愿望清单: 最初在XCBlog上发布在这里苹果公司的全球开发者大会（WWDC 2018）将于下周的2018年6月4日拉开帷幕。令人遗憾的是，我们无法访问苹果的路线图，因此看到他们向我们展示的内容总是很令人兴奋。在WWDC中，除了一些开源项目（如Swift，程序包管理器和Swift NIO）外，Apple Github存储库中也提供了这些项目。在这个WWDC中将要进行的演讲/会话也有悬念，在会议开始之前，我们无法看到演讲的标题。当开发人员在Apple平台上工作时，每个人都希望有一些不错的东西，以便使我们的生活变得轻松。几乎每个人的愿望清单上都有苹果工程师希望得到的东西。 MacRumors，Macworld，AppleInsider，PC Magazine等发布了有关主要软件或硬件的愿望清单，您可以在此处找到大量收藏，但是，在这篇文章中，我将有自己的愿望清单，以介绍我在Continuous领域一直想要的改进集成，持续交付，测试自动化，DevOps和Apple Developer工具。这与Swift，XCTest，XCUITest，Xcode Server，BuddyBuild，Swift Package Manager等有关。 CI / CD：Xcode服务器+ BuddyBuild 苹果公司推出了自己的称为Xcode Server的持续集成解决方案，以便开发人员可以从Xcode创建机器人，然后在macOS服务器上运行。在其他CI服务（例如Jenkins，TeamCity，TravisCI，CircleCI）上使用Xcode Server的优缺点。我写了详细的利弊文章，您可以在这里阅读。但是，Xcode服务器存在一些局限性，即不能将其用于更大的团队和测试请求请求。您可以在我之前的博客文章中了解有关Xcode服务器的十大限制的更多信息。好消息是，苹果现在购买了基于云的CI服务BuddyBuild。这可能解决了大多数iOS开发难题。希望苹果不会因为BuddyBuild而杀死Xcode Server。我的愿望清单中的一些内容来自Xcode Server和BuddyBuild一起工作的团队。 1.不要杀死Xcode服务器由于苹果购买了新供应商来处理与CI / CD相关的任务。苹果有可能完全停止对Xcode Server的支持，并要求用户使用BuddyBuild的解决方案。那将是一场噩梦，公司已经投入了金钱和时间来安装Xcode Server，而切换到其他解决方案将浪费时间和金钱。仍然可以结合使用Xcode Server和BuddyBuild的功能。假设Xcode Server用于自托管，而BuddyBuild用于基于云的CI解决方案。 2.对自托管Xcode服务器的请求请求支持这是大多数开发人员或公司拒绝Xcode Server的唯一原因，因为它不支持测试请求请求。 Xcode现在已经与Github紧密集成，这可以在今年的WWDC中期待 3.从Xcode服务器自动上传到TestFlight 去年在WWDC 2017上，Apple通过许多新功能增强了Xcode Server。您可以在此处阅读更多新功能，或在Safari上观看WWDC的Safari，这些功能增加了许多功能，使iOS应用程序的持续交付变得轻松。但是，它错过了将生成的.ipa文件上传到iTunes […]

让我们使用Bitrise自动化Swift构建: 现在我和我的客户我们生活在真正的幸福中。我：我只是想掌握并自动执行，所以会增加内部版本号，进行编译并提交给Testflight。他：我不再将IPA文件拖放到iTunes中。 Testflight通知我，我可以访问开发人员提交的最新版本。在Apple环境中，我们是安全的，但Bitrise是面向开发人员的开源持续集成工具。现在，让我们澄清一下什么是自动化。配料 Xcode 7.3.1 存储在版本控制存储库中的Xcode项目（Swift或Objc）一个存储您的存储库的git服务器（ Bitbucket 和 Github 可以正常工作）开发人员帐户，Apple电子邮件和密码。密码应为字母数字。可以从 iTunes Connect 获取的应用程序ID 一个免费的 Bitrise 帐户应用程序的分发配置文件有效的证书（从钥匙串导出的 .P12文件。向其中添加密码。）如果使用 Cocoapods，则为Podfile 。食谱打开Bitrise，然后使用您喜欢的GIT服务器登录。我更喜欢Bitbucket，因为它们提供5个免费的私人存储库。选择项目的存储库。将ssh密钥添加到您的GIT服务器。我让Bitrise自动执行此操作。此ssh密钥将帮助Bitrise无需任何密码即可克隆存储库。选择分支。该分支应该是分发分支。 Bitrise将立即开始构建项目。这是重要的一步，因此请务必小心，直到看到消息Validation👍🏻！然后将一个Webhook添加到您的GIT服务器。推送到GIT服务器时，Webhook很有用。挂钩将在推送后通知Bitrise开始构建。这也称为触发器。现在打开工作流程并进行管理。将您的配置文件和证书添加到“代码签名和文件”页面。在此输入.P12的密码。 […]

Swift —在Github上的持续集成: 本文是同时介绍TDD和多个CI概念的指南的一部分。您可以在此处查看介绍性文章。如介绍性文章所述，对于本指南，我们将使用TravisCI作为CI平台。它对开源项目是免费的，并且易于使用。让我们开始工作：首先在TravisCI网站上创建一个帐户，然后对GitHub帐户进行配对（您也可以使用GitHub凭据直接登录到Travis，从而无需进行配对过程）。从项目列表中选择所需的项目，以便Travis可以为其生成一个Webhook。 TravisCI现在已挂接到您的项目上，并且在您的代码更改时将得到通知（默认情况下，它设置为在每次推送以及合并时都运行。您可以在github的项目配置页面上对其进行编辑。现在是时候告诉TravisCI每次对代码进行推送更改时要做什么。为此，我们必须将一个文件添加到项目的根目录，并将其命名为“ .travis.yml”。它看起来应该像这样： 7. TravisCI现在已经配置好，可以开始使用了！提交并推送您的更改（确保包括.yml文件），应通知TravisCI，它将开始构建您的项目并运行测试！如果一切顺利，您应该得到一个类似于以下的屏幕：有些不对劲？请在下面发表评论，我将尽力帮助！ 8.您可能还需要检查日志，以了解实际情况。但是， xcodebuild日志可能有些冗长和混乱。为了解决这个问题，我们将使用另一个名为xcpretty小工具，它将获取构建日志并使其更加用户友好。这很容易。我们只需要向.yml配置文件添加几行： 2. SwiftLint的另一个优点是，您可以配置XCode来运行它，以便在每次构建后进行编码时都能得到实时警告！为此，我们必须在Xcode的构建过程中添加一个新的“运行脚本阶段”，并包含以下脚本：尽管非常有用，但SwifLint有时还是会有些干扰。在某些情况下，您可能会收到您确实不想更改的代码的警告（例如上面的AppDelegate甚至是测试类，它们本来就很长）。为避免这种情况，您可以配置.yml文件以指定文件排除项。我希望您更明确一些，并像 // swiftline:disable:next line_length 随着SwiftLint的本地部分得到照顾，现在是时候让TravisCI处理它了。同样，这是通过travis.yml:完成的travis.yml: 现在该创建一个CodeCov帐户了。使用您的GitHub帐户注册并从列表中添加您的存储库。您应该看到类似于此屏幕。记下令牌ID，因为稍后我们将需要它。最后，我们现在可以配置TravisCI，以便每次构建项目时也可以检查覆盖范围。我们必须在yml文件中添加两件事：通过添加标志-enableCodeCoverage YES ，将xcodebuild配置为也启用coverage数据使用after_script选项将覆盖率数据上传到codecov 。您的Yaml应该如下所示：已知的错误 xcodebuild目前发生一个已知的错误，其中没有考虑UI测试，这会影响您的覆盖率。例如，当我想以正确的百分比（在FizzBuzz示例中为100％）更新CodeCov时，例如在合并合并请求之前，我直接在XCode中运行整个测试套件，然后手动上载coverage使用相同的命令向codecov报告： bash […]

Swift-持续集成（CI）: 本文是同时介绍TDD和多个CI概念的指南的一部分。您可以在此处查看介绍性文章。在一个简单的项目（例如，有一个开发人员）下处理和管理代码通常是一件容易的事。但是，当更多的人开始加入时，项目将增长，代码将获得更多功能，管理任务将逐步升级，并且很快就无法实现。 CI的基本原理是，通过不断审核更改，可以防止（或至少减少）此类集成问题。每次提交后（如果您使用的是git），CI都会构建您的代码并运行测试套件，以确保最新的更改不会破坏任何内容！ CI还可以在单独的计算机上（无论是否在本地）运行，以确保代码在与用户的计算机不同的计算机上运行，并且该代码也可以在“干净”的计算机上构建，而无需事先安装任何吊舱等。在为我的Swift项目寻找合适的CI时，我遍历了其中三个： Travis CI：基于云，它提供了一个VM，供您在其中运行代码。适用于XCode项目，您可以运行xcodebuild xctool甚至fastlane命令。简单的界面，但至少到目前为止，它仅与GitHub项目配对。它是免费的开源项目，并且为私有存储库提供了不同的层次。 Circle CI：非常类似于TravisCI，也是基于云的。它的配置有些不同，但没什么特别的。它的免费套餐仅适用于Linux机器，并已付费MacOS平台（提供免费的两周计划） Jenkins CI：与前两个相反，Jenkins是免费的，但您必须将其托管在自己的服务器中。它具有更多的可定制性，但这是以不那么友好的配置为代价的。它的学习曲线更陡峭，但是如果您想对事情进行更多的控制，这可能是我的选择。此外，我还想包括其他工具，这些工具将有助于检查测试覆盖率，代码质量和棉绒： CodeCov：有关测试覆盖率的报告 SwiftLint：分析代码中可能的错误，样式错误和/或可疑的内容；猎犬：类似于SwiftLint，但基于云 Codebeat：通才代码审查，检查代码重复，长函数或语句等让我们从这里开始看看该工具如何与GitHub存储库一起使用。

使用CI / CD服务构建和部署项目: 几个月前，我开始阅读有关CI / CD的文章，但是自上个月与朋友一起开始新的个人项目以来，我再也没有机会在项目中使用过它。但是什么是CI / CD？ CI或持续集成是一种将代码不断集成到您的应用程序中的能力，这意味着您每天/每周或您希望在任何其他时期将新功能和/或修补程序推送到您的仓库中。持续集成（CI）是一种每天将所有开发人员工作副本合并到一条共享主线的实践（维基百科） CD或持续交付是一种能够安全，快速地连续发布软件的新版本的功能。持续交付（CD）是一种软件工程方法，团队可以在短时间内生产软件，以确保可以随时可靠地发布软件（Wikipedia）连续交付是一种以可持续的方式安全快速地将所有类型的变更（包括新功能，配置变更，错误修复和实验）投入生产或交付用户的能力。（continousdelivery.com）为了实现这一目标，我们将使用像git（gitlab，github，bitbucket）这样的版本控制系统，开发人员可以将他们的工作推送到发布分支，他们的CI服务将提取该代码，构建，测试并将我们的应用程序部署到beta用户。我们开始在Google上寻找CI，并发现了一些有趣的服务，例如Travis，Buddybuild，Bitrise，CircleCI和Jenkins。 Travis是免费的开放源代码项目，具有不错的UI，但这是一个私人项目，Travis没有免费的私人回购计划。 Buddybuild是我们的最爱，我们之前使用过它，并且在私人项目上免费使用。不利的一面是为免费用户建立队列的等待时间很长，但是我们可以忍受。我们没有尝试使用Bitrise，CircleCI或Jenkins。对于这个项目，我们决定使用支持私有仓库和Buddybuild的Gitlab。建立分支机构我们有两个分支，将用于为我们的用户生成应用。我们有一个开发人员分支将生成一个beta应用程序，一个主分支将生成一个AppStore应用程序。您可以拥有多少个分支，例如，生产前分支或alpha测试员分支。考虑到这一点，我们需要创建并保护这些分支，以便没人能向其中推送一些代码并最终破坏应用程序。首先，我们需要创建一个新分支，您可以转到您的仓库并选择分支，然后选择新分支。要保护分支，您需要选择设置进入存储库向下滚动到“ 受保护的分支机构” 。选择一个分支，然后选择将能够合并和推送的角色。之后，您的分支将获得受保护的标签。保护分支意味着没有人可以直接通过Pull Request（PR）或Merge Request（MR）将代码直接推送到该分支，这意味着在该项目上，一旦它被开发，我们将在另一个分支中开发新功能/修复。完成后，我们将其推送到Gitlab，他们创建了一个MR，以将该新功能/修复程序合并到开发人员中。构建我们的应用我们选择Buddybuild作为CI服务，因为它：与Gitlab轻松集成。私人回购是免费的，即使我们需要等待很长时间才能进行构建（有时等待时间约为一小时）。在Buddybuild上创建帐户时，您可以选择将其与gitlab，github或bitbucket链接。选择您的git服务，它将自动扫描应用程序。它可以轻松，轻松地设置您的项目，完成后您将看到分支。如果选择更多 -> 应用程序设置，则可以配置分支机构设置以及更多。首先，我们要在不是开发人员或管理员的任何分支上禁用推送，因为我们将仅构建MR / PR，而不构建推送。如果要构建推送，请启用此选项。您可以在Buddybuild上设置很多配置。如果您想了解更多信息，建议您阅读文档。 […]

Flutterのアプリアイコンを环境ごとに分ける: 本记事では，Flutterのアプリアイコンをンを环境ごとに分ける简単な方法について绍介します。アプリアイコン以外全般については，iOSメインですが以下をご覧ください。 Flutterで环境ごとにビルド设定を切り替える— iOS编最低限度，以下くらいには分けると円滑に开発・テスト・リリースができます。 flutter_launcher_iconsを利用 Flutterには，flutter_launcher_iconsというiOS ・ Andoidアプリアイコンを生成するとても便利なツールがあります。 flutter_launcher_icons | 飞镖包 flutter_launcher_icons Dart软件包–该软件包简化了更新Flutter应用的启动器图标的任务… pub.dartlang.org fluttercommunity / flutter_launcher_icons Flutter启动器图标–一个软件包，简化了更新Flutter应用程序的启动器图标的任务。完全… github.com 基本的な使い方は以下です。 1.インストール＃pubspec.yaml dev_dependencies： flutter_launcher_icons：“ ^ 0.7.0” 2.设定を记述＃pubspec.yaml（flutter_launcher_icons-development.yamlでも良い） flutter_icons： image_path：“ assets / images / icon.png” android：true ios：是的もっと细かい指定も可能ですが，READMEを见てください 3.画像ファイルを配置上で指定したimage_pathの场所にアイコンに指定したい画像ファイルを置く。 4.コマンド実行 $ flutter包pub运行flutter_launcher_icons：main 风味ごとにアイコンを変えるそして，本题のFlavorごとにアイコンを変えるやり方です。以下のPull Requestで対応された机能ですが，まだ使い方のサンプルなど整っておらず， masterではなくflavorブランチに隔离されています。通过sestegra读取风味图标文件·提取请求＃69·fluttercommunity / flutter_launcher_icons 预期文件如下：flutter_launcher_icons.yaml或pubspec.yaml，来自默认图标flutter_launcher_icons… github.com […]

如何在iOS应用中利用验收测试: 与后端开发等其他领域相比，移动开发是一门新兴的学科。由于苹果很长一段时间都不关心测试，因此社区开始进行测试的时间很晚。最初，我们有单元测试工具，我研究过Swift中的单元测试和Objective-C中的单元测试。进行单元测试很棒，但是顾名思义，它只是测试单元。因此，我们继续寻找并找到了黄金大师测试。另一个提高我们质量的好工具。最后，我们可以确保我们的用户界面是正确的。但是拥有正确的UI是否意味着我们的应用正在执行应做的事情？那么，我们应该如何测试整个应用程序呢？我们已经进行了UI测试。太好了，我们可以确保我们的应用正确无误。为我们的应用程序编写了一系列测试，大概两年了（包括2个iOS和Xcode更新），我们意识到： UI测试缓慢，不稳定且难以维护这么结束了吗？我们必须忍受这些缓慢的测试，还是可以以某种方式改进它们？让我们看一下UI测试为什么会这样。 UI测试速度 Apple在UI测试中的解决方案是运行两个单独的进程。每当测试请求XCUIElement时，TestProcess都会从原始应用程序获取整个应用程序状态。然后它将执行整个状态的搜索查询，并列出所有匹配的元素（通常只有一个，但是在找到第一个元素之后仍会继续）。知道了所有这些步骤之后，我们就可以知道在此架构内的时间：将AppState创建为XCTest的树将AppState传输到TestProcess 查询整个AppState 使用Xcode 9，情况发生了一些变化。它不是在TestProcess中执行查询，而是传输查询，而应用正在执行它。此外，您可以使用“ .first”在树中找到第一个元素，然后立即返回。这使UI测试更快，但是并没有我们希望的那样快。而不是运行60分钟，他们可能需要52分钟。缓慢测试的另一个原因是动画。您无法检查它们是否为真，因此可以选择停用它们： UIView.setAnimationsEnabled(_ enabled: Bool) 我不喜欢这种方法，因为您需要在生产代码中实现它，并且可能只有使用动画时才会出现错误。最后，您将不得不考虑收益并决定是否要冒险。稳定性研究了速度问题后，为什么UI测试会出现问题？由于测试是在自己的流程中运行的，因此我们知道它们必须同步。但是为此，过程本身需要相互查找。只要不是这种情况，测试就不会在您的应用程序内无故失败。这不仅可以在测试的第一次开始时发生，而且可以在中间发生。每当您的应用重启时，都需要找到该应用进程。此外，有时由于意外的应用程序行为，导致测试运行不同步。这可能只是系统对话框弹出而您不处理它，或者网络连接中出现小错误，但最终结果可能是毁灭性的。知道我们的测试不稳定，就意味着每当运行失败时，就需要进行无休止的调试。这可能是测试，但通常只是某种时机，（在测试内）意外行为，或者只是Xcode起作用。但这仍然很耗时。可维护性在“屏幕对象”中，我们深入探讨了如何维护测试。即使我们尝试坚持使用它们，我仍然经常看到与应用程序本身无关的代码。 .tap（）之类的函数调用可防止测试松动。用户界面的微小变化可能会杀死该屏幕上的所有测试。 […]