当 NestJS 中的 ETests 让我头疼时

>调试Nestjs E2E测试可能令人难以置信的令人沮丧，尤其是在由于无证件的框架行为而出现看似简单的问题时。 最近，由于Nestjs中的装饰器，我的E2E测试始终失败，我最近遇到了一个问题。 事实证明，这种装饰器引入了复杂性。 @Processor我最初解决测试失败的尝试涉及几种常见的方法，这都是不成功的：

1. 模拟：试图模拟与ioredis-mock>的整个redis相互作用未能解决基本问题。> ioredis-mock
> testContainers：
2. >利用测试范围在测试过程中管理临时redis实例也被证明是无效的。> >
真实的redis实例：
3. 即使使用功能齐全的运行redis实例，测试仍会继续失败。>
根本原因：

和模拟

@Processor核心问题源于在我的

>文件中使用

>装饰器。 Nestjs文档中未明确详细详细介绍此装饰师的行为，导致了意外的测试失败。@Processor> src/user/audio.consumer.ts我的初始测试设置看起来像这样：

由于装饰器而失败。 该解决方案需要采取更具针对性的嘲笑方法：

import { getQueueToken } from '@nestjs/bullmq';
import { INestApplication } from '@nestjs/common';
import { Test, TestingModule } from '@nestjs/testing';
import * as request from 'supertest';
import { AppModule } from '../src/app.module';
import { mockBullMqService } from './bullmq.mock';

describe('AppController (e2e)', () => {
  // ... (beforeAll, afterAll omitted for brevity)

  it('/ (GET)', () => {
    return request(app.getHttpServer())
      .get('/cart')
      .expect(200)
      .expect('Hi');
  });
});

@Processor通过用一个空对象明确覆盖

的提供商，我绕过了

const moduleFixture: TestingModule = await Test.createTestingModule({
  imports: [AppModule],
})
  .overrideProvider(getQueueToken('YOUR_QUEUE_NAME'))
  .useValue({
    on: jest.fn(),
    add: jest.fn(),
    process: jest.fn(),
  })
  .overrideProvider(AudioConsumer) // Crucial addition
  .useValue({}) // Provide an empty value
  .compile();

装饰者的隐式行为并解决了测试失败。

剩下的挑战：测试范围和实际redisAudioConsumer @Processor>

问题得到解决，但我尚未完全解决testContainers遇到的问题和真正的REDIS实例。 需要进一步研究以确定这些特定失败的根本原因。

以上是当 NestJS 中的 ETests 让我头疼时的详细内容。更多信息请关注PHP中文网其他相关文章！