一个优秀的单元测试应该是怎样的？

单元测试（unit testing），是指对软件中的最小可测试单元进行检查和验证。对于单元测试中单元的含义，一般来说，要根据实际情况去判定其具体含义，如C语言中单元指一个函数，Java里单元指一个类，图形化的软件中可以指一个窗口或一个菜单等。总的来说，单元就是人为规定的最小的被测功能模块。单元测试是在软件开发过程中要进行的最低级别的测试活动，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。

先提几个关于单元测试的问题：

1、两周或两个月、甚至两年前写的单元测试，还可以运行并得到结果吗？

2、两个月前写的单元测试，任何一位团队成员都可以运行并得到结果吗？

3、是否可以在几分钟内跑完所有的单元测试？

4、是否可以单击一个按钮就执行全部单元测试？

5、是否能在几分钟内写一个基本的单元测试？

场景1：在应用程序生命周期中，经常需要改动代码，极有可能会无意中破坏现有的功能，这被称为”意外缺陷“，当进行到项目末期，程序员顶着交付的压力修复缺陷时，这类情况更是层出不穷。

如果这种影响能在不到三分钟时间内就可以知道，岂不是很棒？

优秀的测试应该以其本来的、非手工的形式轻松执行。

场景2：两个月前些的单元测试，任何一位团队成员都可以运行并得到结果吗？

必须确保你的改动不会影响别人的代码。

因为担心其他代码依赖于正在改动的代码，所以很多程序员都怕改动老系统中的遗留代码。面临的风险是系统稳定性不可预知。

所以，优秀的测试应该是任何人都可使用、运行的。

场景3：是否可以在几分钟内跑完所有的单元测试？

如果不能很快地运行完测试，你就不会经常运行测试（可能一天，或一周，甚至一个月才运行一次。）

当改动代码后，你肯定希望尽快得到反馈，看看是否影响了既有功能，如果不经常运行测试，间隔越久，改动的代码就越多，出现问题后，就需要花更多的时间来改错。

所以，优秀的测试应该是在几分钟内运行并且全部得出结果的。

场景4：可以单击一个按钮就运行所有单元测试吗？

如果做不到这一点，就意味着必须事先配置好运行测试的机器，而后才能正常运行，又或者单元测试还未完全自动化。如果单元测试没有完全自动化，那么你就不会反复运行，团队中其他人也不会。测试的间隔也将拉长。

所以，优秀的测试应该运行起来不费事，不费力。

场景5：能否在几分钟内写一个基本的单元测试？

辨别一个测试是集成测试还是单元测试最简单的方法，不仅仅看它是否需要花时间运行，更要看它是否要花时间做适当的准备和实现。写集成测试很花时间。

单元测试更倾向于测试每个可能出错的小细节。

优秀的测试应该写起来很顺利，不耗时。

单元测试（UnitTest）是一段自动化的代码，用来调用被测试的方法或类，而后验证基于该方法或类的逻辑行为的一些假设。单元测试几乎总是用单元测试框架来写的。它写起来很顺手，运行起来不费时。它是全自动的、可信赖的、可读性强的、可维护的