iOS应用中的单元测试与模拟

您刚刚开始一个项目。 按照典型的方式，不同的人处于不同的阶段。 在早期阶段，只有您和设计师。 但是随着项目的开展，他们开始引入Web api开发人员来构建Web服务，您最终将将其连接到应用程序的用户界面。

这产生了一个难题，许多开发人员都在以不同程度的成功来解决这个难题。 如何在不依赖Web服务的情况下构建应用程序及其用户界面？

这样的事情有可能甚至被推荐吗？ 那是单元测试的目的吗？

人们兜售一个叫做“测试驱动开发”的东西会说“是”。 他们认为您要先编写测试，然后再编写通过测试的生产代码。

在童话般的土地上，人们显然有时间这样做，这一切都很好，但是给我们大多数人大约一两个月的时间，为我们的客户建造某种可释放的东西。

编写单元测试作为在所有人入职之前验证所有功能（包括用户界面外观）的一种方式，是不现实的。

嘲弄是工作的正确工具。 模拟是伪造的实体，模型或服务。 处于早期阶段的应用应具有各种模拟。 您可以拥有假用户，假事件，假场所，假网络服务。 一切都应该是假的。

但是，尽管您的模型和服务是伪造的，但是您的视图，视图控制器和其他应用程序逻辑确实可以是非常真实的。 那就是嘲笑某件事的全部重点。

就像压出面包模一样。 您可以使用一块木头来使形状正确，但是您完全打算在烘烤时在其中放入真实的面团。

您可以使用伪造的模型和服务启动应用程序项目，在不同的ViewController之间传递它们，并扩展应用程序的大多数用户交互。 稍后，一旦将Web开发人员加入团队，您就可以慢慢开始用真实的交易替换假模型和服务。

如果您一直在使用诸如Model View Controller和Model View View-Model之类的设计模式，则将模拟与真实实体交换应该是一件简单的任务。 在大多数情况下，只需更改类名或添加带有JSON的初始化程序即可。

一个好的模拟尽可能地接近真实交易。 因此，如果您的应用程序具有一个具有名字，姓氏，电子邮件地址和个人资料图片的用户实体，则模拟用户应具有所有相同的属性。

实际上，您的模拟模型可能与最终模型完全相同。 这就是您所追求的。 您希望一旦有可用数据就可以用真实数据填充。

我已经看到在不同的iOS团队中以多种方式完成了模拟。

不太先进的团队从来没有完全内部化模型-视图-控制器，MVVM或关注点分离的概念。 他们创建了松散组织的不同数据阵列，完全希望稍后再回来并重做所有工作。

结果，他们的模拟看起来像这样

您可以看到对应用程序架构的思考很少。 他们只是将一些数据放入数组中，并假设他们在Web服务可用之前无法开始构建应用程序。

但这不是真的！ 即使您的数据不是真实的，您也可以创建结构。

更高级的团队将把他们的模拟视为他们计划长期使用的真实模型。 它们将在ViewController之间传递它们，就像传递真实交易一样。

结果，一个伟大的团队的模拟将看起来像这样

是否需要该协议还有待商bat。 我将其放在此处以强调“ 人”是适用于假人和真实人的抽象概念。 要将伪造与真实交换，您仅需要创建一个符合Person协议的新实体。

区别是显而易见的。 经验更丰富的团队创建了一个久经考验的真实架构。 经验不足的团队创建了一系列无关的东西。

高级团队可以在应用程序周围传递模拟，就像它们是真实的一样。 他们可以完成90％的工作，而无需将任何事情挂接到实际的Web服务上。

同时，在Web服务可用之前，初级团队将难以完成构建功能的任务。 他们的代码没有整齐地组织成可以传递给其他视图控制器的实体（即模型）。 即使他们的应用在控制器之间传递数据，也将以草率而随意的方式完成。

模型中的数据是否为假都无关紧要。 重要的是这些数据的组织。

cks子虽然是假的，但仍然是一种管道。 在整个应用程序中使用它们仍然构成体系结构。 一旦实际数据可用，您只需要对代码进行一些微小的更改即可让实际数据流过。

那么，为什么我要谈论在您的应用程序中模拟用户界面的各种对错方法？

如今，对于自动单元测试的正确使用似乎有些混乱。 有些人似乎认为单元测试应该在应用程序开发的早期阶段替代模拟。

事实是，人们原本可以归因于单元测试的许多好处实际上来自于单元测试所促进的其他最佳实践。

我说的是诸如关注点分离，使用MVC或MVVM之类的通用设计模式，以及通常试图避免代码重复的事情。

尽管在早期进行一些单元测试永远都不错，但是干净的模块化组织是在Web服务可用之前，高级团队可以90％完成应用程序的真正原因。

与此类似，初级团队不会挣扎，因为他们不知道如何编写单元测试。 他们之所以努力，是因为他们没有将关注点分离的概念进行分析。

鉴于大约80％的iOS应用程序开发都涉及用户界面，因此单元测试可以代替Mocks的想法在表面上是错误的。 我们应该尽早进行更多的视觉测试，而不是更少。

模拟程序比单元测试所需的设置少得多，并且在许多情况下，它们与最终模型非常接近，最终模型将在实际数据和服务可用后使用。

如果您只是想开始进行特定的导航，或者需要查看屏幕的布局方式，请使用模拟代替单元测试。 这样您可以更快地工作，并且可以直观地确认一切看起来不错👍。

---

信不信由你，我实际上正在为针对iOS应用程序的单元测试的Udemy课程做Kickstarter。

Swift 4和iOS 11的单元测试

没有蔬菜 只是实用技巧。

我想通过使用实际示例来更实际地介绍单元测试，编写单元测试实际上可以节省您的时间。

我想教人们如何有效地测试难以手动测试的逻辑。 我说的是触发条件罕见或耗时的条件。

我想消除这种“吃蔬菜”的家长式作风，并向您展示一些使您提高工作效率的技巧。

如果您喜欢在这里阅读的内容，请表示支持并以低至1美元的价格支持该项目

即使您负担不起，也可以继续在社交媒体上分享链接。 这是一个巨大的帮助。 谢谢你的支持！