测试覆盖范围

如下图所示，SaaS 的服务端程序可以抽象为下面两种运行模式：

- 处理请求：通过暴露 HTTP 接口向外提供服务的后台程序都属于这种模式。
- 响应事件：不会向外暴露接口，可能是一个独立的进程，拥有自己的运行循环。
![](https://static.cloudcare.cn/cloudcare-mrdoc/img/2024-07-15_153805_5374100.027563561803848446.png)

对于处理请求的场景，通常我们会使用第三方框架(Django、DRF、Tastypie)来向外暴露接口，但是接口最终调用的是我们系统内部的领域逻辑，所以我们测试所需要覆盖的则是接口之下的这些领域逻辑、模型以及工具。

对于响应事件的场景，大多数情况下是系统内部的模块在进行交互，这些模块都要被单元测试覆盖到。

**总而言之，在系统内部模块划分合理，层次结构清晰的情况下，我们需要覆盖到接口层之下的所有模块。**

### 1 覆盖范围的选择

对于一个向外暴露 HTTP 接口的后台服务程序，我们在处理外部到来的请求时一般流程如下：

![](https://static.cloudcare.cn/cloudcare-mrdoc/img/2024-07-15_153817_0422180.22037460906557615.png)

- middleware：请求可能会经过我们设置的中间件进行一些处理
- read inputs：读取请求中的输入数据
- business logic：系统根据请求中的数据执行特定的业务逻辑
- write outputs：将返回数据写入响应中
- middleware：响应可能会经过我们设置的中间件进行一些处理

在这个流程中，read inputs 及 write outputs 是我们在接口层对请求和响应进行处理的逻辑，可以不在单元测试中进行覆盖；而其他三个过程一般由系统中定义的领域逻辑、模型以及工具负责，所以我们的单元测试必须覆盖到这些过程中所使用的模块。

### 2 实例

#### 2.1 响应请求

![](https://static.cloudcare.cn/cloudcare-mrdoc/img/2024-07-15_153832_7885230.22457594898133615.png)

#### 2.2 响应事件

![](https://static.cloudcare.cn/cloudcare-mrdoc/img/2024-07-15_153839_9526260.8136210067088445.png)