多年来，我一直试图说服人们，他们需要为自己的代码编写单元测试。无论他们是先编写测试(如TDD)还是在编写功能之后，我总是试图向他们解释对代码进行单元测试的所有好处。几乎没有人反对我。你不能否认一些显而易见的事情，任何聪明的人都会看到单元测试和TDD的好处。

单元测试的问题在于它需要行为上的改变，而要改变人们的行为是非常困难的。用语言，你会让很多人同意你的观点，但你不会看到他们做事的方式有太多变化。

你必须通过行动来说服人们。你的个人成功会比你的争论吸引更多的人。如果他们看到你不只是在谈论单元测试或TDD，而是在做你鼓吹的事情，而且你是成功的，人们就会试图模仿你。

You should also take on a lead role because no one writes unit test right the first time, so you may need to coach them on how to do it, show them the way, and the tools available to them. Help them while they write their first tests, review the tests they write on their own, and show them the tricks, idioms and patterns you've learned through your own experiences. After a while, they will start seeing the benefits on their own, and they will change their behavior to incorporate unit tests or TDD into their toolbox.

改变不会在一夜之间发生，但只要有一点耐心，你就可能实现你的目标。

当涉及到重构或重写一段代码时，单元测试也特别有用。如果您有良好的单元测试覆盖率，您就可以满怀信心地进行重构。如果没有单元测试，通常很难确保您没有破坏任何东西。

当您手动测试软件时，通常会使用一小组测试/操作。最终，您将自动修改输入数据或操作，以便围绕已知问题进行导航。应该有单元测试来提醒您某些事情不能正常工作。

我建议在编写代码之前编写测试，添加新的测试/数据来改进主代码的功能!

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

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

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

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