iOS Swift - 运行特定的 VIPER 模块而无需浏览所有屏幕

Question

我想在我的项目中使用特定的 Viper 模块。从技术上讲，现在当我需要打开一个特定的 UIViewController 时，我需要通过一些屏幕输入一些数据等，然后在 20 秒内我就在那个特定的屏幕中。

因此，当我只需要测试一些小事情（如 UI 调整、更改一些字符串以使其适合屏幕等）时，需要花费大量时间导航。

相反，我想在运行项目时运行特定屏幕。

在这种情况下，模拟和注入肯定会有很大帮助，因为我需要用一些初始数据来满足我的 Viper 模块。这只是一个技术细节。

我想知道如何组织我的项目以运行特定模块而不是运行整个项目。

硬编码解决方案，例如通过添加覆盖初始点的额外代码来使用应用委托，这只是一个临时解决方案，您需要在完成后清理应用委托。

我可能错了，但我认为应该有一个特定的目标解决方案可以运行不同的模块，无论它是像 HomeViewController 这样的初始点还是带有模拟注入的特定模块。

Answer 1

为了设定这个答案的基本规则，https://TheSwiftDev.com/the-ultimate-viper-architecture-tutorial 描述了 VIPER 是什么的最规范的原始学派变体，以及它作为自律的目的是什么。 （在过去的几年中出现了其他派生观点，但我将在这个答案中使用这种原始的思想流派，因为所有的木头背后 1 箭头清晰和教学原因。）

• 我将礼貌地拒绝 OP 对 VIPER 的“模块”使用。相反，VIPER 是 5 个区域 {视图用于 UI，交互器用于数据存储/网络/传感器，应用程序域“业务”规则的演示者，以应用程序域为中心的实体 [不是以数据存储为中心，不是以网络为中心，而不是以传感器为中心]数据结构，用于导航的路由器}隔离和某种程度的分离。有人可能会说 zone 和 module 是 100% 同义词/全等的，但我将把它们分开作为单独的解释。 5 V I P E R 区域都是关于彼此离婚/隔离以消除 Massive View Controller 反模式/代码气味软件架构https://khanlou.com/2015/12/massive-view-controller 和https://www.hackingwithswift.com/articles/159/how-to-refactor-massive-view-controllers，这是旧时代 Big Ball 的移动应用程序变体泥浆反模式/代码气味软件架构http://www.laputan.org/mud/mud.html#BigBallOfMud

• 另一方面，模块可以解释为比 5 V I P E R 区域更细粒度。让我们在这里做。 VIPER 的每个区域都可以进一步细分为该区域的类似主题部分的模块，例如包含场景/屏幕/包含视图的所有（子）视图或任何其他应用程序的心脏想要的子类别。模块划分可以与 5 V I P E R 区域正交（或忽略）。实际上，设计人员可能会选择在 2 个或更多 VIP E R 区域中的每一个内使用相同的模块划分。或者同样有效的是，设计师可能会选择在视图区域内与在交互者区域内与在演示者区域内具有完全不同的模块划分，因为他们每个人都碰巧专注于分解隔离/离婚/隔离区域的不同方式仅在该区域内才有意义的方式（并且在其他一些 4 个区域中几乎没有意义）。因此，从这个答案的角度来看，我们将不再提及模块，因为它是每个区域内的本地口味，与 OP 的预期目标无关。

• 正确完成的 VIPER 架构中的每个区域都已被隔离，因此特定于 UI 的主题永远不会逃出视图区域（例如，进入最诱人的演示者区域或路由器区域或 [通常是较小的诱惑，除非大量模仿非 VIPER 示例传感器或网络数据采集]交互区）。由于这种隔离，OP 的目标实际上是拥有一个完全不同的路由器/导航区域，通过其各种场景/屏幕/模态对话框驱动应用程序进入测试模式，这种方式对人类来说甚至可能是不自然的- 应用程序及其路由器导航的用户变体。但是，VIPER 软件架构的长期目标整个是换掉整个区域，因为它具有无可挑剔的隔离/离婚——实际上就像通过离婚将一个配偶换成另一个。这就是 OP 正在有效寻求的：将（主要）路由器区域的人类用户变体替换为测试模拟路由器区域，该路由器区域通过类似脚本的行进命令驱动应用程序，从而以如下方式行进 UI通过人类用户 UI 操作来完成令人讨厌的太多努力。模拟/脚本替代路由器区域可以随意“短路”，因为它可以跳过 UI 的某些部分，只要任何本应自然建立的累积状态作为模拟脚本的一部分被回填。如果路由器在短路导航到 UI 的一部分/屏幕/场景时无法访问完成累积状态回填所需的任何方法/API，那么 a) 关注点的分离被侵蚀，因此模拟/脚本化替代路由器区域比其常规人类用户变体隔离更少，或者 b) 其他一些区域需要某种程度的模拟来回填该罐装累积状态以与模拟/脚本化替代路由器区域合作。

• 但是，要使用机械/测试/模拟路由器区域来实现这种对普通路由器区域的换出，以实现类似脚本的 UI 导航，交互器区域也必须被模拟出来，以驱动罐装数据存储内容、罐装网络内容，以及以类似脚本的方式以及以与测试/模拟路由器变体合作的方式来制作传感器内容/采集。确实，在应用程序的通常应用程序域人类用户变体中如此寻求的隔离/离婚是奖励，但远没有隔离，也许根本没有离婚可能是模拟/测试路由器区域和之间值得称赞的目标模拟/测试交互器区域，它们可能非常紧密地结合在一起，以作为一种思维方式一起完成脚本/罐头模拟功能。因此，对于应用程序的人类用户主要变体来说，什么是好的离婚/隔离关注点分离可能是应用程序的 OP 的模拟/测试变体中的灾难性分离，因为实际上两者之间没有这样的关注点分离脚本化/模拟路由器区域替换为脚本/模拟交互器区域。

• 希望演示者的业务规则准后端式处理不需要被模拟，因为希望这些应用程序域业务规则的执行不会妨碍机械驱动UI 1) 通过替代路由器区域进行模拟/脚本导航和 2) 来自模拟/脚本传感器、模拟/脚本数据存储和/或模拟/脚本网络的模拟/脚本数据。如果某些应用程序域需要将视图区域中的纯 UI 测试与演示者区域中的纯业务规则/准后端测试分开，则模拟 UI 视图区域将测试/驱动真正的演示者区域和模拟业务-规则演示者区域（可能具有替代现实/模糊业务规则）将更严格地测试/执行真实视图区域。

• 相反，如果应用程序的开发人员未能 100% 隔离（例如，视图区域内的 UI 主题），那么更换受 UI 污染的非视图区域的能力可能会被严重侵蚀到无法交换非视图区域的程度使用该非视图区域的测试/模拟替代品。为了在 VIP E R 区域之间实现 100% 严格的隔离区间隔离，需要公开的自律，以确保 100% 的区间消息传递/方法调用以纯应用程序域概念表达，不受 Apple-think 或其构造、Android-思考或它的概念，等等。每个 V I P R 区域（除了 E 中相当简单的实体）通常需要在每个区域的外围有一个外观层，以将区域内概念与应用程序域间概念进行交互，例如隔离所有 Apple 认为的 UI 构造或 Android 认为的 UI 概念在视图区域内，以便仅在区域间交换更高层次的应用程序域概念——同样地，在交互器区域的外围有一个立面，用于互通以数据存储为中心或以传感器为中心或以网络为中心的构造隔离区，远离更高层-order-thought app-domain 概念interzone。

• 同样，路由器导航区域的另一个测试/模拟替代品可以将人类用户快速转发到 UI 的特定部分/屏幕/场景，以进行半自动化测试的手动交互，而不是全自动脚本导航。快进可以是到相对未填充的屏幕/场景。或者，快速转发可以是，例如，一个编辑屏幕，其中包含已加载的预制精细实体进行编辑，如果预制精细实体在执行某些用例或只是正确组合情况时特别有用重现错误。