一个需要耗时十分之一秒才能执行完的单元测
这话是认真的。十分之一秒对于单元测试来说简直就像一个世纪一样。不信的话让我们来做一点简单的算术吧：假设你有一个项目，其中包含3 000个类，每个类平均大约有10个测试，一共算起来就是30 000个测试。倘若这些测试个个都耗时十分之一秒才能运行完的话，那整个项目测试一遍需要多少时间呢?将近一个小时!对于反馈来说这段等待时间可不短。什么?你的项目没有3 000个类?那一半总有吧，这样算下来也仍然要等半个小时呢。另一方面，假如我们的测试只需耗时百分之一秒呢?很显然，我们一下子从需要等一个小时变成了只需等5到10分钟!这样的话，虽说我还是比较谨慎的只取出其中的部分单元测试来用，但哪怕每隔几个小时就将它们全部运行一遍我也不再害怕。
单元测试运行得快。运行得不快的不是单元测试。
有些测试容易跟单元测试混淆起来。譬如下面这些测试就不是单元测试：
(1) 跟数据库有交互;
(2) 进行了网络间通信;
(3) 调用了文件系统;
(4) 需要你对环境作特定的准备(如编辑配置文件)才能运行的。
当然，这并不是说这些测试就是坏的。编写它们常常也是有价值的，而且你通常也会在单元测试用具内来编写它们。然而，将它们跟真正的单元测试区分开来还是很有必要的，因为这样你就能够知道哪些测试是你可以(在你进行代码修改的时候)快速运行的。
单元测试有下面的这些优点：
1、它是一种验证行为。
程序中的每一项功能都是测试来验证它的正确性。它为以后的开发提供支缓。就算是开发后期，我们也可以轻松的增加功能或更改程序结构，而不用担心这个过程中会破坏重要的东西。而且它为代码的重构提供了保障。这样，我们就可以更自由的对程序进行改进。
2、它是一种设计行为。
编写单元测试将使我们从调用者观察、思考。特别是先写测试(test-first)，迫使我们把程序设计成易于调用和可测试的，即迫使我们解除软件中的耦合。
3、它是一种编写文档的行为。
单元测试是一种无价的文档，它是展示函数或类如何使用的最佳文档。这份文档是可编译、可运行的，并且它保持最新，永远与代码同步。
4、它具有回归性。
自动化的单元测试避免了代码出现回归，编写完成之后，可以随时随地的快速运行测试。
单元测试的范畴
如果要给单元测试定义一个明确的范畴，指出哪些功能是属于单元测试，这似乎很难。但下面讨论的四个问题，基本上可以说明单元测试的范畴，单元测试所要做的工作。
1、 它的行为和我期望的一致吗?
这是单元测试最根本的目的，我们就是用单元测试的代码来证明它所做的就是我们所期望的。
2、 它的行为一直和我期望的一致吗?
编写单元测试，如果只测试代码的一条正确路径，让它正确走一遍，并不算是真正的完成。软件开发是一个项复杂的工程，在测试某段代码的行为是否和你的期望一致时，你需要确认：在任何情况下，这段代码是否都和你的期望一致;譬如参数很可疑、硬盘没有剩余空间、缓冲区溢出、网络掉线的时候。
3、 我可以依赖单元测试吗?
不能依赖的代码是没有多大用处的。既然单元测试是用来保证代码的正确性，那么单元测试也一定要值得依赖。
4、 单元测试说明我的意图了吗?
单元测试能够帮我们充分了解代码的用法，从效果上而言，单元测试就像是能执行的文档，说明了在你用各种条件调用代码时，你所能期望这段代码完成的功能。
文章来源于领测软件测试网 https://www.ltesting.net/
