你应该尽量少测试!

这意味着，您应该编写足够多的单元测试来揭示意图。这一点经常被掩盖。单元测试的成本很高。如果您进行了更改，并且必须更改测试，那么您将不那么敏捷。保持单元测试短小精悍。这样它们就有很大的价值。

我经常看到许多永远不会崩溃的测试，它们又大又笨拙，没有提供太多价值，它们最终只会拖慢你的速度。

你应该尽量少测试!

这意味着，您应该编写足够多的单元测试来揭示意图。这一点经常被掩盖。单元测试的成本很高。如果您进行了更改，并且必须更改测试，那么您将不那么敏捷。保持单元测试短小精悍。这样它们就有很大的价值。

我经常看到许多永远不会崩溃的测试，它们又大又笨拙，没有提供太多价值，它们最终只会拖慢你的速度。

我是一名维护工程师，负责一个文档记录不佳、糟糕而庞大的代码库。我希望编写代码的人已经为它编写了单元测试。 每次我进行更改和更新产品代码时，我都担心自己可能会因为没有考虑某些条件而引入错误。 如果他们编写测试，那么对代码库的更改就会更容易、更快。(与此同时，代码库将处于更好的状态)..

我认为，在编写api或框架时，单元测试非常有用，因为这些api或框架必须持续多年，并由原始编码器以外的人使用/修改/发展。

最好的说服方式是……找到一个bug，为它写一个单元测试，修复这个bug。

这个特定的错误不太可能再次出现，您可以通过测试来证明它。

如果你做得足够多，其他人很快就会明白。

我在几年前发现了TDD，从那时起我就使用它编写了所有我喜欢的项目。我估计，TDD一个项目所花费的时间与牛仔式地组合一个项目所花费的时间大致相同，但我对最终产品的信心增加了，以至于我忍不住有一种成就感。

我还觉得它改进了我的设计风格(更面向界面，以防我需要一起模拟东西)，而且，正如顶部的绿色帖子所写的，它有助于“编码便秘”:当你不知道接下来要写什么，或者你有一个令人生畏的任务摆在你面前时，你可以写小一点的。

最后，我发现到目前为止，TDD最有用的应用是在调试中，如果仅仅因为您已经开发了一个询问框架，那么您就可以用它来刺激项目以可重复的方式产生错误。

单元测试可以帮助您以更少的错误发布软件，同时降低总体开发成本。您可以点击链接阅读更多关于单元测试的好处