关于这个话题，我写了一篇很大的博客文章。我发现单靠单元测试是不值得的，而且通常在截止日期临近时就会被削减。

与其从“测试后验证”的角度来讨论单元测试，我们应该看看在实现之前编写规范/测试/想法时所发现的真正价值。

这个简单的想法改变了我写软件的方式，我不会回到“旧的”方式。

测试优先开发如何改变了我的生活

单元测试很像去健身房。你知道这对你有好处，所有的争论都有意义，所以你开始锻炼。刚开始有一种冲动，这很好，但几天后你开始怀疑是否值得这样做。你每天花一个小时换衣服，在仓鼠转轮上跑步，你不确定除了腿和手臂疼痛之外，你真的得到了什么。

然后，也许一两周后，就在疼痛消失的时候，一个重要的截止日期开始来临。你需要把醒着的每一个小时都用来完成“有用的”工作，所以你要去掉无关紧要的事情，比如去健身房。你改掉了这个习惯，当截止日期结束的时候，你又回到了起点。如果你设法回到健身房，你会觉得和你第一次去的时候一样酸痛。

You do some reading, to see if you're doing something wrong. You begin feel a little bit of irrational spite toward all the fit, happy people extolling the virtues of exercise. You realize that you don't have a lot in common. They don't have to drive 15 minutes out of the way to go to the gym; there is one in their building. They don't have to argue with anybody about the benefits of exercise; it is just something everybody does and accepts as important. When a Big Deadline approaches, they aren't told that exercise is unnecessary any more than your boss would ask you to stop eating.

所以，回答你的问题，单元测试通常是值得付出努力的，但是所需的努力量对每个人来说都不一样。如果你在一家不重视代码质量的公司处理意大利面条式的代码库，那么单元测试可能需要付出巨大的努力。(许多经理会歌颂单元测试，但这并不意味着他们会在关键时刻支持单元测试。)

如果你正试图将单元测试引入到你的工作中，并且没有看到你所期待的所有阳光和彩虹，不要责怪自己。你可能需要找一份新工作来真正让单元测试为你工作。

作为一名物理专业的学生，我非常有动力去证明我的代码是可以正常工作的。您可以从逻辑上证明这一点，随着实现变得更加复杂，难度会急剧增加，或者您可以通过良好的测试对功能进行(尽可能接近的)经验证明。

如果不提供函数的逻辑证明，就必须进行测试。唯一的选择是说“我认为代码可以工作....”

单元测试的一个好处是，它们可以作为说明代码行为方式的文档。好的测试有点像参考实现，团队成员可以通过查看它们来了解如何将他们的代码与您的代码集成。

就在今天，我不得不更改一个类，之前已经为其编写了单元测试。 测试本身写得很好，包括我甚至没有想过的测试场景。 幸运的是，所有测试都通过了，我的更改很快得到了验证，并自信地放到了测试环境中。

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

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