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

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

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

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

单元测试的好处之一是可预测性。

在单元测试之前，我可以非常准确地预测编写代码所需的时间，但无法预测调试所需的时间。

现在，因为我可以计划将要编写什么测试，所以我知道编码需要多长时间，并且在编码结束时，系统已经调试好了!这为开发过程带来了可预见性，消除了许多压力，但仍然保留了所有的乐趣!!

单元测试非常值得最初的投资。自从几年前开始使用单元测试以来，我发现了一些真正的好处:

回归测试消除了恐惧 对代码进行更改(什么都没有 就像看到代码的温暖光芒 每次有变化，要么工作，要么爆发 了) 以下的可执行代码示例 其他团队成员(包括你自己) 6个月的时间…) 无情的重构——这是令人难以置信的回报，试试吧!

代码片段可以极大地帮助减少创建测试的开销。创建能够在几秒钟内创建类大纲和相关单元测试fixture的代码片段并不困难。

测试驱动开发中经常被忽略的一个主要部分是可测试代码的编写。乍一看，这似乎是一种妥协，但您会发现可测试代码最终也是模块化的、可维护的和可读的。 如果你仍然需要说服别人，这是一个关于单元测试优点的简单演示。

根据我的经验，在复杂的软件环境中，单元测试和集成测试是“必须的”。

为了说服团队中的开发人员编写单元测试，您可能需要考虑在开发环境中集成单元测试回归分析(例如，在您的日常构建过程中)。

一旦开发人员知道如果单元测试失败，他们就不必花那么多时间调试它来发现问题，他们就会更有动力去编写这些测试。

这里有一个工具可以提供这样的功能:

单元测试回归分析工具