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

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

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.

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

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

Unit Testing is one of the most adopted methodologies for high quality code. Its contribution to a more stable, independent and documented code is well proven . Unit test code is considered and handled as an a integral part of your repository, and as such requires development and maintenance. However, developers often encounter a situation where the resources invested in unit tests where not as fruitful as one would expect. In an ideal world every method we code will have a series of tests covering it’s code and validating it’s correctness. However, usually due to time limitations we either skip some tests or write poor quality ones. In such reality, while keeping in mind the amount of resources invested in unit testing development and maintenance, one must ask himself, given the available time, which code deserve testing the most? And from the existing tests, which tests are actually worth keeping and maintaining? See here

关于单元测试要记住的一件事是，它对开发人员来说是一种安慰。

相反，功能测试是针对用户的:无论何时添加功能测试，您都是在测试用户将看到的东西。当您添加单元测试时，您只是让开发人员的生活更轻松。在这方面有点奢侈。

当您必须在编写单元或功能测试之间做出选择时，请记住这种二分法。

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

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

Yes - Unit Testing is definitely worth the effort but you should know it's not a silver bullet. Unit Testing is work and you will have to work to keep the test updated and relevant as code changes but the value offered is worth the effort you have to put in. The ability to refactor with impunity is a huge benefit as you can always validate functionality by running your tests after any change code. The trick is to not get too hung up on exactly the unit-of-work you're testing or how you are scaffolding test requirements and when a unit-test is really a functional test, etc. People will argue about this stuff for hours on end and the reality is that any testing you do as your write code is better than not doing it. The other axiom is about quality and not quantity - I have seen code-bases with 1000's of test that are essentially meaningless as the rest don't really test anything useful or anything domain specific like business rules, etc of the particular domain. I've also seen codebases with 30% code coverage but the tests were relevant, meaningful and really awesome as they tested the core functionality of the code it was written for and expressed how the code should be used.

在探索新的框架或代码库时，我最喜欢的一个技巧是为“它”编写单元测试，以发现事物是如何工作的。这是一个学习新事物的好方法，而不是阅读枯燥的文档:)

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

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