Tag: 测试

推送通知用户界面测试: 如果您曾经尝试过手动测试推送通知，则知道它们会很痛苦。首先，您必须将应用程序加载到设备（而不是模拟器）上，通过应用程序流程，确保已关闭/打开应用程序，等等。能够自动执行这种测试不是很好吗？确保您的应用一般设置为推送通知（已启用权利，从开发人员门户生成的推送证书）确保在运行UI测试时将您的应用配置为指向localhost：8080作为其域您应用的info.plist必须在App Transport Security Settings NSAllowsLocalNetworking的App Transport Security Settings NSAllowsLocalNetworking 。没有此设置，您的应用将无法连接到localhost域。模拟服务器这里有几个Swift服务器库。有一些用于生产就绪的Web服务器（例如Perfect，Vapor等框架），但是我们想要的是轻便的东西。我一直在使用Swifter（https://github.com/httpswift/swifter），但是您也可以尝试使用Embassy（https://github.com/envoy/Embassy）。本文中的示例使用Swifter。在我的UI测试目标中，我为模拟服务器添加了以下类：如果将它分解成小块，这很简单。它只有3种方法：1）启动方法2）清理方法，以及3）设置设备令牌端点的方法（在此示例中为/pushEndpoint ）现在，确保将设备令牌发送到模拟服务器设置应用在您的代码中，几乎可以肯定，您有一个将设备令牌发送到远程服务器的功能。您必须做的是确保在运行UI测试时，将此URL请求的主机设置为localhost:8080 。实际上，您应该做的是1）运行UI测试时通过启动选项发送一个标志，或者2）设置一个表明您正在运行要切换到的UI测试的编译器标志。为了简洁起见，我只是在下面的AppDelegate类中对/pushEndpoint的请求进行硬编码localhost:8080 ：我们设置的最后一步是设置一种方法，以从测试运行程序发送推送通知。从测试运行器发送推送通知以下是我用于从UI测试运行程序发送推送的代码（将此代码放入UI测试目标中）：如您在上面看到的，我们要做的第一件事是将为推送通知生成的证书加载到内存中（确保它是沙箱版本！）。您应该将此文件添加到项目中，并确保它是UI测试目标的一部分。之后，剩下要做的就是通过NWPusher库发送您的推送通知。请确保您的通知格式正确。样本推送通知有效负载可能如下所示： {“ aps”：{“ alert”：“测试消息”，“徽章”：1}} 当然，通知会比这复杂得多，但这只是一个示例。运行测试现在终于可以进行测试了！这是一个示例测试：您会在上面的测试中注意到，我们同时利用了之前创建的模拟服务器和triggerPushNotification(withPayload:)函数。如果一切顺利，您的测试应启动该应用程序，然后将其放在后台，然后将推送通知发送到您的设备，然后在UI测试上点击它！而且我们完成了！设置所有这些有点麻烦，但是我认为这是值得的。测试推送通知始终是一件繁琐的事情，我觉得很多开发人员可能做得还不够。有了像我们在这里介绍的那样的测试框架，在修改应用程序中的推送通知逻辑时，您可以更加放心。一旦您的第一个测试启动并开始运行，别忘了测试应用程序的状态，例如被暂停，应用程序完全关闭并对不同的应用程序状态/视图做出反应。但我会将其留给读者作为练习。 […]

我在一个月的TDD中学到了什么: 很长一段时间，我编写程序时都没有编写任何测试线。实际上，我认为编写测试是在浪费时间，直到我开始在一家公司工作时，我的工作是为编码不良的应用创建新功能。每次编写新行时，我都会对该应用程序进行一百次修改，以确保它仍然可以正常工作。这让我意识到测试非常重要，但是即使考虑到这一点，我也没有给出正确的价值。有一天，我的同事提出了一个好主意。让我们以一个新的流程开始这个新项目，让我们使用他说的TDD。但是TDD到底是什么？ TDD是一种鼓励程序员在编写代码之前编写测试的软件过程。测试驱动开发（ TDD ）是一种软件开发过程，它依赖于非常短的开发周期的重复：将需求转换为非常具体的测试用例，然后对该软件进行改进以仅通过新的测试。在那一刻之前，我还没有编写很多测试代码，我知道这个TDD决定会让我遭受痛苦。我将学习测试，新的库以及最重要的内容：如何编写良好的测试代码。我们做了两周的配对编程，所以我可以习惯TDD及其生命周期，即：编写测试代码并运行。它可能会失败，实际上，它应该会失败，现在您可以编写一些代码，但仅需最少的代码即可通过测试。再次运行测试，它应该通过。现在，您可以编写更多测试或重构以前的代码，而无需添加新功能。在这一挑战中，我们决定使用一些库来帮助我们在iOS中编写测试：Quick，Nimble，Nimble + Snapshots和KIF：快 GitHub – Quick / Quick：Swift（和Objective-C）测试框架。快速– Swift（和Objective-C）测试框架。 github.com 帮助您编写测试，为beforeEach和测试本身定义各种测试的上下文。使测试更具可读性很有用。敏捷 GitHub – Quick / Nimble：Swift和Objective-C的Matcher框架 Nimble –一个用于Swift和Objective-C的Matcher框架 github.com 使您的断言也更易读，而不是使用XCTAssertEqual(1+1,2,”expected one plus one equal two”)您可以编写XCTAssertEqual(1+1,2,”expected one plus one equal […]

NS for iOS Devs —可测试性: 在软件开发社区中，测试通常是一个大讨论。我们听到很多人说“如果您不编写测试，您就是一个糟糕的开发人员”或“如果您不知道如何编写测试，那么您做错了所有事情”或“测试是好的，但它们耗时”。但是，我更喜欢说 “如果您不编写测试，那就可以了。只需尝试编写它们，您将最终了解其好处，并且您将学习和思考有关在编码之前所做的体系结构决策的更多信息。我与很多人交谈，在聚会和会议上观看了很多关于各种测试的演讲。一段时间后，我意识到相信通常的想法：“在iOS中，如果您有质量检查人员，则无需编写测试。” 这仍然不时地使我退缩。但是，无论我们是否认为相同或不喜欢编写测试，我们都应该承认其好处。相信我，当我看到及时带来的好处时，我改变了主意并开始编写自动化测试，即使我们有质量检查人员。首先，我们应该考虑没有测试的工作流程，并确定（未来）问题。让我们考虑一下只有一个质量检查人员而没有自动化测试的情况。我们需要在编码之前和编码期间考虑所有情况。仅仅因为人性，我们往往会犯错误。这就是为什么手动测试有问题的原因。会有不想要的行为。我听说您，您有一个出色而勤奋的质量检查人员来测试构建。但是小错误往往会被遗漏，并且可以通过自动测试轻松识别。另一方面，当我们进行自动化测试时，我们倾向于减少错误。我们创建测试用例并修复代码以使测试通过。仅思考和编写这些案例会带来更多好处。它们成为意图的记录。它为项目中的新开发人员提供了足够的信息。因此，在入职过程中，测试会拉平学习曲线。编写更少的代码是大多数开发人员想要的事情之一。通常，这是反对测试的有力论据。但是，如果没有测试，我们最终将花费更多的时间来发现错误并进行修复。没有一种简单的方法可以衡量其影响程度。但是测试编写的项目往往更稳定，更可靠。即使添加了新功能，我们也可以放心。因为如果我们的更改影响了代码的其他部分，则测试失败将通知我们。通过测试可以更好地做出体系结构决策。我们将在以后的文章中讨论架构，但是我只想说，在编写测试时，我们最终会思考很多架构方法。我们开始考虑单一责任和依赖倒置原则，以建立更好的架构。有时我们需要对服务进行模拟或存根（通常在Swift中使用protocol来完成），这有助于理解面向协议的编程。因此，我们在不知不觉中开始研究和学习更多的架构方法和设计模式。最后，测试使代码审查变得容易。如果我们已经进行了很多测试，我们将更有信心更改不会影响代码的其他部分。而且，如果我们对拉（或合并）请求的内容不是很熟悉，那么通过测试，我们可以轻松理解该内容。我喜欢Apple工程师在WWDC17的一次会议上说的话：“测试代码的代码审查，而不是带有测试代码的代码审查。” 好的，我们总结一下，直到这里。手动测试存在错误，可能会导致不良行为自动化测试功能强大，可为代码提供自我文档自动化测试首先看起来很耗时，但从长远来看，它们可以节省更多时间自动化测试可以帮助我们理解架构方法，甚至可以在不注意的情况下教很多东西。自动化的测试使代码审查更加容易。关于iOS应用编写测试的大量在线教程非常出色（下面是链接）。在这里，我们将重点介绍要点和一些测试技巧。 “设计代码以实现可测试性” — John Sundell 正如约翰所说，我们应该问自己一个问题： “是什么使代码易于测试？” 。 […]

XCode单元测试简介: 今天，我想讨论一下XCode中的单元测试。我一直想涵盖这个主题，但是我从来没有真正理解过如何实现它。我已经决定本周学习单元测试的基础知识，并希望在我的下一个应用程序中实现它。在这个博客中，我将为您提供有关实现非常简单的单元测试的教程。我希望这将使我的听众能够在将来的应用中学习和使用它。什么是单元测试？我们都是人类，当我们是人类时，我们往往会犯错误。作为开发人员，我们的代码与我的类推代码相同，我们会犯很多错误。编码中的苦难之一是调试是一个痛苦的过程，尤其是当我们有几百行代码时。至少可以说，调试并非易事。但是，在Xcode中，有一种解决方案可以帮助简化调试过程，也就是单元测试。单元测试允许您通过以测试格式编写其他代码来及早发现错误。如果结果不是我们期望的，我们的应用程序将尽早结束，因为我们的代码未通过测试。想象一下遍历您的代码并尝试查找错误的时间，并意识到该错误只是字符串中的一个简单拼写错误。如果有一些工具可以告诉您那不是很好吗？您很幸运，因为这是单元测试的唯一目的！我不想给您一种印象，通过使用单元测试将导致没有错误的代码，因为事实并非如此！单元测试将在整个过程中为您提供帮助，但不能完全依靠它。让我们开始吧！将单元测试添加到您的项目首次创建项目时，可以在开始时添加单元测试。它位于底部，您只需简单地检查一下并将其包含在您的项目中

App Store中的Probando mi App: 在应用商店中购买，销售和销售应用程序的大企业部分：证书证明书，客户证明书等。等等。 Diawi.com的Gracias a la plataforma Diawi.com提供的内部使用权的使用权，可以在任何时候使用siguiendo los pasos que detallo来继续： 1.- Xcode中的Abrir e proyecto 2.- Ir almenú产品—存档 3.- Luegoapareceránla siguiente pantalla con todas tus compilaciones 4.-临时出口商品的选择和出口选择权 5.-发行新的发行本票 6.-应用软件自动更新和更新文档的出口企业，IPA的语言更新。 7.- Luego deben ingresar a https://www.diawi.com/ y子应用程序和botón机器人发送 8.-平台链接到电子邮件，并向IOS 4高级版的发行人发送电子邮件。结论从公共场所购买新药的理由是，在每年的国际采购交易会上，您将获得一份新的认证。在App Store上的前公共场所，您可以在App Store上找到自己的信息。

教程如何模拟iOS设备上的位置。: 在编写此说明时，我是由iOS大师Andrii Rogulin指导的。谢谢兄弟，这将有助于许多质量检查人员。转到帐户，然后单击“下载工具”。应该有一些重定向到App Store，以下载XCode。等待直到安装了XCode。运行XCode。将您的iOS设备连接到安装了Xcode的计算机。点击“创建一个新的Xcode项目” 选择“单视图应用” 填写“产品名称”，然后单击“下一步” 选择应在其中创建项目的位置。最后，您应该会看到类似于此屏幕在选项卡中，遵循：XCode->首选项->帐户->“ +”->“ Apple ID”->登录到您的帐户。选择团队按“>”，构建过程应开始。在构建结束时，您的iOS设备将被重定向到空白页，您可以从中切换到地图应用程序。要更改地图上显示的iOS设备的当前位置，请执行以下操作 3.选择其中一个位置后，地图将重新加载并显示所选位置。现在您可以进行一些位置相关的测试。附注：要获得更多位置，请点击此处： GPX Generator –轻松生成GPX文件！通过单击Google Maps轻松快速地创建GPX文件！使用生成的代码文件来模拟在您的…… gpxgenerator.com 上的行走

编写敏捷测试: 使用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 {成功 […]

iOS测试技巧＃1-跟踪辅助功能测试失败: 这是一系列小技巧的第一篇，这些技巧可以帮助您提高测试技能。您可以在此处查看其他帖子： iOS测试技巧2 –提高测试的可读性尽管对于代码重用而言很重要，但是断言的帮助器功能可以帮助我们创建更具可读性的测试。在此特定测试用例中使用辅助函数的原因不在这里。如果您在测试函数之外执行断言，但测试失败，则Xcode仅在调用断言方法的位置显示消息，如下所示：发生此现象的原因是函数XCTAssertEqual具有两个默认参数，它们指定文件和执行测试的行。对于您的项目而言，这不是一个大问题，但是如果您使用的是TDD（测试驱动的开发），则很可能会减慢您的开发速度，因为每次发生多个错误时，您都必须进行调试才能找到出了什么事。要对其进行修复，这非常简单，您所要做的就是传递给XCTAssert测试的#file和#line ，如下所示： #file和#line是文字值，它们对于日志记录也很有用。 PS：这也发生在Nimble中，因此您可以使用相同的方法进行修复。所有人，谢谢您的阅读！

#if在动态环境中工作#endif iOS中的App Environment抽象: 2.问题在谈论包括多个后端和应用程序环境的开发设置时，配置将成为救生员，并且是一种设置和构建满足多种需求的应用程序的好方法。当我们开始考虑明确设置应用程序环境的主要原因时，就会出现问题。他们注定会有所不同！这意味着Alpha版本应该与Beta版本有所不同，并且可以肯定的是， Debug和Release之间存在有意义的区别。只要与其他API URL或某些资产有关，就可以了。但是，如果它们提供的实际功能有所不同，则可能适得其反。我确定您至少看过一次此代码： #if调试 // 做点什么＃其他 //做其他事情＃万一还算不错。请记住，在大多数情况下，除非您开始归档或在Release中构建，否则将不检查#else之后的代码。因此，它已经失去了一些编译时安全性。考虑到这一点： #if调试 //调试流程 #elseif AlPHA //被认为是Alpha流程 //但是有一个错字，编译器永远不会突出显示 #elseif测试版 // Beta流＃其他 //应该是Release，对吗？ //除非我们添加了更多配置 //忘了处理它们＃万一从理论上讲，它可以在代码的许多地方发生。每个添加/删除配置都可能需要重新访问这些位置，然后重新检查流程。没有编译器的帮助，代码很快变得难以维护。另一个主题是单元测试-编写有趣的测试。我有🙂 3.环境抽象我在许多不同的项目中都在为这个问题而苦苦挣扎。不管功能切换的好坏，我经常以类似以下内容结束：公共枚举环境：字符串{ 案例调试案例测试版案例发布公共静态var当前：环境{ #if调试返回.debug #elseif测试版返回.beta ＃其他返回.release ＃万一 } […]

Xcode专业提示：再次运行上一个测试: 不想埋葬书架，所以这里是： ⌘G 控制选项命令G 这将再次执行您上一次执行的测试操作-这可能正在运行一个或多个测试套件或案例。如果您要进行迭代更改，并且不想回到测试方法范围或“测试导航器”中，以便每次手动运行特定测试，这将非常方便。也可以从Xcode的“ 产品”菜单中访问它，如下所示：还众所周知，我会进入我的计划并切换我想要的测试套件，但是如果您要更改要频繁运行的测试集，这也很艰巨。但是，如果您想一遍又一遍地运行测试的子集，则上述方法可能会很有用，但这是另一天的工作。