为鼓励单元测试，特分门别类示例各种组件的测试代码并进行解说，供开发人员参考。

本文中的测试均基于JUnit5。

单元测试实战（一）Controller 的测试

单元测试实战（二）Service 的测试    

单元测试实战（三）JPA 的测试    

单元测试实战（四）MyBatis-Plus 的测试

单元测试实战（五）普通类的测试

​​​​​​​单元测试实战（六）其它

其它测试注解

除了我们示例中用到的@WebMvcTest、@DataJpaTest、@MyBatisPlusTest等之外，Spring还有若干针对性的测试注解，如：

• Controller层：@WebFluxTest、@GraphQlTest
• 数据层：@DataRedisTest、@DataMongoTest、@DataElasticSearchTest、@DataLdapTest……

当然还有通用的@SpringBootTest。但@SpringBootTest太通用，它会拉起整个ApplicationContext，而其它有针对性的注解则是拉起裁剪过的ApplicationContext，因此有人认为@SpringBootTest更适合集成测试。

单元、集成、系统测试的分工

由此引出一个测试分工的问题。即，单元测试、集成测试、系统测试是否有清晰的边界。其实，只要把握一个原则就行了：随着测试粒度的增大，Mock/Spy逐渐减少，真实组件逐渐增多。单元测试一般是针对单个组件（类）的测试，因此它的依赖一般都需要Mock出来（除了测试数据），所以有“无Mock、不单测”的说法；集成测试则是针对完成一定功能的一组组件的测试，这一组组件都应该是真实的，它们的外部依赖则被Mock出来；而系统测试已经没有Mock/Spy，全部是真实组件了（当然，可以Mock外部接口）。

打桩率

同时请注意，如果测试一个类（乃至一个方法）需要打的桩（即Mock/Spy）太多，说明它的依赖太多，这个组件很可能违反了单一职责原则，要考虑重构。

测试数据的准备

前面的一些示例中，测试数据（业务实体）是作为测试类属性new出来的；有时同样一组数据在好几个测试类里都有，没有统一管理。更好的办法是将它们归集在一个管理组件里，且不一定写死，可以使用cvs文件或SQL文件（如MyBatis Plus的测试示例）；JUnit5有很强的数据驱动能力。

测试衡量指标（覆盖率与Assertion）

通常，单元测试的指标是代码覆盖率。但我们都知道单纯地统计覆盖率意义不大，因为1）覆盖了的代码是否是主要业务代码？2）有覆盖、无验证（或曰断言，Assertion），等于什么也没有。

覆盖率分为行覆盖率、分支覆盖率、路径覆盖率和变异覆盖率。大多数团队都是从行、分支做起。路径覆盖较难，一般不会要求。

变异（mutation）覆盖率就是解决上面说的Assertion问题的。就是说，如果代码行为改变，测试是否会失败，如果没失败，就说明没有Assert或Assert不够。

就测试而言（不止单元测试），最重要的有两条：一要盖，二要验。盖就是覆盖，就是要有测试，测试要覆盖最重要的那些分支；验就是检查，Assertion。脱离Assertion的数量和质量，空谈测试覆盖率是毫无意义的。

自动生成工具

有些工具可以生成测试代码框架，然后我们再往里补内容，IDEA就自带；另外它还有个插件叫Squaretest，更强大，但只有30天免费。如今大模型在这方面做的都不错，国内能直接使用的有阿里的“通义灵码”。更多工具见这里。

工具只起辅助作用，测试的有效性最终还要靠人来保障。

不测什么

无论单元测试还是集成测试，都无需去测三方的组件。比如用到了Spring提供的某个组件，它自己是有测试的，不要专门去给它写测试。

单纯的CRUD，没有自写SQL、没有业务逻辑的，测的必要性也不大；我们的示例中有这种测试，主要还是为了示例。

更多参考资料

从爬行到奔跑 - 我们为什么需要单元测试？（阿里）

Java单元测试实战（阿里）

单元测试的五个关键问题（阿里）

Spring boot Mybatis-Plus数据库单测实战