我对单元测试和 TDD 相当陌生，所以请耐心等待我问一些人可能会考虑的新手问题，或者这是否已经被辩论过。如果这被证明是一个“糟糕的问题”(太主观且无法辩论)，我会很高兴地关闭它。但是，我已经搜索了几天，并没有得到明确的答案，我需要更好地理解这一点，所以我知道没有比在这里发布更好的方法来获取更多信息。
我已经开始阅读 older book关于单元测试(因为一位同事手头有它)，它的开篇讨论了为什么要进行单元测试。它提出的要点之一是，从长远来看，您的代码更可靠、更简洁，并且更不容易出现错误。它还指出，有效的单元测试将使跟踪和修复错误变得更加容易。因此，它似乎非常关注整体预防/减少代码中的错误。
另一方面，我也找到了an article关于编写出色的单元测试，它指出单元测试的目标是使您的设计更加健壮，相反，发现错误是手动测试的目标，而不是单元测试。
因此，作为 TDD 的新手，我对进入 TDD 和构建单元测试的心态有点困惑。我承认，我现在在我最近开始的项目中进行这项工作的部分原因是因为我厌倦了我的更改破坏了以前存在的代码。诚然，上面链接的文章至少指出这是 TDD 的一个优势。但我希望通过返回并在我现有的代码中添加单元测试(然后从现在开始继续 TDD)有助于首先防止这些错误。
这本书和这篇文章真的是在用不同的语气说同样的话，还是在这个主题上有一些主观性，而我所看到的只是两个人对如何处理 TDD 有一些不同的看法？
提前致谢。
最佳答案
我将使用以前的 answer 的混音来尝试一下。我写。简而言之，我不认为这是插入良好设计和最小化错误之间的二分法。我更多地将其视为一个(好的设计)导致另一个(最小化错误)。
我倾向于说 TDD 是一个碰巧涉及单元测试的设计过程。这是一个设计过程，因为在每次 Red-Green-Refactor 迭代中，您首先为不存在的代码编写测试。你正在设计。
TDD 的第一个优点是保证您的代码设计是可测试的。可测试代码往往具有松散耦合和高内聚性。松散耦合和高内聚很重要，因为它们使代码在需求发生变化时易于更改。 TDD 的第二个优点是，在您完成系统实现后，您碰巧有一个巨大的回归套件来捕捉任何错误和假设变化。因此，TDD 由于它创建的设计而使您的代码易于更改，并且由于它创建的测试工具，它使您的代码可以安全地更改。
关于unit-testing - 单元测试目标和 TDD : find/minimize bugs or improve design?，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/6636839/