Supertest实战指南：Node.js接口测试与自动化回归测试-育师

1. 为什么选Supertest：它在Node测试生态里的位置

做Node后端开发的朋友，十有八九都遇到过这样的场景：接口写完了，curl手动敲了几次，看着返回的JSON没问题，就直接提交了。结果上线第二天，线上报了个500，一查发现是某个边界参数没处理，而那个参数恰好是curl的时候没测到的。这种问题的根源不在于代码写得不好，而在于接口缺少一套自动化的回归保护。

Supertest就是用来解决这个问题的。它是一个Node.js的HTTP接口测试库，核心作用是在测试代码里直接发起真实的HTTP请求，然后对响应状态码、响应头、响应体做断言。它不需要真正把服务部署起来，也不需要监听端口，你只需要把Express、Koa或者原生http的app实例丢给它，它内部会帮你把这个app启动在一个临时端口上，然后发起请求。

我在项目里用Supertest已经三年多了，从最早的Express 4时代一直到现在的Express 5和Fastify混合架构，它一直稳稳地在我的测试金字塔里占据“接口集成测试”这一层。对比一下另外两种测试方式，你就知道它的价值在哪了：

单元测试（比如用Jest直接调用一个函数）：测的是逻辑片段，根本不知道路由能不能通、参数绑定对不对、中间件顺序有没有坑。
端到端测试（比如Playwright去点页面）：覆盖最全，但速度慢、环境依赖重，不可能每个接口都这样测。
Supertest恰好是中间地带：直接绕过浏览器，用HTTP协议跟你的应用对话，速度接近单元测试，覆盖范围却接近端到端。

如果你是一个Node后端开发者、或者正在搭建内部测试体系的前端团队，这篇内容值得你花十分钟看完。我会把Supertest的核心机制、常用API、高级玩法以及我在实际项目里踩过的坑一次性讲清楚。

1.1 Supertest的底层原理：它不是mock，是一次真实HTTP请求

很多人第一次用Supertest会误以为它像nock那样把请求拦截下来、然后返回伪造的响应。其实不是。Supertest做的事情非常朴素：你把app传进去，它用app.listen(0)在随机端口上起一个HTTP服务，然后把测试里的请求真正发到这个服务上。

这意味着你的路由、中间件、错误处理逻辑、参数解析、Session机制都是真实执行的。这比mock响应要可靠得多，因为你测的是“整个链路”，而不是“某个环节”。

示例：

const request = require('supertest'); const app = require('../app'); // 你导出的Express实例 describe('GET /api/users', () => { it('应该返回用户列表', async () => { const res = await request(app) .get('/api/users') .expect(200) .expect('Content-Type', /json/); expect(res.body).toHaveProperty('data'); }); });

就这么几行代码，你的应用会真实收到一个GET请求，真实执行业务逻辑，真实返回响应。如果路由没写对，如果中间件抛异常了，如果返回格式不是JSON，测试就会失败。

1.2 Supertest与测试框架的关系：它不取代Jest，它是Jest的得力拍档

Supertest不是测试框架，它的定位非常纯粹：只负责“发请求、验证响应”。测试用例的组织、断言库的写法、覆盖率报告，这些活它都不管，也管不了。所以你需要配合Jest、Mocha这类测试框架来用。

我这里用Jest示例，因为Jest的断言风格更现代、内置覆盖率工具、并行执行支持也更好。在Jest里，Supertest的用法就是await request(app).get('/xxx')，配合Jest的expect()，语法非常顺滑。把Supertest和Jest结合使用，能做到“测试代码像在写业务代码一样自然”。

2. 核心API上手：从一段最基础的测试说起

Supertest的API看起来不多，但每一个API背后都有它的设计逻辑。不理解这些逻辑，写出来的测试可能过不了、或者漏掉重要的验证点。我按“发请求—加参数—做断言—结束”这条链路来拆解。

2.1 request()函数：从app到HTTP请求实例

request(app)是Supertest的入口。它接收的参数类型很灵活：

Express/Koa/Fastify的app实例
原生http.createServer()返回的server实例
一个监听在某个端口的URL字符串，比如request('https://example.com')

其实这里藏着一个关键区别。如果你传入的是app实例，Supertest会临时启动一个HTTP server，测试结束之后默认关闭；但如果你传入的是一个URL字符串，它会直接向那个地址发请求，不会启动本地server，此时你需要自己保证目标服务是启动状态。

提示：日常开发接口测试时，永远把app实例传给Supertest，不要传URL。传URL意味着你依赖一个外部环境，测试的稳定性就大打折扣了。

2.2 链式调用与HTTP动词方法

Supertest的优雅之处在于它的链式调用语法，读起来就像在念一句自然的英文句子：发起一个请求、设置一下头部、提交一段数据、然后期望得到什么样的响应。

const res = await request(app) .post('/api/v1/orders') .set('Authorization', `Bearer ${token}`) .send({ productId: 'p_1024', quantity: 2 }) .expect(201);

链上的每个环节都有对应的方法：

.get(path)、.post(path)、.put(path)、.delete(path)、.patch(path)：发起对应HTTP动词的请求。
.set(field, value)：设置请求头，比如Content-Type、Authorization、User-Agent。
.send(payload)：发送请求体，可以是对象、字符串或Buffer。传对象时Supertest会自动帮你JSON序列化，并设置Content-Type: application/json。
.query(obj)：拼查询参数，等价于在URL后面手动加?key=value&key2=value2。
.expect(status)/.expect(field, value)/.expect(body)：断言响应。
.end(callback)：结束链式调用，执行回调函数。

2.3 expect断言的几种形态

.expect()是Supertest最强也是最多人用错的API。它一共支持三种形态，每种适用场景不一样。

第一种，expect(status)，直接断言HTTP状态码：

await request(app).get('/api/ping').expect(200);

第二种，expect(field, value)，断言响应头：

await request(app) .get('/api/users') .expect('Content-Type', /json/);

注意这里的第二个参数支持正则表达式。因为Content-Type可能带字符集，比如application/json; charset=utf-8，如果你写死'application/json'反而会匹配失败。用正则/json/可以避免这种脆弱断言。

第三种，expect(body)，断言响应体。这个形态最丰富，支持字符串、对象、正则、函数。

// 精确匹配对象（需要响应体完全一致） await request(app).get('/api/ping').expect({ pong: true }); // 正则匹配字符串 await request(app).get('/api/home').expect(/欢迎访问/); // 函数自定义验证（最灵活） await request(app).get('/api/users').expect((res) => { if (!res.body.data || !Array.isArray(res.body.data)) { throw new Error('响应缺少 data 数组'); } });

2.4 agent机制：保持会话状态的“隐形口袋”

写业务接口测试时，最烦的就是登录态。几十个接口都要带token，每个请求都手动塞header，代码冗余又容易漏。Supertest提供了一个叫agent的东西，它本质上是一个“会记住状态的请求客户端”。

const agent = request.agent(app); // 先登录，agent会自动保存set-cookie await agent.post('/api/login').send({ username: 'admin', password: '123456' }); // 之后的请求自动携带cookie，无需手动处理 await agent.get('/api/profile').expect(200);

这个机制在测试session-based登录时简直救命。它内部维护了一个cookie jar，登录接口返回的Set-Cookie会被自动保存和带上。如果你的登录方案是JWT而不是cookie，那agent就帮不上忙了，你得自己把token存在变量里，然后手动set('Authorization', ...)。

实操建议：在有“登录—业务请求”多步骤流程的测试里，优先用agent。它不只能保持cookie，还能保持请求头、超时配置等请求级别的设置，能让测试代码明显更干净。

2.5 异步与await：Supertest的Promise化

早期版本的Supertest是纯回调风格的，必须手动传.end(callback)。从v3开始，Supertest支持Promise，在.expect()之后可以直接await，这让代码的阅读性和可维护性提升了一个档次。

// 回调风格（老代码常见） request(app) .get('/api/ping') .expect(200) .end((err, res) => { if (err) return done(err); done(); }); // async/await风格（推荐） const res = await request(app).get('/api/ping').expect(200);

需要提醒的是：如果你用了.end(callback)回调风格，就不要再await同一个请求了，否则end回调可能会被调用两次，测试会变得非常诡异。.end(callback)和Promise风格只能二选一。

2.6 测试文件的准备与清理：before和after钩子

接口测试不是单纯地“发请求、看响应”，它往往涉及数据库、缓存、文件等外部依赖。所以围绕请求的“准备—清理”逻辑非常关键。我通常在测试文件里这样组织：

const request = require('supertest'); const app = require('../app'); const db = require('../db'); beforeAll(async () => { await db.connect(process.env.TEST_DATABASE_URL); await db.migrate.latest(); }); afterAll(async () => { await db.destroy(); }); beforeEach(async () => { await db('users').del(); await db('orders').del(); }); describe('用户模块接口测试', () => { it('GET /api/users 返回空列表', async () => { const res = await request(app).get('/api/users').expect(200); expect(res.body.data).toEqual([]); }); });

这套模式的思路是：每次测试之前把表清空，让每个用例都从干净的基线开始跑，避免数据残留造成的“假失败”。数据库连接用beforeAll建立、afterAll关闭，避免内存泄漏和句柄残留导致Jest进程不退出。

3. 把Supertest用进项目：一套可复用的接口测试体系

单独写几个测试文件简单，但要形成一套能长期维护、多人协作的接口测试体系，有几个设计决策值得好好想想。我这里完整复盘一下我在实际项目中落地Supertest的整套方案。

3.1 项目结构设计：按模块分目录，不按类型堆文件

很多团队写测试喜欢建一个test/文件夹，然后把所有测试文件都丢进去。一开始没问题，但接口数量一旦上到200个，找文件就会让人崩溃。我更推荐按业务模块组织测试，让测试结构和源码结构一一对应。

. ├── src/ │ ├── modules/ │ │ ├── auth/ │ │ │ ├── auth.controller.js │ │ │ ├── auth.service.js │ │ │ ├── auth.router.js │ │ │ └── __tests__/ │ │ │ └── auth.api.test.js │ │ └── order/ │ │ ├── order.controller.js │ │ ├── order.service.js │ │ ├── order.router.js │ │ └── __tests__/ │ │ ├── order.api.test.js │ │ └── order.service.test.js │ └── app.js ├── jest.config.js └── package.json

3.2 全局基础配置：Jest环境与超时设置

接口测试比单元测试慢，需要更长的超时时间，同时要处理测试中启动的HTTP server和数据库连接。Jest默认的5秒超时往往不够。我在jest.config.js里做如下配置：

module.exports = { testEnvironment: 'node', testMatch: ['**/__tests__/**/*.test.js'], setupFilesAfterEnv: ['./tests/setup.js'], testTimeout: 15000, maxConcurrency: 4, forceExit: false, detectOpenHandles: true };

几个关键点解释一下：

detectOpenHandles: true：帮你在测试结束时找出未关闭的资源（比如数据库连接、HTTP server），这在排查“测试跑完但不退出”时极其有用。
forceExit: false：不要开这个选项，它会在测试还没跑完时强制杀掉进程，掩盖真正的问题。
maxConcurrency: 4：给并发测试设一个上限，避免同时开几十个HTTP server把本机端口和内存打爆。

3.3 共享工具函数：把重复动作包起来

接口测试里最常重复的动作就是“登录并获取token”。我把它抽成一个工具函数，避免每个测试文件都写一遍JWT获取逻辑：

// tests/helpers/auth.js const request = require('supertest'); const app = require('../../src/app'); async function getToken(overrides = {}) { const user = { username: 'test_user', password: 'test_pass', ...overrides }; const res = await request(app) .post('/api/auth/login') .send(user) .expect(200); return res.body.token; } module.exports = { getToken };

然后测试文件里就清爽多了：

const { getToken } = require('../helpers/auth'); it('创建订单需要token', async () => { const token = await getToken(); await request(app) .post('/api/orders') .set('Authorization', `Bearer ${token}`) .send({ productId: 'p_1024' }) .expect(201); });

3.4 用环境变量区分测试数据库

接口测试最常见的坑是“误连生产库”。虽然听起来很蠢，但真的发生过——因为测试环境的数据库URL写在了代码里，而不是环境变量里。我习惯在tests/setup.js里强制设置测试数据库环境变量，并且写一个启动检查，绝不让测试库和生产库混用：

// tests/setup.js const path = require('path'); // 强制加载测试环境配置 process.env.NODE_ENV = 'test'; process.env.PORT = '0'; process.env.DATABASE_URL = process.env.TEST_DATABASE_URL || 'postgres://localhost/myapp_test';

然后在数据库连接模块里加一个保护：

// src/db.js if (process.env.NODE_ENV === 'test' && !process.env.DATABASE_URL.includes('_test')) { throw new Error('测试环境禁止连接非测试数据库'); }

这样万一哪天有人不小心把环境变量配错了，测试会在启动时就失败，而不是等到数据被污染了才追悔莫及。

3.5 Coverage：测得到底够不够

接口测试的覆盖率统计和单元测试略有不同，它关心的是“路由条目是否都被走到”。我用Jest内置的coverage再做一层补充：

npx jest --coverage --collectCoverageFrom='src/modules/**/*.js'

实际观察下来，接口测试的语句覆盖率很难做到100%，因为很多分支要依赖不同的用户角色、权限、外部服务状态才能触发。但只要关键路由的覆盖率达到80%以上，回归兜底的目的就达到了。如果一个路由长期没有被任何测试触碰，那它大概率是“裸奔”的。

4. 高级场景实战：文件上传、鉴权与并发测试

基础用法讲完了，下面进入真正“值钱”的部分。这些场景不是每个团队都会遇到，但一旦遇到，如果你没有提前熟悉Supertest的相应玩法，现场去查文档会非常浪费时间。我把文件上传、JWT鉴权、错误处理、并发测试这四个高频场景的完整代码写在这里。

4.1 文件上传测试：attach方法

Supertest最容易被忽视的一个方法是.attach()，它专门用来模拟multipart/form-data文件上传。我在做头像上传功能时，一开始不知道这个方法，是先用fs.readFileSync读文件、然后手动拼form-data，踩了很多坑之后才发现的。

正确用法：

const path = require('path'); const request = require('supertest'); const app = require('../app'); it('头像上传成功', async () => { const filePath = path.join(__dirname, 'fixtures/avatar.png'); const res = await request(app) .post('/api/user/avatar') .attach('avatar', filePath) .expect(200); expect(res.body).toHaveProperty('avatarUrl'); });

.attach(field, filePath)的第二个参数也可以传Buffer，比如在测试里动态生成一个小文件：

const fakeImage = Buffer.from('fake-image-content'); await request(app) .post('/api/user/avatar') .attach('avatar', fakeImage, 'avatar.png') .expect(200);

第三个参数是文件名。如果接口逻辑里会根据原始文件名做白名单校验，比如只允许.jpg/.png，你就必须指定一个带正确扩展名的文件名。

文件上传测试时，有几个细节容易踩坑。第一个是文件fixture体积不要太大，几KB就够了，否则测试会变慢；第二个是要注意接口是否会读取文件格式信息，如果只是假数据，某些用file-type库做校验的接口会直接拒绝；第三个是上传的临时文件要记得清理，有些框架（比如Multer）写入磁盘的临时文件不会自动删，跑多了会占满磁盘。

4.2 JWT鉴权流程测试：token过期与权限隔离

现代接口基本都用JWT做鉴权。Supertest测JWT接口的难点在于：你需要在测试里制造不同类型的token，包括有效token、过期token、权限不足的token。

我封装了一个token工厂：

// tests/helpers/tokenFactory.js const jwt = require('jsonwebtoken'); const config = require('../../src/config'); function validToken(payload = {}) { return jwt.sign({ uid: 'u_001', role: 'admin', ...payload }, config.jwtSecret, { expiresIn: '1h' }); } function expiredToken() { return jwt.sign({ uid: 'u_001', role: 'admin' }, config.jwtSecret, { expiresIn: '-1h' // 已经过期 }); } module.exports = { validToken, expiredToken };

然后在测试里：

it('携带过期token返回401', async () => { const token = expiredToken(); await request(app) .get('/api/users') .set('Authorization', `Bearer ${token}`) .expect(401); }); it('非管理员访问管理接口返回403', async () => { const token = validToken({ role: 'member' }); await request(app) .delete('/api/users/u_001') .set('Authorization', `Bearer ${token}`) .expect(403); });

这个写法的好处是：如果JWT的校验逻辑有变化（比如把过期判断从401改成403），测试会立刻红灯告诉你“契约变了”，逼着团队去讨论这是有意变更还是bug。

4.3 错误处理中间件测试：500和404的正确姿势

很多团队只测“正确路径”，从来不测错误路径。但恰恰是错误处理中间件写得对不对，决定了你的接口在生产环境里挂掉时，是返回一个友好的JSON错误，还是一坨HTML堆栈。

我用Supertest验证错误处理中间件的几个关键行为：

it('未匹配路由返回JSON 404', async () => { const res = await request(app).get('/api/this-route-does-not-exist').expect(404); expect(res.body).toHaveProperty('error.message'); }); it('未知异常进入500错误处理', async () => { const res = await request(app).get('/api/users').expect(500); expect(res.body.error.code).toBe('INTERNAL_ERROR'); });

错误路径的测试往往能提前暴露很多问题，比如错误处理中间件忘记设置Content-Type: application/json导致返回的是HTML，或者错误对象里带着敏感堆栈信息直接被返回给前端。这些坑，如果你不写测试，几乎不可能在开发期发现。

4.4 并发测试与数据隔离：避免脏数据互相干扰

Supertest是可以并发跑多个用例的，Jest默认也会在同一个文件里并行执行测试。但并发带来一个严重问题：如果两个用例同时往同一张表里插入数据，其中一个用例断言“列表长度为1”就会失败。

解决思路有两个方向。第一个方向是彻底隔离：每个用例都创建自己的测试数据，断言时只关心自己创建的那条数据是否存在，而不是断言“整个表只有一条”。第二个方向是串行化：对依赖共享数据的用例，用test.only或describe.only临时调整，或者在Jest配置里把maxConcurrency: 1。

从长远看，第一种思路更健康。我通常这样写：

it('用户详情应该展示自己的订单', async () => { const token = await getToken(); // 只创建属于当前测试用户的数据 const order = await createOrder(token, { productId: 'p_123' }); const res = await request(app) .get(`/api/orders/${order.id}`) .set('Authorization', `Bearer ${token}`) .expect(200); expect(res.body.data.id).toBe(order.id); });

每一个用例只依赖自己创建的数据，而不是全局共享状态。这样无论Jest怎么并发，都不会互相踩到脚。

5. 常见问题与排查技巧实录

用Supertest这几年，我被各种奇怪的问题折磨过。下面这些问题每一个都是我实际遇到过并且花了时间排查的，整理成速查表供参考。

5.1 测试跑完但进程不退出：检测未关闭的句柄

这是Supertest用户最常遇到的一个问题：Jest明明显示所有测试都通过了，但命令行一直卡着不退出，最后只能Ctrl+C强杀。我之前遇到过最典型的一个案例是：某个测试用例里用app.listen()启动了一个真实的HTTP server，但没有在测试结束后关闭它。Supertest自己管理的server会自动关，但你手动启动的这个server不会。

排查手段：

在jest.config.js里开启detectOpenHandles: true，Jest会在测试结束后列出未关闭的句柄。
检查是不是开了数据库连接没有关闭。很多ORM的连接池即使你调用destroy()也不会立刻释放所有连接，建议用afterAll统一收尾。
检查有没有定时器还在跑。比如代码里有个setInterval，测试结束时没被clear，进程也退不掉。

afterAll(async () => { await db.destroy(); // 关闭数据库连接池 server.close(); // 关闭手动启动的HTTP server });

5.2 数据库清空策略：每次测试前到底要不要删表

数据清理是接口测试里最棘手的问题，没有之一。我见过三种策略，各有优劣。

方案A：每个用例前清空所有表。好处是隔离性最好，坏处是如果表特别多、外键关系复杂，清理动作本身可能耗时数秒，测试会变慢。
方案B：只在关键表上清理。比如只清orders表和users表，其他字典表不清。好处是快，坏处是两个用例如果都依赖同一个字典数据，可能会出现“假失败”。
方案C：事务回滚。把每个用例包在数据库事务里，测试结束回滚，数据自动回到原位。这个方案最安全，但要求你的数据库连接和业务代码使用同一个事务上下文，很多项目做不到。

我目前用得最多的是方案A的改良版，只在beforeEach里清掉那些测试真正会写入的表：

const CLEAN_TABLES = ['orders', 'order_items', 'users']; beforeEach(async () => { for (const table of CLEAN_TABLES) { await db(table).del(); } });

用del()而不是truncate()，原因是有外键约束的时候，truncate往往报错，而delete不会。还有一个额外的好处：如果你用的是自增主键，delete不会重置自增序列，这样反而能暴露出某些“假设ID从1开始”的坏代码。

5.3 超时问题：长耗时接口的测试策略

有些接口处理特别慢（比如导出报表、批量发送邮件），默认超时时间不够用。这时候不要急着提高测试超时时间，而是要思考一个更本质的问题：你真的要在测试里等待这个慢接口完成吗？

我的建议是：把“发起任务”和“验证任务结果”分开测。对于异步任务接口，只验证“任务已接受”就够；任务真正执行的结果，可以单独测那个执行函数。

it('提交导出任务应该立即返回accepted', async () => { const res = await request(app) .post('/api/export') .send({ format: 'xlsx' }) .expect(202); // 202 Accepted，而不是200 expect(res.body.taskId).toBeDefined(); });

如果确实需要等待任务完成，可以用一个轮询帮助函数：

async function waitForTask(taskId, timeout = 10000) { const start = Date.now(); while (Date.now() - start < timeout) { const res = await request(app).get(`/api/tasks/${taskId}`).expect(200); if (res.body.status === 'completed') return res.body; await new Promise(r => setTimeout(r, 200)); } throw new Error(`任务 ${taskId} 在 ${timeout}ms 内未完成`); }

5.4 调试技巧：失败时打印完整请求与响应

Supertest的报错信息有时候非常隐晦，只有expected 200 got 500，但不知道请求体或者响应里到底有什么。这时候我的做法是：在断言之前先把响应体打印出来。

it('创建订单应该成功', async () => { const payload = { productId: 'p_1024', quantity: -1 }; const res = await request(app).post('/api/orders').send(payload); if (res.status !== 201) { console.error('响应内容:', JSON.stringify(res.body, null, 2)); } expect(res.status).toBe(201); });

或者更优雅一点，直接用.expect()的回调形式：

await request(app) .post('/api/orders') .send(payload) .expect((res) => { if (res.status !== 201) { throw new Error(`请求失败，响应体: ${JSON.stringify(res.body)}`); } });

还有一个实用技巧：在测试文件顶部设置process.env.DEBUG = 'supertest*'，可以打开Supertest的调试日志，它会打印每次请求的方法、路径、状态码和耗时。

5.5 Supertest与Superagent的关系澄清

用着用着你会发现Supertest有些方法的用法很眼熟，比如.set()、.send()、.query()。这是因为Supertest内部依赖了Superagent——一个Node端的HTTP客户端库。Supertest是“Superagent + app实例”的包装：它复用了Superagent的请求API，同时增加了expect()断言和app启动逻辑。

这个关系带来一个重要推论：Supertest的请求部分支持Superagent的所有功能，包括代理配置、超时设置、TLS选项等。所以如果你需要测试HTTPS接口或者需要走代理，可以在Supertest的请求链路上设置。

const request = require('supertest'); await request(app) .get('https://external-api.example.com') .timeout({ response: 5000, deadline: 10000 });

5.6 多环境并行测试的隔离问题

团队大了以后，单个测试套件可能不够用，需要分环境跑：CI上一份、本地一份、还可能有一个压测环境。这时候不同环境的数据库、Redis、消息队列都需要隔离，不然测试数据会互相串。

我的做法是用不同数据库名来区分环境，而代码里统一从环境变量读取连接信息：

# .env.test DATABASE_URL=postgres://localhost/myapp_test REDIS_URL=redis://localhost:6379/1 # .env.ci DATABASE_URL=postgres://ci-runner:randompass@ci-db:5432/myapp_ci REDIS_URL=redis://ci-redis:6379/1

然后配置脚本分别加载对应的环境变量文件，不依赖开发者的手工设置。

写在最后的几点参考

最后再分享几个我这几年的使用心得，不算什么高深理论，但都是踩过坑换来的。

第一，接口测试的核心价值不是测正确路径，而是测错误路径和边界条件。如果你新建的所有测试都在验证“正常请求能返回200”，那这套测试的兜底能力非常弱。花同样的时间，去测“参数缺失返回400”“未认证返回401”“无权限返回403”，这些都是真实生产环境最可能出问题的地方。

第二，不要在测试里依赖“全表只有一条数据”这样的隐含假设。写得越具体的断言，在将来改造时越脆弱。尽量断言“我创建的数据在响应里出现”，而不要断言“响应里没有别人创建的别的数据”。

第三，Supertest虽然好用，但别指望它解决所有测试问题。涉及浏览器渲染、前端交互流程的，还是得用浏览器级的端到端测试工具。把Supertest定位在“接口集成测试”这一层，它的性价比是最高的。

第四，测试代码和业务代码一样，需要持续重构。当你发现为了配合某个测试，得写特别多setup代码或者改业务代码才能让测试好写时，这是一个信号：要么测试的结构不对，要么业务接口设计有问题。不要硬写，停下来看看是不是该调整了。

Supertest实战指南：Node.js接口测试与自动化回归测试