什么是单元测试？为什么要做？(1)，2024年最新看这篇文章就行了-CSDN博客

本文链接：https://blog.csdn.net/2401_83946261/article/details/137604091

单元测试和集成测试的界线我相信大部分开发也是不清晰的。个人理解单元测试针对于一块业务逻辑最小的单元，太抽象。物理上可以简单理解为一个类的方法，可以是public方法也可以是private方法。一个单元测试不应该包含外部依赖的逻辑，反之就是集成测试了。

问题的核心就在于此。

一个service的一个接口实现可能依赖很多第三方：

1.本地其它的service

2.dao调用

3.rpc调用

4.微服务调用。

如下图：

(图二)

也就是说你的单元测试，真正调用了外部依赖那就是集成测试。这其实很常见对不？我们先说这种情况下如何集成测试。

Local Integration Test

本地集成测试也就是说不依赖与其他进程。包括：service依赖其他本地service或者dao的情况。在讲述如何集成测试之前，我们先理一下测试模型，测试主要包含三块内容：1.数据准备 2.执行逻辑 3.输出验证。

第一步：数据准备

在本地集成测试里，数据来源基本上来自于dao，dao来自于sql。也就是在执行一个case之前，执行一些sql脚本，数据库则使用h2这类memory database，切记不要依赖公司测试环境的db。

下图是使用spring-test框架的一个case，可以在case执行之前准备我们所需要的各种数据，另外在执行完case之后，执行clean.sql脚本来清理脏数据。这里也说明一个case的执行环境是完全独立的，case之间互不干扰，这很重要。

(图三)

第二步：执行逻辑最简单，就是调用一下我们测试的方法即可

第三步：验证

集成测试一般是调用service，或者dao的接口验证。

举个例子：CRUD操作的集成测试

调用C接口
调用R接口，验证C成功
调用U接口
调用R接口，验证U成功
调用D接口
调用R接口，验证D成功

Remote Integration Test

假设我们一个service实现依赖某个RPC Service

第一步：数据准备

跑到别人家的数据库插几条数据？或者跟PRC Service的Owner商量好，搭一个测试环境供我们测试？有些公司还真有专门的自动化测试环境，那么即使有测试环境，那如何实现各种case场景下，第三方Service很配合的返回数据给我们？想想都蛋疼。

第二步：执行方法

假设我们成功的解决了第一步中的问题，皆大欢喜。现在来看第二步，假设我们的service里面调用了另一个RPC Service创建了很多数据，跑了无数次case，结果…RPC Service对应的数据库都是我们的脏数据，如何清理？而且他们敢随便删数据吗？想想也蛋疼。

第三步：输出验证

假设我们又愉快的解决了第二步中的问题。现在来看第三步，假设我们的方法执行最终输出是创建了一个订单，订单当然是调用订单Service接口了，那么我们如何验证订单是否成功创建了呢？或许可以调用订单Service查询订单的接口来验证。很明显大多数情况下并没有这么完美。想想也蛋疼呀。通过以上分析，Local Integration Test是可行的，Remote Integration Test基本不可行。那么有没有什么办法解决呢？答案就是Mock

第一步：Mock RPC Service 想返回什么数据就返回什么数据
第二步：还是Mock接口，想调用几次就调用几次
第三步：这一步等到下面讲完单元测试就明白了

Unit Test

上面我们谈到Mock可以解决外部依赖的问题，现在有很多Mock的开源框架比如：mockito。那么问题来了，既然我们可以mock第三方远程依赖，为何不mock dao、local service呢？没错外部依赖全部mock掉，就是单元测试了。因为我们只关心所测试的方法的业务逻辑，也就是真正高内聚的逻辑单元了。如下图：

(图四)