前言：
现在大公司越来越重视项目的单元测试，甚至明确要求项目的单元测试覆盖率不能低于某个值，足可见单元测试的重要性；
试想如果没有单元测试，那么如何保证代码能够正常运行呢？
测试人员做的只是业务上的集成测试，也就是黑盒测试，对单个的方法是没有办法测试的，而且，测试出的 bug 的范围也会很广，根本不能确定 bug 的范围，还得去花时间来确定 bug 出在什么地方。
另外，一个最常见的问题：写单测浪费时间？ 你有没有计算过你改bug的时间（定位+修复），算一下的话你会发现时间浪费的会更多。
建议：
关于如何写好单元测试，下面有几条建议供大家参考：
- 测试数据外部化
测试数据大致分为两种：变化的和不变化的，对于不变的测试数据，我们完全可以写在单元测试用例代码中，也可以将数据外部化。
而对于测试数据一直在变，并且测试数据量比较大的时候可以使用测试数据外部化将数据放在测试用例的外部进行统一管理。
什么是数据外部化？就是将数据放在单元测试用例的外部统一管理，比如我们可以将一个单元测试用例中的测试数据统一放在一个CSV文件中。
我们就可以通过比如junit5中的参数测试注解@ParameterizedTest和引入CVS文件的注解@CsvFileSource并指定其中的resources属性指定CSV文件，numLinesToSkip = n 属性指定从第n+1行开始。这样就可以通过一个CSV文件统一管理一个单元测试用例中的数据。
我们管理测试用例中所需要的数据就只需要管理一个个CSV文件即可。
下面可以看一个案例：（其中具体的使用方法请看博客junit5系列-参数化测试）
在这里插入图片描述
其中，two-column.csv文件内容
在这里插入图片描述
- 构建具有特定结果的测试
如果方法结果具有随机性，这样的方法几乎无法测试，所以我们针对这种方法便没有办法去进行测试。
我们只能对根据特有数据得到特定结果的方法进行测试。
- 测试方面全面，设计的每一方面必须有一个测试用例：
正面所有情景
负面所有情景
临界值
特殊值
4.测试用例请尽量简洁、简短
在能完成测试的基础上尽量简洁代码，这样不仅使代码更加好看，还好维护好理解。 想想一大堆代码和几行代码你更想看哪个？
- 测试用例尽量快
对于单元测试用例我们几乎每开发完一个方法或者修改完一个方法，我们几乎都会去运行一遍测试用例，确保没有影响到其他模块的正常运行，所以我们要尽量让你的测试方法“快！”，移除一些和单元测试无关的代码。当然，前提还是要保证测试的完整性与正确性。
- 每次运行单元测试时，请确保100%运行成功！
这个相对来说比较简单，但是做起来是比较难的，因为可能会有多种原因导致你的测试用例失败，比如：数据过期、方法内部逻辑改变等。
这些可能会花费你的一些时间去修改，你往往可能不愿意，不过既然做了一件事，就做好一件事呗
但是如果你不注意这些小错误，这可能就会导致你的一个大流程失败，大家应该知道，我们在运行一个流程时往往一个小小的错误就导致流程整理失败！
- 设计好你的测试
这包含的方面就比较广了，下面几个方面我认为大家应该注意的：
前面所说的代码在保证质量的前提下尽量简洁。
单元测试中代码的抽象也是可以有的，我们也可以将一些可重用的代码抽象出来，提高代码的重用性和减少代码的重复。
给测试类测试方法起一个好名字。测试类一般是“类名+Test后缀”，可以表示对哪个类进行的测试。测试方法也是类似，“测试方法名+Test后缀”或者对一个方法的部分测试“测试方法名+测试部分作用+Test后缀”。
每个测试方法对被测试方法的功能断言不宜过多，如果一个方法需要多个断言进行测试，我们可以进行大致分类，将其分不到两个测试方法中，这样可以细粒度的进行测试。
8.注意测试代码覆盖率
一个设计好的单元测试，其代码测试覆盖率也是很高的，并不要求100% 的测试代码覆盖率，但是高覆盖率的代码包含未检测到的错误的几率要低，因为其更多的源代码在测试过程中被执行。
注意：高代码覆盖不能保证测试是完美的，所以要小心！
- 还有就是一些其他的注意点了，比如
不要使用print语句去输出测试结果人工判断是否正确，要使用断言
一些不好理解的测试最好在方法上面写明注释，便于后期理解与维护
使用框架进行单元测试，比如Junit5如果其中的断言支持不满足你的需求也可以使用ASsertJ框架来丰富断言，Mockito进行Mock数据等
好了，上述就是对如何写好单元测试的一些建议，如有不当，请在评论区中指出，感激不尽！
写在最后：
忙的时候虽然累，但是忙完了会特别畅快舒服；闲的时候虽然爽，但是闲的时间长了心就慌了。你迷茫的原因往往只有一个，那就是在本该拼命去努力的年纪，想得太多，做得太少。
所以朋友们确定目标，不忘初心，勇往直前，相信最后一定可以开出一朵属于自己的花儿来，加油。