本文旨在解决在Jest测试框架中，对TypeScript-REST框架的@Preprocessor装饰器所使用的函数进行Mock时遇到的常见问题。由于装饰器在模块加载时即被评估，传统的beforeEach或延迟jest.mock方法可能无法生效。我们将详细探讨问题根源，并提供一种有效的解决方案：通过在测试文件顶部提前进行模块级Mock，确保在装饰器评估前Mock函数已正确替换。
在现代TypeScript应用开发中，尤其是在构建RESTful API时，我们经常会利用装饰器（Decorators）来增强类的功能，例如添加认证、授权或日志记录等前置处理逻辑。TypeScript-REST框架的@Preprocessor装饰器就是一个典型的例子，它允许我们将一个函数作为请求的预处理器。然而，在为包含这类装饰器的控制器编写单元测试时，我们可能会遇到一个棘手的问题：如何有效地Mock掉这些前置处理器函数，以隔离测试目标并避免不必要的副作用？
考虑以下场景，我们有一个AuthenticationController，它使用@Preprocessor(requireAppCheck)来在处理请求前执行requireAppCheck函数：
// firebase.client.ts
import * as config from 'config';
import * as firebase from 'firebase-admin';
export class FirebaseClient {
static initialized = false;
static initialize() {
if (!FirebaseClient.initialized) {
const firebaseConfig: any = config.get('firebase');
firebase.initializeApp({
credential: firebase.credential.cert(JSON.parse(firebaseConfig.privateKey)),
databaseURL: firebaseConfig.databaseUrl,
});
FirebaseClient.initialized = true;
}
}
}
// auth-preprocessors.ts
import * as firebase from 'firebase-admin';
import { Errors } from 'typescript-rest';
import { logger } from './logger';
import { Request } from 'express';
import { FirebaseClient } from './firebase.client';
export async function requireAppCheck(req: Request) {
FirebaseClient.initialize(); // 此处调用了实际的Firebase初始化逻辑
// ... doSomeStuff();
}
// authentication.controller.ts
import { Inject } from 'typescript-ioc';
import { PATCH, Path, Preprocessor } from 'typescript-rest';
import { requireAppCheck } from '../utils/auth-preprocessors';
@Path('/')
export class AuthenticationController {
@Path('v1/path')
@PATCH
@Preprocessor(requireAppCheck) // 这里使用了requireAppCheck
public async myFunc(): Promise<any> {
// ... doSomething();
return { status: 200, message: 'Success' };
}
}在编写AuthenticationController的测试时，我们希望Mock掉requireAppCheck函数，以避免它执行实际的FirebaseClient.initialize()调用，这可能导致测试失败（例如，由于配置缺失或尝试连接真实服务）。然而，以下常见的Mock尝试可能无法奏效：
在beforeEach中进行jest.spyOn：
// authentication.controller.spec.ts (错误示例)
import * as AuthProcessors from '../utils/auth-preprocessors';
// ... 其他导入和AuthenticationController导入
describe('PATCH /path', () => {
let requireAppCheckMock: jest.Mock;
beforeEach(() => {
requireAppCheckMock = jest.fn().mockResolvedValue('someValue');
jest.spyOn(AuthProcessors, 'requireAppCheck').mockImplementation(requireAppCheckMock);
});
it('does stuff', async () => {
// ... 调用控制器方法
});
});这种方法会失败，错误信息会显示FirebaseClient.initialize()被调用，表明requireAppCheck的实际实现被执行了。
使用jest.mock在测试块内：
// authentication.controller.spec.ts (错误示例)
describe('PATCH /path', () => {
let requireAppCheckMock: jest.Mock;
beforeEach(() => {
requireAppCheckMock = jest.fn().mockResolvedValue('someValue');
});
jest.mock('./../utils/auth-preprocessors', () => ({
requireAppCheck: requireAppCheckMock
}));
// ... 其他导入和AuthenticationController导入
it('does stuff', async () => {
// ... 调用控制器方法
});
});同样，这种方法也可能无法正确Mock，因为jest.mock的调用时机不正确。
问题的核心在于JavaScript/TypeScript模块的加载机制以及装饰器的评估时机。
要成功Mock掉@Preprocessor使用的函数，我们必须确保Mock操作在控制器模块被导入和装饰器被评估之前完成。最直接有效的方法是在测试文件的顶部，所有相关模块导入之前，对目标模块进行jest.spyOn。
// authentication.controller.spec.ts (正确示例)
// 1. 首先导入需要被Mock的模块
import * as AuthProcessors from '../utils/auth-preprocessors';
// 2. 在所有其他导入之前，定义Mock函数并进行spyOn
// 确保requireAppCheckMock在AuthenticationController加载前就已存在
let requireAppCheckMock = jest.fn().mockResolvedValue('someValue');
jest.spyOn(AuthProcessors, 'requireAppCheck').mockImplementation(requireAppCheckMock);
// 3. 然后导入AuthenticationController以及其他必要的模块
import { Container } from 'typescript-ioc';
import { AuthenticationController } from './authentication.controller'; // 控制器必须在spyOn之后导入
// ... 其他导入
describe('PATCH /v1/path', () => {
beforeEach(() => {
// 在这里可以重置Mock的状态，但不需要重新spyOn
requireAppCheckMock.mockClear();
requireAppCheckMock.mockResolvedValue('someValue'); // 每次测试前确保mock行为一致
// 如果需要，可以清理typescript-ioc容器
Container.snapshot();
});
afterEach(() => {
Container.restore();
});
it('应该成功处理请求并使用Mock的requireAppCheck', async () => {
// 模拟请求和调用控制器方法
const controller = Container.get(AuthenticationController);
const response = await controller.myFunc();
// 验证Mock函数是否被调用
expect(requireAppCheckMock).toHaveBeenCalledTimes(1);
expect(response.status).toBe(200);
// ... 其他断言
});
it('另一个测试用例', async () => {
requireAppCheckMock.mockRejectedValue(new Error('AppCheck failed')); // 为当前测试设置不同的Mock行为
const controller = Container.get(AuthenticationController);
try {
await controller.myFunc();
// 如果期望失败，此处不应执行
fail('Expected myFunc to throw an error');
} catch (error: any) {
expect(error.message).toContain('AppCheck failed');
}
expect(requireAppCheckMock).toHaveBeenCalledTimes(1);
});
});Mock的生命周期：虽然jest.spyOn在文件顶部执行一次就足以替换函数，但在每个测试用例中，你可能需要使用mockClear()、mockReset()或mockRestore()来重置Mock的状态或行为，以确保测试之间的隔离性。在beforeEach中重新设置mockResolvedValue是一个好习惯。
jest.mock的替代方案：虽然此问题通过jest.spyOn解决，但对于需要完全替换整个模块的场景，jest.mock仍然是首选。如果使用jest.mock，也必须确保它在所有相关模块导入之前被调用，通常是在文件顶部。例如：
// authentication.controller.spec.ts (使用jest.mock的示例)
const requireAppCheckMock = jest.fn().mockResolvedValue('someValue');
jest.mock('../utils/auth-preprocessors', () => ({
requireAppCheck: requireAppCheckMock,
// 如果模块有其他导出，也需要在这里mock，否则它们将是undefined
}));
import { AuthenticationController } from './authentication.controller';
// ... rest of the test请注意，使用jest.mock时，如果被Mock的模块有其他导出且在测试中被使用，也需要在此处一并Mock，否则它们会变为undefined。而jest.spyOn只影响目标函数，对模块的其他部分无影响。
模块导入顺序：始终牢记，被Mock的模块（auth-preprocessors）必须在jest.spyOn或jest.mock之后，而被测试的模块（authentication.controller）必须在Mock操作之后导入。
测试隔离：确保你的Mock不会泄露到其他测试文件或影响全局状态。jest.spyOn通常会创建临时的Mock，并在测试完成后自动清理，但手动重置Mock行为仍是良好的实践。
当在Jest中测试使用装饰器的TypeScript-REST控制器时，对装饰器中引用的函数进行Mock需要特别注意模块的加载顺序和装饰器的评估时机。通过在测试文件的顶部，所有相关模块导入之前，使用jest.spyOn对目标函数进行模块级Mock，可以有效地解决Mock不生效的问题。理解这一机制是编写健壮、可维护的单元测试的关键。
以上就是Jest中装饰器前置处理器函数的Mock策略的详细内容，更多请关注php中文网其它相关文章！
每个人都需要一台速度更快、更稳定的 PC。随着时间的推移，垃圾文件、旧注册表数据和不必要的后台进程会占用资源并降低性能。幸运的是，许多工具可以让 Windows 保持平稳运行。
Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号
387
收藏
