swift - 如何在Swift中编写可测试的代码

Question

因此，当我开始对postNotification和addObserver的简单两行进行单元测试时，我的这个问题就开始了。从这个类似的问题here中，您可以看到要使其可测试，您需要在编写代码的常用方式之外添加约20行和部分。

面对这个问题实际上是我第一次了解单元测试和TDD之间的区别。如果您的代码是可测试的，即遵循TDD思维方式，则单元测试很容易。接下来，我被带到了如何编写可测试的代码，而我并没有找到太多的指导方针，每个教程都只是跳入编写单元测试。苹果自己的documentation与此无关。

我最初的想法是我需要针对“函数式编程”并以pure function方式编写函数。但是，这又是非常耗时的，并且可能需要在现有代码中甚至在新项目中进行大量重构，甚至还需要为新项目添加许多行，而且我甚至不确定that is the correct approach。是否有任何建议的指南或标准，可以轻松地编写可测试代码？

我已经知道的我自己:
我知道您不应该编写任何代码，除非有测试失败的代码，所以基本上我必须先编写测试，并且一旦出现错误，甚至是编译器错误，都必须重新切换在需要测试的实际类上编写所有必要的内容，并使我的测试代码不出现任何错误，然后切换回测试类并继续编写我的测试并修复编译错误，直到完成。然后运行测试，看看它是否检查了我要检查的内容。

对于所有测试，我应该确保测试会通过并在我期望失败的地方准确通过，即在期望失败的地方通过测试。

我不知道如何以更简单的方式简化流程。

我不是在问如何为NSNotificationCenter编写可测试的代码，而是在问有关编写可测试的代码的一般准则。

Answer 1

这是一个相当大的问题，也是开发人员的观点朝着截然不同的方向发展的问题。同样重要的是要注意，使代码可测试并不是很多特定于Swift的问题:在很多方面，使您能够例行且方便地编写可测试代码的事实实际上取决于您遵循一些基本的，普遍适用的原则。测试驱动的设计实践通常会通过验证您遵循的实践来间接帮助您，这些实践使通过测试执行代码的合理性得以实现，同时还为您带来了其他程序员的生产力和可靠性优势。因此，不幸的是，编写可测试的代码不是学习使用Xcode的一些机械技巧的问题，而并不是证明您已经设计并计划了编写的程序和库并遵循某些良好实践的问题。

我将尽力在下面链接到一些Swift专用资源，以展示我倾向于遵循的更通用的原则以使我的代码可测试。

使您的代码可测试通常是遵循面向对象的合理设计原则的副作用。

您可能会发现有关the SOLID principles的阅读很有用。

还要查看SOLID五个原则中每一个的this Swift based demonstration。

Google's Code Reviewer's Guide(PDF)对于了解典型的OOD问题以及如何避免也是一个很好的资源(同样，与此OOD相关的文档的副标题恰好是“可编写测试代码”)。

遵循良好的面向对象设计本身通常是好的高层体系结构决策的副作用。基本上，尽早并经常考虑计划在程序的对象图中引入的类型。它们之间的作用和依赖性是什么？从不同上下文(例如，UI代码与单元测试)执行代码时，对象图中的任何依赖关系是否难以满足或无法正确构造？

关于建筑设计模式的计算机科学文献很多。 The Gang of Four仍然是一本有值(value)的书，可以阅读有关此主题的内容(尽管并非所有内容都适用于您的典型Swift程序)。

看一下Swift design patterns演示，以概述在Swift中可以实现多少个常见设计模式。

特别是如果您的代码是针对移动应用程序的，则应该read about VIPER，这是一种面向移动应用程序的架构模式，它是来自iOS应用程序的典型架构需求。

要将设计模式链接到上面列出的SOLID原则，“单一责任”原则也许是许多大型Cocoa程序中最明显违反的一项原则，这是不良的体系结构实践的结果，这也导致很难测试代码。实际上，人们经常 Jest 将 cocoa 中实践中使用的MVC称为"Massive View Controller"。

以上提出的观点绝非Swift特有的，我希望不会有争议性的主张。但是，Swift确实还提供了语言功能，这些功能还可以帮助您编写可靠的无错误代码，部分原因是这些语言功能可以帮助您使代码测试友好。以下是一些Swift的良好做法:

Use value types when you can:Swift非常适合编写将自动引用计数的引用(指针)最小化的程序。这不仅带来了性能上的好处，而且还增加了编写可靠代码的机会，从而最大程度地减少了在测试中难以捕获的意外依赖关系和数据竞争。

Keep things immutable when you can:Swift中的语法约定和类型系统可帮助您避免发生可变状态，这尤其会对代码的可测试性产生负面影响(配置对象图进行测试可能会变得困难，因为这将获得实际可用的测试覆盖率代码(如果程序中的可能状态空间很大)。

苹果公司还提供了有关the architectural matter of value types and immutability的一些指南，该指南还涉及代码的可测试性。

在可能的情况下使用协议(protocol):理解原因，继续阅读the Liskov substitution principle :-)更严重的是，比起具体类型，更喜欢使用协议(protocol)可以帮助您编写可测试的代码，例如，通过允许您在测试设置中使用假冒的特定测试类型来实现依赖关系。或模拟一些与测试无关的资源。

使用功能编程技术(在有意义时):通常将功能与功能组合在一起，可以帮助您编写易读，灵活的代码，避免发生可变状态。我推荐Functional Swift by Chris Eidhof and others作为在Swift中应用功能模式的良好指南。

再说一遍，这个问题很大，我的意思只是说说要说的很简单，以指出没有可测试性的万灵丹–这是您在设计代码时遵循许多最佳实践的结果。