如何在Node.js中使用Jest编写集成测试？

1. 如何在Jest中编写集成测试？ #

集成测试的核心是验证多模块/服务的协同逻辑，比如接口与数据库的交互、第三方API调用等。在Jest里编写的核心流程如下：

• 准备测试环境：启动专属的测试数据库（比如用Docker临时实例或本地测试库），通过脚本初始化表结构、插入测试数据。
• 编写测试用例：用test/it函数包裹测试逻辑，但要覆盖完整流程。比如测试用户注册接口，要调用接口后，直接查询数据库验证记录是否新增。
• 清理测试环境：用Jest的beforeEach/afterEach钩子，在每个测试前后重置数据库（清空表、回滚事务），避免测试数据互相干扰。

举个简单的示例：

import request from 'supertest';
import app from '../app';
import { db } from '../db';

// 每个测试前清空用户表
beforeEach(async () => {
  await db.query('TRUNCATE TABLE users RESTART IDENTITY');
});

test('用户注册成功后数据库新增对应记录', async () => {
  // 调用注册接口
  const response = await request(app)
    .post('/api/users')
    .send({ username: 'testuser', email: 'test@example.com' });

  expect(response.statusCode).toBe(201);
  
  // 查询数据库验证结果
  const userResult = await db.query('SELECT * FROM users WHERE username = $1', ['testuser']);
  expect(userResult.rows.length).toBe(1);
  expect(userResult.rows[0].email).toBe('test@example.com');
});

// 所有测试结束后关闭数据库连接
afterAll(async () => {
  await db.end();
});

2. 集成测试写法与单元测试是否不同？ #

差异很明显，核心区别体现在这几点：

• 测试范围：单元测试聚焦单个函数/模块，完全隔离外部依赖；集成测试覆盖多模块协作，甚至包含真实外部服务（数据库、第三方API）。
• 依赖处理：单元测试会Mock/Stub所有外部依赖；集成测试优先使用真实依赖，仅在必要时模拟。
• 运行速度：单元测试快，都是内存内操作；集成测试慢，因为要和真实服务交互。
• 测试目的：单元测试保证单个模块逻辑正确；集成测试验证模块间交互符合预期，比如接口与数据库的映射是否正确、第三方API调用的处理逻辑是否达标。

3. 集成测试文件是否需特殊扩展名，还是沿用.spec.ts？ #

不需要特殊扩展名，.spec.ts或.test.ts都可以用。如果需要区分单元和集成测试，可以在文件名里加标识，比如user.integration.spec.ts，后续能通过Jest配置单独运行某一类测试。

4. 集成测试文件需要放在特殊目录下吗？ #

不是强制要求，但建议单独归类到tests/integration目录，和单元测试的tests/unit分开。这样管理更清晰，也方便在Jest配置中拆分测试命令：

比如在jest.config.js中配置：

module.exports = {
  projects: [
    {
      displayName: 'unit',
      testMatch: ['<rootDir>/tests/unit/**/*.spec.ts'],
    },
    {
      displayName: 'integration',
      testMatch: ['<rootDir>/tests/integration/**/*.spec.ts'],
      testTimeout: 10000, // 集成测试耗时更长，需设置更长超时
    },
  ],
};

之后就能用npm test -- --selectProjects unit只跑单元测试，npm test -- --selectProjects integration只跑集成测试。

5. 集成测试中绝对不能使用Stub/Mock吗？ #

当然不是绝对的。集成测试优先验证真实协作，但遇到以下场景时，Mock/Stub是合理选择：

• 第三方服务不稳定/成本高：比如调用支付API，真实测试会产生费用或容易失败，这时候可以Stub返回结果，只验证自身代码的处理逻辑。
• 模拟极端场景：比如第三方服务返回500错误，真实调用很难复现，用Mock模拟该场景更高效。
• 依赖未实现：如果某个协作服务还没开发完成，暂时用Stub模拟其行为，保证集成测试能先行运行。

注意：Mock的范围要尽量小，核心依赖（比如自身的数据库）必须用真实实例，否则就失去了集成测试的意义。

内容的提问来源于stack exchange，提问作者Jon Sud