当涉及到重构或重写一段代码时，单元测试也特别有用。如果您有良好的单元测试覆盖率，您就可以满怀信心地进行重构。如果没有单元测试，通常很难确保您没有破坏任何东西。

单元测试适用于QA人员或你的经理，而不是你;所以绝对不值得。

您应该专注于编写正确的代码(不管这意味着什么)，而不是测试用例。让其他人去担心吧。

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

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

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

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

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

@George Stocker“不幸的是，我们的代码库并不适合简单的测试。”每个人都同意单元测试有好处，但对于这个代码库来说，成本似乎很高。如果成本大于收益，那么他们为什么要对此充满热情呢?倾听你同事的意见;也许对他们来说，单元测试的痛苦比单元测试的价值更大。

具体地说，尽量尽快获得价值，而不是一些感觉良好的“xUnit是绿色的”价值，而是用户和维护者所重视的干净代码。也许您必须为一次迭代强制进行单元测试，然后讨论是否值得这样做。

单元测试的全部意义在于使测试变得简单。这是自动的。“make test”就完成了。如果您面临的问题之一是难以测试代码，那么这就是使用单元测试的最佳理由。