TypeORM是Node.js生态中使用最广泛的ORM框架之一，它提供了实体映射、QueryBuilder、事务等丰富能力。但在编写单元测试时，如果每个测试都连接真实的MySQL或PostgreSQL数据库，测试速度会非常慢，而且在CI环境中还需要额外配置数据库服务，极易出现数据污染和用例间相互干扰的问题。本文将围绕如何在Node.js项目中Mock TypeORM的数据库访问层展开，提供从轻量级Mock到内存数据库的多种可落地方案。
方案一：使用SQLite内存数据库替代真实数据库
这是最推荐的一种做法，尤其适合做集成级别的测试。TypeORM本身支持多数据库驱动，SQLite提供了一个特殊的内存模式，数据完全存在内存中，测试结束后自动销毁，既保留了TypeORM完整的功能（QueryBuilder、关系加载、事务），又不需要任何外部依赖。
具体做法是在测试启动前创建一个使用sqlite内存库的DataSource，并通过synchronize: true让TypeORM根据实体定义自动建表，这样实体结构变化时无需手动维护测试库的schema：
import { DataSource } from 'typeorm';
import { User } from '../entity/User';
export const testDataSource = new DataSource({
type: 'sqlite',
database: ':memory:',
dropSchema: true,
synchronize: true,
entities: [User],
logging: false,
});
beforeAll(async () => {
await testDataSource.initialize();
});
afterAll(async () => {
await testDataSource.destroy();
});拿到testDataSource后，可以通过testDataSource.getRepository(User)获取Repository执行各种增删改查，行为与真实数据库高度一致。需要注意的是，SQLite与MySQL在函数支持上有差异，比如GROUP_CONCAT、日期函数的行为不完全相同，如果你的业务代码里大量使用了数据库特有函数，可能需要抽象出一层查询封装，或者改用testcontainers方案启动真实数据库容器。
方案二：使用jest.mock模拟Repository与DataSource
如果你只想测试Service层的业务逻辑，不关心SQL本身的正确性，那么直接Mock掉TypeORM的Repository是更轻量的选择。这种方式完全不需要数据库，测试执行速度极快。核心思路是用jest的jest.mock替换掉依赖注入中的Repository对象，并手动控制其方法的返回值。
假设有一个UserService，它通过构造函数注入了UserRepository：
// userService.ts
import { Repository } from 'typeorm';
import { User } from '../entity/User';
import { injectRepository } from '../utils/inject';
export class UserService {
private userRepo: Repository<User>;
constructor(userRepo: Repository<User>) {
this.userRepo = userRepo;
}
async findActiveUsers(): Promise<User[]> {
return this.userRepo.find({ where: { isActive: true } });
}
}对应的测试文件可以这样写，通过构造一个假的Repository对象传入：
import { UserService } from '../userService';
import { User } from '../entity/User';
describe('UserService', () => {
it('应只返回激活状态的用户', async () => {
const mockUsers: Partial<User>[] = [
{ id: 1, name: '张三', isActive: true },
];
// 构造Mock Repository，实现被调用的方法
const mockRepo = {
find: jest.fn().mockResolvedValue(mockUsers),
} as any;
const service = new UserService(mockRepo);
const result = await service.findActiveUsers();
expect(result).toHaveLength(1);
expect(mockRepo.find).toHaveBeenCalledWith({
where: { isActive: true },
});
});
});这种写法的优点是完全解耦数据库，缺点是它无法验证SQL的正确性——如果你的查询条件写错了，Mock测试依然会通过。因此建议将Mock测试用于业务分支逻辑的验证，而把数据正确性交给SQLite内存库的集成测试来保证，两者互补。
当Service中使用了@InjectRepository装饰器通过依赖注入容器获取Repository时，可以配合@nestjs/testing的Test.createTestingModule来统一覆盖，示例：
const moduleRef = await Test.createTestingModule({
providers: [
UserService,
{
provide: getRepositoryToken(User),
useValue: {
find: jest.fn().mockResolvedValue([]),
findOneBy: jest.fn().mockResolvedValue(null),
save: jest.fn().mockResolvedValue({}),
},
},
],
}).compile();复杂场景处理：事务、自定义Repository与数据工厂
事务是Mock测试中的常见难点。当业务代码使用了manager.transaction或queryRunner时，需要Mock的事务入口会变多。一个实用技巧是Mock整个DataSource或EntityManager，让transaction方法直接执行回调并传入一个Mock的manager：
const mockManager = {
save: jest.fn().mockResolvedValue({}),
findOneBy: jest.fn().mockResolvedValue(null),
delete: jest.fn().mockResolvedValue({ affected: 1 }),
};
const mockDataSource = {
manager: mockManager,
transaction: jest.fn().mockImplementation(async (cb) => {
return cb(mockManager);
}),
} as any;这样事务内的所有操作都能被断言，同时不必关心事务的提交与回滚细节。如果使用的是SQLite内存库方案，则完全不用Mock，transaction会真实执行，测试更接近生产行为。
另一个提升效率的关键是封装数据工厂（Fixture Factory）。测试中反复手工构造实体对象既冗长又容易遗漏字段，可以封装一个createTestUser之类的工厂函数，配合faker生成随机数据，每次测试调用工厂即可获得一条可入库的记录：
import { faker } from '@faker-js/faker';
import { User } from '../entity/User';
export function createTestUser(overrides: Partial<User> = {}): User {
const user = new User();
user.name = faker.person.fullName();
user.email = faker.internet.email();
user.isActive = true;
return Object.assign(user, overrides);
}最后是测试数据隔离问题。在SQLite内存库方案中，推荐在beforeEach中清空所有表，而不是依赖用例执行顺序。可以遍历所有实体执行repository.clear()，保证每个用例都在干净的数据状态下运行。综合来看：纯逻辑测试用jest.mock快速覆盖，涉及查询与事务的用SQLite内存库做集成验证，这套组合拳基本能覆盖TypeORM项目的绝大多数测试需求，同时兼顾速度与可信度。