为什么总是对尽可能小的代码单元进行单元测试是最佳实践？我发现那些测试永远不会在重构中存活下来。

Question

几年来，我一直是测试驱动开发的实践者，总的来说，我对它很满意。我还不明白的一点是，你应该始终对“最小的单元”进行单元测试。

单元测试的部分想法似乎是为了让你可以自信地重构，相信你不会破坏任何东西。然而，我发现测试非常小的代码片段的测试几乎永远不会在这些重构中幸存下来，代码总是发生足够大的变化，以至于小的单元测试被丢弃，新的测试被编写。由于较高级别的接口不会经常更改，因此覆盖较大功能的测试似乎在这里提供了最大的价值。

对于琐碎的重构，比如移动方法，这些都是通过IDE完成的，因为我使用的是静态类型的语言，所以我从来没有遇到过IDE不能完美地进行重构的情况。

还有其他人有类似或相反的经历吗？

Answer 1

我发现了同样的事情--但我认为有一件事是重要的，那就是区分私有代码单元和公共可访问的代码单元。我确实认为，始终对“在公共API中公开的最小的、可用的代码单元”进行单元测试是很重要的。

公共API在重构期间不应该改变(因为它破坏了二进制兼容性和版本控制)，所以这个问题确实存在。

至于私有API，这里有一个平衡。测试的规模越小，对测试的依赖程度就越高。测试的级别越高，测试就越灵活，越有可能在重构中幸存下来。

话虽如此，我相信两者都很重要。大规模的重构总是需要重新编写测试--这只是测试的一部分。

Answer 2

这是一个粒度问题，就像金发女孩和三只熊一样。你想要的东西不是太小，不是太大，而是恰到好处。

如果粒度太小，那么您可能会发现这是浪费时间。如果它太大，那么它可能会错过重要的约束，这些约束在重构/重新配置等过程中应该保持不变。

就像任何“最佳实践”一样，这些想法通常是在理论上形成的，但需要一些常识，并针对您的特定情况进行调整，才能对您有用。

Answer 3

在我看来，测试的代码单元越小，从测试失败中获得的信息就越多。如果你有一个覆盖更大代码段的更高级别的测试，那么失败将告诉你更少的关于问题所在的信息。