还没有人提到的一件事是，让所有开发人员承诺实际运行和更新任何现有的自动化测试。当您重新进行自动化测试并发现由于新的开发而出现故障时，会失去很多价值并使自动化测试非常痛苦。因为开发人员已经手动测试了代码，所以大多数测试不会指出错误，所以花在更新它们上的时间只是浪费。

说服怀疑者不要破坏其他人在单元测试上所做的工作，对于从测试中获得价值更为重要，而且可能更容易。

每次从存储库更新时，花费数小时更新由于新特性而损坏的测试既没有效率也没有乐趣。

单元测试的好处之一是可预测性。

在单元测试之前，我可以非常准确地预测编写代码所需的时间，但无法预测调试所需的时间。

现在，因为我可以计划将要编写什么测试，所以我知道编码需要多长时间，并且在编码结束时，系统已经调试好了!这为开发过程带来了可预见性，消除了许多压力，但仍然保留了所有的乐趣!!

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

使用单元测试套件，可以在保持其余功能不变的情况下对代码进行更改。这是一个很大的优势。当你完成新功能的编码时，你会使用单元测试套件和回归测试套件吗?

我曾多次尝试单元测试，我仍然相信，考虑到我的情况，这是值得的。

我开发网站，其中很多逻辑涉及在数据库中创建、检索或更新数据。当我为了单元测试的目的而尝试“模拟”数据库时，它变得非常混乱，似乎有点毫无意义。

当我围绕业务逻辑编写单元测试时，从长远来看它从未真正帮助过我。因为我主要独自从事项目工作，我倾向于直观地知道哪些代码区域可能会受到我所从事的工作的影响，并且我手动测试这些区域。我希望尽可能快地向客户交付解决方案，而单元测试通常看起来是浪费时间。我列出了手动测试，并亲自完成它们，并在执行过程中标记它们。

我可以看到，当一个开发团队在一个项目中工作并互相更新代码时，这可能是有益的，但即使这样，我认为如果开发人员具有高质量，良好的沟通和编写良好的代码通常就足够了。

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

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