编写优秀的单元测试（三）如何编写优秀的单元测试

定义

首先，我们需要声明一点，对于好的定义，一千个人心中有一千个哈姆雷特。每个人对于好的定义不同，我们定义的“好”只是基于现有知识的，广义的“好”，知识是不断发展变化的，“好”的标准也不是一成不变的。

那么，优秀的单元测试具备几个要素呢：

• 测试代码的可读性和可维护性，研究证明，代码的可读性与缺陷密度密切相关
• 代码在项目中或特定源码中的组织方式
• 测试所检查的内容
• 测试的可靠性和可重复性
• 测试对于测试替身的应用

写出优秀的单元测试

• 使用清晰的文档结构，避免巨型测试文件的产生（一个几千行的文件总是让我们头大）
• 减小颗粒度，避免巨大测试方法的产生（一个几百行的测试函数一旦测试没通过，查找原因都是个让人头疼的事情）
• 测试的命名要有意义，与实际测试的内容一定要一致。（要是不一致误导性都多强就不多说了吧）
• 测试程序不该有依赖。这句话的意思是说，测试程序写好之后，如果换个电脑直接迁出代码，测试能不能正常通过？如果依赖了系统的某个运行库或者测试环境，特定的服务等，就会让测试增加许多的复杂性
• 测试之间不应该有互相的依赖。不要出现A没有通过导致B C测试都通不过的情况。这样不利于问题的快速定位。
• 编写有意义的测试（下面专门来讲）
• 使用测试替身。我们一提到测试替身的时候，经常直接想到mock，事实上，测试替身是 桩（Stub） 伪造对象（fake）测试间