我正在努力将单元测试集成到我所在团队的开发过程中，并且有一些怀疑论者。有什么好方法可以让团队中持怀疑态度的开发人员相信单元测试的价值？在我的具体情况下，我们将在添加功能或修复错误时添加单元测试。不幸的是，我们的代码库不适合简单的测试。
我们办公室每天都有这样的交流：
“伙计，我只是喜欢单元测试，我刚刚能够对某些工作的方式进行大量更改，然后能够通过再次运行测试来确认我没有破坏任何东西......”
细节每天都在变化，但情绪不会。单元测试和测试驱动开发 (TDD) 有很多隐藏的和个人的好处，也有很多显而易见的好处，除非他们自己做，否则你无法真正向他们解释。
但是，忽略这一点，这是我的尝试！
单元测试允许您快速对代码进行重大更改。你知道它现在可以工作了，因为你已经运行了测试，当你做出你需要做的改变时，你需要让测试再次工作。这可以节省几个小时。
TDD 帮助您了解何时停止编码。您的测试让您确信您现在已经完成了足够多的工作，并且可以停止调整并继续下一步。
测试和代码协同工作以实现更好的代码。您的代码可能不好/有问题。你的测试可能是坏的/错误的。在 TDD 中，您寄希望于坏/错误的可能性 都 较低。通常是需要修复的测试，但这仍然是一个很好的结果。
TDD 有助于编码便秘。当面临一项庞大而艰巨的工作时，编写测试将使您快速前进。
单元测试可以帮助你真正理解你正在处理的代码的设计。您无需编写代码来做某事，而是首先概述您使代码受到的所有条件以及您期望从中得到的输出。
单元测试给你即时的视觉反馈，当我们完成后，我们都喜欢那些绿灯的感觉。这是非常令人满意的。在中断后从中断的地方重新开始也容易得多，因为你可以看到你到达的地方——下一个需要修复的红灯。
与流行的看法相反，单元测试并不意味着编写两倍的代码，或者编写更慢的代码。一旦掌握了窍门，它就会比没有测试的编码更快、更健壮。测试代码本身通常是相对微不足道的，不会给你正在做的事情增加很大的开销。这是你只有在做的时候才会相信的：）
我认为是 Fowler 说的：“经常运行的不完美测试比根本不编写的完美测试要好得多”。我将此解释为允许我在我认为最有用的地方编写测试，即使我的其余代码覆盖范围非常不完整。
好的单元测试可以帮助记录和定义应该做什么
单元测试有助于代码重用。将您的代码 和 测试迁移到您的新项目。调整代码直到测试再次运行。
我参与的很多工作都没有很好地进行单元测试（Web 应用程序用户交互等），但即便如此，我们都在这家商店中被测试感染，并且当我们完成测试时最开心。我不能高度推荐这种方法。
