本文是笔者自己对单元测试的理解，由于刚入行，可能理解不深，希望读者发现错误可以帮忙指出，谢谢。
单元测试是为了测试代码的最小单元而存在的测试。怎样的单元算是最小单元则由程序员自己决定。在面向对象语言中，最小单元往往是一个 (public) method。当然，有些人也会把整个类当成最小单元。不过说到底，单元测试是越简单越好的。如果一个单元测试很复杂，那么它很可能是一个集成测试。当然，为了每个单元测试都足够简单，一般期望每一个 public 方法所做的事情也尽量简单，这样也有利于代码的复用。
起初，我对单元测试感到疑惑：明明都有集成测试了，为什么还需要编写单元测试？通过后期对系统的维护，我感受到了单元测试的几个优点：
- 帮助程序员更好地理解需求：每次编写单元测试时，我刚好能对代码做一次 review，同时可以再理一遍思路，查看是否符合需求。整个过程有点像是小黄鸭调试法。
- 提升代码的质量：如果单元测试难以编写，一般说明代码在编写层次上存在缺陷，需要进行调整甚至重构。
- 提供代码级别的文档：对于未接触过当前应用的人来说，他们可以通过单元测试代码来了解应用的运行方式。
- 方便代码修改或者重构时的排错：当你对原本的代码进行修改的时候，良好的单元测试可以及时地告诉你哪些修改会影响到原本的逻辑。
下面的表格列出了不同的功能使用这三个框架时分别需要使用哪些注解：
从常用功能上来看，三者实际上都足够开发使用。但是从以来引进的便携度来说，TestNG 更加方便，引入一个包就包含了测试结果报告生产的功能，而 Junit 则需要额外引入生产报告的扩展。在提供的断言工具类中，TestNG 的 assertEquals(actual, expected) 相比 Junit 的 isEquals(expected, actual) 更符合我的习惯，因此我使用 TestNG 来写本篇教程。
首先，引入 TestNG 的依赖。由于我使用的是 gradle，因此只写了 gradle 的配置方式，maven 的方式可以参考 Maven Surefire Plugin-Using TestNG
简单编写一个工具类并测试
编写完代码之后，执行 执行测试，执行完毕之后可以在 build/reports/ 目录下找到单元测试报告。
实际业务中编写单元测试会更加复杂，因为每一个方法都可能依赖几个其他模块，为了防止其他模块影响自己模块的单元测试，我们就需要 stub，在 Java 中，一般使用 Mockito 框架来提供这种能力。
使用示例
由于 mockito 现在已经支持 mock 静态方法和构造器(since 3.5.0)，powermock 使用场景变少。如果需要 mock private 方法，则可以考虑使用 powermock。或者当你使用低版本的 mockito 时想要 mock 静态方法和构造器，也可以使用，但是使用起来更为麻烦。
引入 powermock 依赖，注意，需要将 mockito-inline 依赖更改为 mockito-core
更新单元测试基类
使用 powermock 来 mock 静态对象
版权声明：
本文来源网络，所有图片文章版权属于原作者，如有侵权，联系删除。
本文网址：https://www.bianchenghao6.com/java-jiao-cheng/10759.html