unit-testing - 主要与外部资源交互的单元测试程序

Question

我想开始在我的应用程序中进行更多的单元测试，但在我看来，我所做的大部分事情都不适合进行单元测试。我知道单元测试应该如何在教科书示例中工作，但在现实世界的应用程序中它们似乎没有多大用处。

我编写的一些应用程序具有非常简单的逻辑和与我无法控制的事物的复杂交互。例如，我想编写一个守护程序，它对某些应用程序发送的信号使用react，并更改操作系统中的一些用户设置。我可以看到三个困难:

首先，我必须能够与应用程序交谈并收到它们的事件通知；

然后我需要在收到信号时与操作系统交互，以更改适当的用户设置；

最后，所有这些都应该作为守护进程工作。

所有这些事情都可能很微妙:我将不得不浏览可能很复杂的 API，并且我可能会引入错误，例如通过误解某些参数。单元测试能为我做什么？我可以模拟外部应用程序和操作系统，并检查给定来自应用程序的信号，我将在操作系统上调用适当的 API 方法。这是......好吧，应用程序的微不足道的部分。

实际上，我所做的大部分事情都涉及与数据库、文件系统或其他应用程序的交互，而这些是最微妙的部分。

另一个例子看 my build tool PHPmake .我想重构它，因为它写得不是很好，但我害怕这样做，因为我没有测试。所以我想补充一些。关键是重构可能会破坏的东西可能不会被单元测试捕获:

要做的一件事是决定要构建哪些内容以及哪些内容已经是最新的，这取决于上次修改文件的时间。当触发一些构建命令时，这个时间实际上是由外部进程改变的。

我想确保正确显示外部进程的输出。有时 buikd 命令需要一些输入，这也应该得到正确管理。但我不知道先验哪些进程会运行——它可能是任何东西。

模式匹配涉及一些逻辑，这似乎是可测试的部分。但是进行模式匹配的函数使用(除了它们自己的逻辑之外)PHP函数glob ，它适用于文件系统。如果我只是模拟一棵树来代替实际的文件系统，glob不管用。

我可以继续举更多例子，但重点如下。除非我有一些精巧的算法，否则我所做的大部分工作都涉及与外部资源的交互，这不适合单元测试。不仅如此，通常这种交互实际上是不平凡的部分。仍然有很多人将单元测试视为一种基本工具。我错过了什么？我怎样才能学会成为一个更好的测试员？

Answer 1

我推荐这个google tech-talk on unit testing .

视频归结为

编写您的代码，使其尽可能少地了解如何使用它。您的代码所做的假设越少，测试就越容易。避免构造函数中的复杂逻辑、使用单例、静态类成员等。

隔离 您的代码来自外部世界(通讯、数据库、实时)，并确保您的代码只与您的隔离层对话。否则，就“假环境”设置而言，编写测试将是一场噩梦。

单元测试应该测试故事 ;这才是我们真正理解和关心的；给定一个具有方法 foo() 的类, testFoo()是无信息的。他们实际上推荐了像 itShouldCloseConnectionEvenWhenExceptionThrown() 这样的测试名称。 .理想情况下，您的故事应该涵盖足够的功能，以便您可以从故事中重建规范。

注意:视频和这篇文章以 Java 为例；但是，要点适用于任何语言。