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

这是非常以. net为中心的，但是有人尝试过Pex吗?

我非常怀疑，直到我尝试了——哇，多么精彩的表演。以前我想“我不会被这个概念说服，直到我明白它实际上对我有什么好处”。我只跑了一次就改变了主意，说:“我不在乎你怎么知道那里有致命异常的风险，但现在我知道我必须处理它”

也许这种行为唯一的缺点是它会标记所有事情，给你六个月的积压。但是，如果你有代码债，你总是有代码债，只是你不知道而已。告诉项目经理可能有20万个故障点，而你之前只知道有几十个，这是一个令人讨厌的前景，这意味着首先解释这个概念是至关重要的。

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

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

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

单元测试绝对是值得付出努力的。不幸的是，您选择了一个困难的(但不幸的是常见的)场景来实现它。

从单元测试中获得的最大好处是从头开始使用它——在一些精选的小项目中，我有幸在实现类之前编写单元测试(此时接口已经完成)。通过适当的单元测试，您可以在类还处于婴儿期时就发现并修复它们，而不是在将来毫无疑问会集成到复杂系统中的任何地方。

如果您的软件是完全面向对象的，那么您应该能够在类级别上添加单元测试，而不需要太多的努力。如果您没有那么幸运，您仍然应该尽可能地尝试合并单元测试。确保当你添加新功能时，新部分都有清晰的接口，你会发现单元测试让你的工作变得更容易。

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

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

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.

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

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