Unit testing helps a lot in projects that are larger than any one developer can hold in their head. They allow you to run the unit test suite before checkin and discover if you broke something. This cuts down a lot on instances of having to sit and twiddle your thumbs while waiting for someone else to fix a bug they checked in, or going to the hassle of reverting their change so you can get some work done. It's also immensely valuable in refactoring, so you can be sure that the refactored code passes all the tests that the original code did.

如果你正在使用NUnit，一个简单而有效的演示就是在他们面前运行NUnit自己的测试套件。看到一个真正的测试套件对代码库进行测试，胜过千言万语……

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

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

作为一名物理专业的学生，我非常有动力去证明我的代码是可以正常工作的。您可以从逻辑上证明这一点，随着实现变得更加复杂，难度会急剧增加，或者您可以通过良好的测试对功能进行(尽可能接近的)经验证明。

如果不提供函数的逻辑证明，就必须进行测试。唯一的选择是说“我认为代码可以工作....”

[我有一个观点，我不能在上面看到]

“每个人都在进行单元测试，他们不一定意识到这一点——事实”

想想看，你写了一个函数来解析一个字符串并删除新的行字符。作为一个开发新手，你要么在命令行中通过Main()实现它来运行几个用例，要么用一个按钮组合一个可视化前端，将你的函数绑定到几个文本框和一个按钮上，然后看看会发生什么。

这就是单元测试——基本的和糟糕的组合在一起，但是你测试了一些情况下的代码段。

你写一些更复杂的东西。当您抛出一些用例(单元测试)并将其调试到代码中并进行跟踪时，它会抛出错误。你在浏览过程中查看这些值，并决定它们是对还是错。在某种程度上，这是单元测试。

这里的单元测试实际上是采用这种行为，将其形式化为结构化模式并保存，以便您可以轻松地重新运行这些测试。如果您编写了一个“适当的”单元测试用例而不是手动测试，那么它所花费的时间是相同的，或者随着您的经验的增加可能会更少，并且您可以一次又一次地重复它

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

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

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