服务器端Swift — MVC（单元测试）
在我的上一篇文章中，我描述了如何根据MVC模式（与ASP.NET MVC类似的构建）构建服务器端Swift应用程序。 但是，这里缺少一件事： 单元测试 。 没有单元测试，我无法想象认真的应用程序。 在本文中，我将介绍如何在Swift（和Perfect框架）中向我们的MVC应用程序添加带有单元测试的项目。
首先，我们必须重新构建一些应用程序。 我们无法为可执行应用程序创建单元测试。 这就是为什么我们必须将应用程序分为两部分：
- 可执行文件 -这部分应包含尽可能少的文件，
- 库 -该部分应包含整个业务逻辑-这部分我们可以连接到我们的测试库。
划分应用程序后，我们应该有一个如下所示的项目：
来源/
TaskerServerApp /
主Swift
TaskerServerLib /
控制器/ *
楷模/*
仓库/ *
扩展名/ *
测验
TaskerServerLibTests /
因此，我们有TaskerServerApp可执行文件，其中仅包含一个文件（引导我们的服务器的主文件）。 我们有TaskerServerLib ，其中包含业务逻辑的主要部分（控制器，模型，存储库等）。 在单独的项目TaskerServerLibTests我们将进行单元测试。
要创建该项目，我们必须为Swift Package Manager准备Package.swift文件。 它看起来应该像这样：
现在我们必须考虑如何创建伪造的实现。 在像C＃/ Java这样的语言中，我们可以使用功能强大的模拟框架，例如：Moq，Rhino.Mocks，mockito。 不幸的是，在Swift中，这项任务并不是那么容易。 Swift的反射/自省能力不足，无法在运行时生成动态类（在许多被称为代理的模拟框架中）。 我发现了一些模拟库，例如：
SwiftyMocky-我们可以标记协议（ //sourcery:AutoMockable ），然后适当的伪造实现将由Sourcery工具生成，
Cuckoo —特殊的生成器（ CuckooGenerator ）和框架，generator负责基于配置文件生成伪造的实现，
Mimus —框架，提供我们可以在人工生成的假文件中使用的方法（目前仅支持模拟），
Dobby-与Mimus相似，但是在我们的虚假实现中，我们可以使用模拟和存根。
我不想使用任何生成器，因为在大型分布式团队中（尤其是当团队成员可以使用不同的操作系统时），它将产生很多问题。 我决定选择Dobby框架，该框架非常简单并提供清晰一致的语法。 当然，我们仍然必须手动创建伪造的实现文件，有时这会很痛苦。
下面是如何创建假存储库实现的示例：
我们有三个目标（可执行文件，具有业务逻辑的库和具有单元测试的库）。 我们在服务器引导程序（ main.swift文件），控制器（路由）和模型之间有明确的区分。 而且重要的是我们有单元测试 ！
在下一篇文章中，我将重点关注下一个重要主题： 配置文件 。 可以存储对我们服务器重要的信息的文件，例如：连接字符串，其他服务地址，日志等。
您可以在我的GitHub项目中找到所有源代码（分支unit-tests ）：