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

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

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可以根据需求文档验证功能，那么就完成了。船。

在我的脑海中，最经典的例子就是嵌入到GridView的ASPX页面中的SqlDataReader。代码都在ASPX文件中。SQL位于存储过程中。你做什么单元测试?如果页面做了它应该做的事情，那么是否真的应该将其重新设计成几个层，以便实现自动化?

简而言之——是的。它们值得你付出每一分努力……在某种程度上。在一天结束的时候，测试仍然是代码，并且很像典型的代码增长，您的测试最终将需要重构，以便可维护和可持续。有一大堆的陷阱!当涉及到单元测试时，但是没有什么，我的意思是没有什么比丰富的单元测试集更能让开发人员更自信地进行更改了。

I'm working on a project right now.... it's somewhat TDD, and we have the majority of our business rules encapuslated as tests... we have about 500 or so unit tests right now. This past iteration I had to revamp our datasource and how our desktop application interfaces with that datasource. Took me a couple days, the whole time I just kept running unit tests to see what I broke and fixed it. Make a change; Build and run your tests; fix what you broke. Wash, Rinse, Repeat as necessary. What would have traditionally taken days of QA and boat loads of stress was instead a short and enjoyable experience.

提前准备，一点点额外的努力，当你不得不开始摆弄核心特性/功能时，它会给你带来十倍的回报。

我买了这本书——它是xUnit测试知识的圣经——它可能是我书架上被引用最多的书之一，我每天都在查阅它:链接文本

你想说服谁?工程师还是经理?如果你试图说服你的工程师同事，我认为你最好的办法是迎合他们的愿望，让他们做出高质量的软件。有许多研究表明，它能发现漏洞，如果他们关心做好工作，这对他们来说就足够了。

如果您试图说服管理层，您将很可能不得不做一些成本/收益推理，说明未检测到的缺陷的成本大于编写测试的成本。一定要把不可转化的成本也包括在内，比如失去客户的信心等等。

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

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

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