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

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

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

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

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

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

偶尔，我自己或我的同事会花几个小时来研究一个不太明显的错误，一旦发现了错误的原因，90%的情况下代码都没有经过单元测试。单元测试并不存在，因为开发人员为了节省时间而偷工减料，但随后却失去了这一点和更多的调试。

花少量的时间来编写单元测试可以节省未来调试的时间。

One of the best things about unit testing is that your code will become easier to test as you do it. Preexisting code created without tests is always a challenge because since they weren't meant to be unit-tested, it's not rare to have a high level of coupling between classes, hard-to-configure objects inside your class - like an e-mail sending service reference - and so on. But don't let this bring you down! You'll see that your overall code design will become better as you start to write unit-tests, and the more you test, the more confident you'll become on making even more changes to it without fear of breaking you application or introducing bugs.

There are several reasons to unit-test your code, but as time progresses, you'll find out that the time you save on testing is one of the best reasons to do it. In a system I've just delivered, I insisted on doing automated unit-testing in spite of the claims that I'd spend way more time doing the tests than I would by testing the system manually. With all my unit tests done, I run more than 400 test cases in less than 10 minutes, and every time I had to do a small change in the code, all it took me to be sure the code was still working without bugs was ten minutes. Can you imagine the time one would spend to run those 400+ test cases by hand?

当涉及到自动化测试——无论是单元测试还是验收测试——每个人都认为编写可以手动完成的代码是浪费精力，有时这是真的——如果你计划只运行一次测试的话。自动化测试最好的部分是，您可以毫不费力地运行它们几次，并且在第二次或第三次运行之后，您所浪费的时间和精力已经得到了补偿。

最后一个建议是，不仅要对代码进行单元测试，还要先进行测试(详见TDD和BDD)。

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

你应该尽量少测试!

这意味着，您应该编写足够多的单元测试来揭示意图。这一点经常被掩盖。单元测试的成本很高。如果您进行了更改，并且必须更改测试，那么您将不那么敏捷。保持单元测试短小精悍。这样它们就有很大的价值。

我经常看到许多永远不会崩溃的测试，它们又大又笨拙，没有提供太多价值，它们最终只会拖慢你的速度。

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