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

在我们的办公室里，每天都有这样的对话:

“伙计，我就是喜欢单元测试，我刚刚能够对某些东西的工作方式进行了一系列更改，然后能够通过再次运行测试来确认我没有破坏任何东西……”

细节每天都在变化，但情绪却不变。单元测试和测试驱动开发(TDD)有很多隐藏的和个人的好处，也有很多明显的好处，除非他们自己做，否则你无法真正向他们解释。

但是，忽略这一点，下面是我的尝试!

Unit Tests allows you to make big changes to code quickly. You know it works now because you've run the tests, when you make the changes you need to make, you need to get the tests working again. This saves hours. TDD helps you to realise when to stop coding. Your tests give you confidence that you've done enough for now and can stop tweaking and move on to the next thing. The tests and the code work together to achieve better code. Your code could be bad / buggy. Your TEST could be bad / buggy. In TDD you are banking on the chances of both being bad / buggy being low. Often it's the test that needs fixing but that's still a good outcome. TDD helps with coding constipation. When faced with a large and daunting piece of work ahead writing the tests will get you moving quickly. Unit Tests help you really understand the design of the code you are working on. Instead of writing code to do something, you are starting by outlining all the conditions you are subjecting the code to and what outputs you'd expect from that. Unit Tests give you instant visual feedback, we all like the feeling of all those green lights when we've done. It's very satisfying. It's also much easier to pick up where you left off after an interruption because you can see where you got to - that next red light that needs fixing. Contrary to popular belief unit testing does not mean writing twice as much code, or coding slower. It's faster and more robust than coding without tests once you've got the hang of it. Test code itself is usually relatively trivial and doesn't add a big overhead to what you're doing. This is one you'll only believe when you're doing it :) I think it was Fowler who said: "Imperfect tests, run frequently, are much better than perfect tests that are never written at all". I interpret this as giving me permission to write tests where I think they'll be most useful even if the rest of my code coverage is woefully incomplete. Good unit tests can help document and define what something is supposed to do Unit tests help with code re-use. Migrate both your code and your tests to your new project. Tweak the code till the tests run again.

我参与的很多工作都没有很好地进行单元测试(web应用程序用户交互等)，但即使如此，我们在这个商店里都被测试感染了，当我们把测试束缚住时，我们最高兴。我怎么极力推荐这种方法都不为过。

最好的说服方式是……找到一个bug，为它写一个单元测试，修复这个bug。

这个特定的错误不太可能再次出现，您可以通过测试来证明它。

如果你做得足够多，其他人很快就会明白。

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

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.

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

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

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测试知识的圣经——它可能是我书架上被引用最多的书之一，我每天都在查阅它:链接文本