金字塔测试原理：写好单元测试的8个小技巧，一文总结

想必金字塔测试原理大家已经很熟悉了，近年来的测试驱动开放在各个公司开始盛行，测试代码先写的倡议被反复提及。

鉴于此，许多中大型软件公司对单元测试的要求也逐渐提高。那么，编写单元测试有哪些小技巧可以借鉴和学习的呢？

测试代码文件路径与开发代码文件路径“相同”

这里的“相同”并不是完全意义的一摸一样，测试代码和开发代码处于同一目录，而是指的测试代码文件路径你与开发代码文件路径“大体相同”。

如下图1、2所示，开发代码路径和测试代码路径都包括/java/ru/yandex/clickhouse/。

图1 开发代码路径

图2 测试代码路径

测试代码文件名清晰

清晰的测试代码文件名可以帮助阅读测试代码的其他人员对该文件的测试内容有很好的初步认识。

例如上图2所示：测试代码文件ClickHouseConnectionTest.java，从命名上就可以帮助阅读人员获悉该测试代码文件是针对ClickHouseConnection.java的测试。

清楚地命名单元测试名称

不要担心名字过长，一个长而完整的名称可以让您立即知道哪个测试失败了，以及该测试到底想做什么。

长时间命名的测试也可以记录你的测试。如下图3所示：从testMaxMemoryUsage()名称就可以看出该测试代码是针对最大内存使用量地测试。显而易见，该名称远远好于test1()、test()2……

图3 单元测试名称样例

一次测试一项

同集成测试、系统测试原则一致，测试用例应该保持“专有性”原则，即每次测试只针对一个功能进行测试。

如下图4所示：都是针对clickhouse进行配置，然后发起查询的功能，但图上方主要是针对最大执行事件设置的测试，图下方是针对最大内存使用量设置的测试。

图4 单元测试“专有性”样例

测试保持独立性

测试保持独立性指的是不同测试用例/代码块之间不应该存在依赖（如：test2()的代码依赖test1()中的参数设置），每一个测试用例/代码块应该能独立运行。

鉴于此，我们可以把一些通用性配置（如数据库初始化）提取到测试套件/代码文件初始化环节。

清晰地抛出测试失败地异常

测试用例/代码并不能保证每次运行都能成功（如开发代码进行重构或功能变动引起地测试代码失败），因此在编写测试代码时需要捕获失败时的异常，并清晰地返回。

例如：若使用Integer aa=1;Integer bb=2;Assert.assertTrue(aa==bb);代码判断变量aa和bb是否相等，若不相等时只会判定失败而不会有详细错误信息。

若改为Assert.assertEquals(aa, bb);则会在失败时返回类似的Expected 1, but the actual result was 2的信息，这样的错误信息更有价值。

不要执着于测试覆盖率

谈到单元测试，就会想到测试覆盖率。测试覆盖率主要指的是代码路径覆盖率和分支覆盖率。

在编写单元测试时难免会陷入一味追求100%测试覆盖率的陷阱。100%测试覆盖率是一个很难实现的愿景，100% 的覆盖率并不意味着你已经覆盖了所有的边缘情况，它只是意味着所有的代码路径都被执行了。

在实际测试过程中，我们应该关注的是测试功能是否覆盖而不是单元代码路径是否被全部覆盖。例如：对于具有相同代码的文件（同一代码块复制粘贴），追求100%的测试覆盖率会导致测试冗余。

因此，我们应该从保障功能正常的角度出发编写单元测试用例，而不是针对每个单元函数编写单元测试用例。

那么，如何从功能的角度出发编写单元测试用例呢？最简单的一点就是查看被调用的函数模块。

若某个模块被上层功能函数调用，那么这个模块就需要我们编写单元测试用例进行守护。

最好有注释

注释可以帮助其他阅读代码的人员更快地理解代码，单元测试也是代码，因此养成注释地习惯可以提高你编写代码的素养。

适当地给单元测试用例分类，提高运行效率

单元测试用例和集成测试用例、系统测试用例一样，当测试用例数量变得很大时，每次修改部分代码运行所有的单元测试用例显得累赘。

这个时候如果你的单元测试用例有明确的分类，那么就能提高运行效率。

如下图5所示：该单元测试标签为”unit”，在运行时可以根据“unit”标签选中该单元测试用例。

图5 单元测试标签样例

上述单元测试小技巧，希望能帮助各位单元测试初学者。