多年来，我一直试图说服人们，他们需要为自己的代码编写单元测试。无论他们是先编写测试(如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.

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

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

我在其他任何答案中都没有看到这一点，但我注意到的一件事是，我可以更快地调试。你不需要通过正确的步骤序列深入到你的应用程序中，只发现你犯了一个布尔错误，需要重新做一遍。使用单元测试，您可以直接进入正在调试的代码。

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

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

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

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

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

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

根据我的经验，在复杂的软件环境中，单元测试和集成测试是“必须的”。

为了说服团队中的开发人员编写单元测试，您可能需要考虑在开发环境中集成单元测试回归分析(例如，在您的日常构建过程中)。

一旦开发人员知道如果单元测试失败，他们就不必花那么多时间调试它来发现问题，他们就会更有动力去编写这些测试。

这里有一个工具可以提供这样的功能:

单元测试回归分析工具