unit-testing - 为什么始终对尽可能小的代码单元进行单元测试是最佳实践？我发现那些测试永远无法在重构中幸存下来

Question

多年来，我一直是测试驱动开发的实践者，总的来说我对此很满意。我还不理解的一部分是您应该始终对“最小可能单元”进行单元测试的想法。

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

对于琐碎的重构，比如四处移动方法，这些都是通过 IDE 完成的，而且由于我使用的是静态类型语言，所以我从来没有遇到过 IDE 无法执行的情况重构完美。

有没有人有类似或相反的经历？

Answer 1

我发现了同样的事情 - 但我认为区分私有(private)代码单元和可公开访问的代码单元很重要。我确实认为始终对“在公共(public) API 中公开的尽可能小的可用代码单元”进行单元测试很重要。

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

至于私有(private) API，这里有一个平衡点。你测试的越小，你就越能依赖你的测试。您的测试级别越高，测试就越灵活，它们就越有可能在重构中幸存下来。

话虽如此，我认为两者都很重要。大规模重构总是需要返工测试 - 这只是一般测试的一部分。