不要引入副作用

最好的情况是，单元测试是一种有用的诊断工具，可帮助您了解应用程序的哪些部分正常工作，哪些无效 。单元测试可帮助您找到回归，由于最近的一些代码更改，这些功能不再起作用。

有了完善的测试套件，您可以精确地确定哪些代码行导致了最近的回归，并且可以对其进行修复。

但是，在最坏的情况下，单元测试带来的混乱比清除起来要多。

您可能不知道哪些测试真正通过了，因此，您可能不再认为值得再运行这些测试了。到那时，测试花费的时间超过了您节省的时间。

发生这种情况的一种常见方式是单元测试产生副作用时。在本文中，您将探索如何发生这种情况以及如何避免这种情况。

副作用是由于运行测试而导致的一些长期后果 。副作用可能影响应用程序本身，测试套件的安装，或者在更极端的情况下，影响应用程序所依赖的服务器环境。

在大多数情况下，副作用只会造成混乱。

由于副作用似乎是随机的，因此您最终可能会创建难以跟踪和重现的错误 。这可能使您陷入一些奇怪的兔子洞，从而调查与应用程序逻辑无关的问题。

让我们研究一下测试可以产生副作用的方式。

单元测试绝不应向文件系统写入任何内容 。如果这样做，它们可能会影响您的应用安装所依赖的存储状态。

当这种情况发生时，这不是世界末日。这不是那种会影响客户电话（基本上是从App Store下载它的人）在生产中使用该应用程序的事情。话虽如此，它可能会导致测试设备上出现一些奇怪的错误。

让我们再来看上一篇文章中的AccessGranter类，不要依赖临时状态。

在该文章中， AccessGranter授予访问应用程序中功能的权限，但前提是用户已登录。该类的第一个版本直接由用户默认值确定。这是从该文章复制的相同代码。

即使您不是api开发人员，Postman还是一个不错的工具。您可以实时了解api团队的进展情况。

我过去常常将所有时间都花在编写会访问api团队正在研究的不同端点的代码上。为了测试这些端点是否正常工作，我将手动运行该应用程序。邮差通过为我完成所有这些工作来节省时间。

在将应用程序连接到服务器之前，我可以快速检查Postman。如果连接处于活动状态，并且请求返回了预期的数据，那么就可以开始了！

具有较小的全局可变状态的副作用是较少的副作用 。当编写更好的代码时，最终会编写出更有效的测试。当您专注于编写更有效的测试时，您会编写更好的代码。这就是单元测试可以使您成为更好的开发人员的方式。

我目前正在写有关iOS单元测试的书。下一篇文章将重点介绍编写快速的单元测试。

同时，您可以查看有关单元测试的其他工作。

不要依赖临时状态

构建iOS单元测试的四个简单规则

我们应该在iOS应用程序中进行哪些单元测试？