NestJS E2E テストのデバッグは、特に文書化されていないフレームワークの動作が原因で一見単純な問題が発生した場合に、非常にイライラすることがあります。 最近、NestJS の @Processor
デコレータが原因で E2E テストが一貫して失敗するという問題に遭遇しました。 このデコレータは、テストではすぐには明らかではない複雑さをもたらしていることが判明しました。
テストの失敗を解決するための私の最初の試みには、いくつかの一般的なアプローチが含まれていましたが、すべて失敗しました。
ioredis-mock
モック: ioredis-mock
との Redis インタラクション全体をモックしようとしましたが、根本的な問題を解決できませんでした。@Processor
と嘲笑核心的な問題は、@Processor
ファイル内での src/user/audio.consumer.ts
デコレーターの使用から発生しました。このデコレータの動作は NestJS ドキュメントで明示的に詳しく説明されていないため、予期しないテストの失敗につながります。
私の最初のテスト設定は次のようになりました:
<code class="language-typescript">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'); }); });</code>
これは、@Processor
デコレーターが原因で失敗しました。 この解決策には、モックに対するより的を絞ったアプローチが必要でした:
<code class="language-typescript">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();</code>
空のオブジェクトで AudioConsumer
プロバイダーを明示的にオーバーライドすることで、@Processor
デコレータの暗黙的な動作をバイパスし、テストの失敗を解決しました。
@Processor
問題は解決されましたが、Testcontainers と実際の Redis インスタンスで発生した問題にはまだ完全には対処していません。 これらの特定の障害の根本原因を特定するには、さらなる調査が必要です。
以上がNestjsのETESTが頭痛を与えたときの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。