聊一聊，单元测试应该测试什么？

开始

如今大公司愈来愈重视项目的单元测试，甚至明确要求项目的单元测试覆盖率不能低于某个值，足可见单元测试的重要性；

试想若是没有单元测试，那么如何保证代码可以正常运行呢？

测试人员作的只是业务上的集成测试，也就是黑盒测试，对单个的方法是没有办法测试的，并且，测试出的 bug 的范围也会很广，根本不能肯定 bug 的范围，还得去花时间来肯定 bug 出在什么地方。

另外，一个最多见的问题：写单测浪费时间？ 你有没有计算过你改bug的时间（定位+修复），算一下的话你会发现时间浪费的会更多。

参考建议

关于如何写好单元测试，下面有几条建议供你们参考：

1. 测试数据外部化

测试数据大体分为两种：变化的和不变化的，对于不变的测试数据，咱们彻底能够写在单元测试用例代码中，也能够将数据外部化。

而对于测试数据一直在变，而且测试数据量比较大的时候可使用测试数据外部化将数据放在测试用例的外部进行统一管理。

什么是数据外部化？就是将数据放在单元测试用例的外部统一管理，好比咱们能够将一个单元测试用例中的测试数据统一放在一个CSV文件中。

咱们就能够经过好比junit5中的参数测试注解@ParameterizedTest和引入CVS文件的注解@CsvFileSource并指定其中的resources属性指定CSV文件，numLinesToSkip = n 属性指定从第n+1行开始。这样就能够经过一个CSV文件统一管理一个单元测试用例中的数据。

咱们管理测试用例中所须要的数据就只须要管理一个个CSV文件便可。

下面能够看一个案例：（其中具体的使用方法请看博客[junit5系列-参数化测试]()）

@ParameterizedTest
@CsvFileSource(resources = "/two-column.csv", numLinesToSkip = 1)
void testWithCsvFileSource(String first, int second) {
    assertNotNull(first);
    assertNotEquals(0, second);
}

其中，two-column.csv文件内容

Country, reference
Sweden, 1
Poland, 2
"United States of America", 3

2. 构建具备特定结果的测试

• 若是方法结果具备随机性，这样的方法几乎没法测试，因此咱们针对这种方法便没有办法去进行测试。

  • 咱们只能对根据特有数据获得特定结果的方法进行测试。

3. 测试方面全面，设计的每一方面必须有一个测试用例：

• 正面全部情景
• 负面全部情景
• 临界值
• 特殊值

4. 测试用例请尽可能简洁、简短

在能完成测试的基础上尽可能简洁代码，这样不只使代码更加好看，还好维护好理解。
想一想一大堆代码和几行代码你更想看哪一个？

5. 测试用例尽可能快

对于单元测试用例咱们几乎每开发完一个方法或者修改完一个方法，咱们几乎都会去运行一遍测试用例，确保没有影响到其余模块的正常运行，因此咱们要尽可能让你的测试方法“快！”，移除一些和单元测试无关的代码。固然，前提仍是要保证测试的完整性与正确性。

6. 每次运行单元测试时，请确保100%运行成功！

这个相对来讲比较简单，可是作起来是比较难的，由于可能会有多种缘由致使你的测试用例失败，好比：数据过时、方法内部逻辑改变等。

这些可能会花费你的一些时间去修改，你每每可能不肯意，不过既然作了一件事，就作好一件事呗

可是若是你不注意这些小错误，这可能就会致使你的一个大流程失败，你们应该知道，咱们在运行一个流程时每每一个小小的错误就致使流程整理失败！

7. 设计好你的测试

这包含的方面就比较广了，下面几个方面我认为你们应该注意的：

• 前面所说的代码在保证质量的前提下尽可能简洁
• 单元测试中代码的抽象也是能够有的，咱们也能够将一些可重用的代码抽象出来，提升代码的重用性和减小代码的重复。
• 给测试类测试方法起一个好名字。测试类通常是“类名+Test后缀”，能够表示对哪一个类进行的测试。测试方法也是相似，“测试方法名+Test后缀”或者对一个方法的部分测试“测试方法名+测试部分做用+Test后缀”。
• 每一个测试方法对被测试方法的功能断言不宜过多，若是一个方法须要多个断言进行测试，咱们能够进行大体分类，将其分不到两个测试方法中，这样能够细粒度的进行测试。

8. 注意测试代码覆盖率

一个设计好的单元测试，其代码测试覆盖率也是很高的，并不要求100% 的测试代码覆盖率，可是高覆盖率的代码包含未检测到的错误的概率要低，由于其更多的源代码在测试过程当中被执行。

注意：高代码覆盖不能保证测试是完美的，因此要当心！

9. 还有就是一些其余的注意点了，好比

• 不要使用print语句去输出测试结果人工判断是否正确，要使用断言
• 一些很差理解的测试最好在方法上面写明注释，便于后期理解与维护
• 使用框架进行单元测试，好比Junit5若是其中的断言支持不知足你的需求也可使用ASsertJ框架来丰富断言，Mockito进行Mock数据等

好了，上述就是对如何写好单元测试的一些建议，若有不当，请在评论区中指出，感激涕零！

接下来，我会写一些关于单元测试如何搭建、junit5相关新语法、基于图数据库的单元测试等
欢迎关注博主和 公众号[匠心Java]，一块儿讨论~

refer:博客 博客 官网