单元测试 代码里面都绝对路径怎么处理_浅谈单元测试

参加工作的第一个功能要上线了。第一次得知，在上线之前，需要对代码进行质量构建。其中，单元测试的覆盖率就是一项十分重要的指标。

接下来，将从单元测试的含义、单元测试的作用、常见的单元测试框架、以及单元测试的评价标准这四个方面来说明。

单元测试是什么？

测试的是一个小的单元

单元测试，顾名思义，它测试的是一个小”单元”，这个”单元”一般是类或方法，而不是模块或者系统。单元测试一般都是由开发工程师来完成的，是代码层面的测试，用于测试“自己”编写的代码的正确性。

不依赖于任何不可控组建

单元测试不依赖于任何不可控的组件，如果代码中依赖了其他这些不可控的组件，比如复杂外部系统，复杂模块或类，则需要通过 mock 的方式，将这些不可控的部分变成可控。

单元测试的意义

在你写完一个功能代码之后，怎么保证你的代码运行正确？在各种异常（数据异常、输入异常、调用异常等）情况下，程序运行结果都符合你预先设计的预期，返回合适的报错呢？这个时候，单元测试就派上了用场。

1. 发现很多考虑不全面的地方

从我个人写单元测试的经验来看，在写单元测试的时候，几乎每次都会发现很多考虑不全面的地方，都会发现很多”bug“。设计完备的单元测试用例，非常有助于扫清代码中的各种低级的 bug。所以，我一直觉得，提高代码质量，最有效的手段，就是写好单元测试。Google 中有很多项目是完全没有测试团队参与的。代码的正确性完全靠开发团队来保障，线上 bug 反倒是非常少。

2. 自我 code review 的过程

写单元测试的过程本身就是一个自我 code review 的过程。在这个过程中，你可以发现一些设计上的问题，比如代码设计的不可测试，代码的可读性不好等等。

3. 增强你对代码的信心

写单元测试还能增强你对代码的信心。等你写好完备的单元测试，并且代码通过所有的测试用例的时候，你对自己写的代码也会信心大增。这种一切尽在掌握中的感觉是很好的：）如果你好好写过单元测试，那在这一点上，应该能跟我有所共鸣吧。

4. 单元测试还对重构代码有帮助

除此之外，单元测试还对重构代码也有很大帮助。当你发现某个类或者函数实现的不好，你想要重构一下，但又怕考虑不全面，改了之后会出错，出力不讨好，这个时候该怎么办呢？如果有单元测试情况就不一样了。代码重构完之后，你跑一下原来的单元测试。如果单元测试都通过，那基本上可以保证，你的重构没有破坏正确性。不过，这个的前提是，之前写的单元测试质量很好，覆盖率很高。

JAVA中常用的单元测试工具

Junit5

https://junit.org/junit5/

junit是老牌测试框架了，也是目前引用最广泛的一个框架。当前已经更新到Junit5，功能更强大。

asserts

https://assertj.github.io/doc/

一个功能强悍的断言工具，支持各种断言方式

Mockito

https://site.mockito.org/

一个单元测试中的Mock工具，可以很灵活的创建对象，配合单元测试。

在我们项目中，使用的是Mockito来实现单元测试的编写的。

单元测试的评价标准-覆盖率

定义

代码覆盖（英语：Code coverage）是软件测试中的一种度量，描述程序中源代码被测试的比例和程度，所得比例称为代码覆盖率。

意义

1. 分析未覆盖部分的代码，从而反推在前期测试设计是否充分，没有覆盖到的代码是否是测试设计的盲点，为什么没有考虑到？需求/设计不够清晰，测试设计的理解有误，工程方法应用后的造成的策略性放弃等等，之后进行补充测试用例设计。
2. 检测出程序中的废代码，可以逆向反推在代码设计中思维混乱点，提醒设计/开发人员理清代码逻辑关系，提升代码质量。
3. 代码覆盖率高不能说明代码质量高，但是反过来看，代码覆盖率低，代码质量不会高到哪里去。覆盖率可以作为测试自我审视的重要工具之一。

本文参考链接

• 单元测试的定义
• 单元测试的常用方法