[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"verticals":3,"article-nestjs-weekly-testing-provider-overrides":44,"search-suggestions":459,"related-nestjs-weekly-testing-provider-overrides":499,"code:plain:true:ktn5uj":560,"code:ts:true:1uy4k9w":561,"code:ts:true:kpwmr":562,"code:ts:true:j9yvca":563,"code:ts:true:1bvgskh":564,"code:ts:true:1nmezln":565,"code:ts:true:1tt4szh":566,"code:ts:true:sf4td1":567,"code:ts:true:9wj6mp":568,"comments-01a0a630-c856-72d3-bae5-3339e38a8564":569},[4,20,32],{"id":5,"slug":6,"name":7,"tagline":8,"description":9,"accentFrom":10,"accentTo":11,"icon":12,"defaultLocale":13,"locales":14,"features":16,"position":19},"019fe637-3d33-714b-b57f-23e163ffca0c","dev","Web Development","Read it. Run it. Prove it.","A post a day on modern web development — most with an editable playground and a quiz that explains every answer. Free, no account needed.","violet-500","cyan-400","◇","en",[13,15],"fa",{"courses":17,"paths":17,"articles":17,"exams":18,"flashcards":18,"packages":17,"community":17,"certificates":17,"teams":17,"commerce":17},true,false,0,{"id":21,"slug":22,"name":23,"tagline":24,"description":25,"accentFrom":26,"accentTo":10,"icon":27,"defaultLocale":13,"locales":28,"features":30,"position":31},"019fe637-3dc2-754c-8657-0f175bfee7c6","lang","Languages","Learn a language the way you learn a codebase.","Grammar explained the way good documentation explains an API — one idea at a time, each with a quiz.","amber-400","⌘",[13,15,29],"es",{"courses":18,"paths":18,"articles":17,"exams":18,"flashcards":17,"packages":18,"community":17,"certificates":17,"teams":18,"commerce":18},2,{"id":33,"slug":34,"name":35,"tagline":36,"description":37,"accentFrom":38,"accentTo":39,"icon":40,"defaultLocale":13,"locales":41,"features":42,"position":43},"7b3c16f2-931d-410e-802e-e1fa4edab7de","soft","Soft Skills","The half of the job nobody wrote documentation for.","Weekly, on the parts of working life that decide more than your code does — first weeks, meetings, interviews, promotions, and the people around you. Written from what actually happens, and recorded as a podcast you can listen to on the walk.","emerald-400","teal-300","◉",[13],{"courses":18,"paths":18,"articles":17,"exams":18,"flashcards":18,"packages":18,"community":17,"certificates":18,"teams":18,"commerce":18},3,{"id":45,"slug":46,"title":47,"subtitle":48,"excerpt":49,"coverUrl":50,"locale":13,"readingMinutes":51,"publishedAt":52,"viewCount":53,"likeCount":19,"commentCount":19,"author":54,"vertical":59,"topic":60,"tags":63,"_count":74,"playground":76,"body":78,"bodyMd":425,"seo":426,"translationGroupId":428,"series":429,"podcastUrl":48,"verticalId":5,"thread":447,"assessments":449,"translations":455,"quiz":457},"01a0a630-c856-72d3-bae5-3339e38a8564","nestjs-weekly-testing-provider-overrides","NestJS Testing Module: Provider Overrides (with Cheat Sheet)",null,"A complete guide to NestJS's testing module: how overrideProvider really wires mocks, why get() fails on scoped providers, and using useMocker.","\u002Fmedia\u002Fcovers\u002Fnestjs-weekly-testing-provider-overrides.png",13,"2026-09-18T10:54:07.724Z",18,{"id":55,"name":56,"username":57,"avatarUrl":48,"headline":58},"019fe637-3c25-7088-9034-39c9f15dc3c8","Parsa Jiravand","parsa","Frontend engineer · building bestpractic",{"slug":6,"name":7,"accentFrom":10,"accentTo":11},{"slug":61,"name":62},"nestjs","Nestjs",[64,65,68,71],{"slug":61,"name":62,"color":48},{"slug":66,"name":67,"color":48},"node","Node",{"slug":69,"name":70,"color":48},"typescript","Typescript",{"slug":72,"name":73,"color":48},"tutorial","Tutorial",{"assessments":75},1,{"slug":46,"title":77},"NestJS testing module — interactive playground",{"blocks":79,"version":75},[80,84,90,93,96,101,104,113,116,119,122,137,140,143,148,151,155,158,161,164,167,170,173,177,180,183,186,190,193,196,199,203,206,209,212,216,219,222,225,228,232,235,240,243,246,249,253,256,259,267,270,278,281,285,288,291,294,297,300,303,306,309,312,315,318,321,324,327,330,378,381,384,387,390,393,396,404,407,410,413,416,419],{"id":81,"html":82,"type":83},"b1","\u003Cp>A unit test for \u003Ccode>OrdersController\u003C\u002Fcode> calls \u003Ccode>Test.createTestingModule({...}).compile()\u003C\u002Fcode>, then \u003Ccode>moduleRef.get(AuditLogService)\u003C\u002Fcode> to grab the mock and assert it was called. Every other provider in the test resolves without a hitch. This one throws:\u003C\u002Fp>","paragraph",{"id":85,"code":86,"type":87,"language":88,"highlight":89},"b2","Error: AuditLogService is a scoped provider. Use \"moduleRef.resolve()\" instead of \"moduleRef.get()\".","code","plain",[],{"id":91,"html":92,"type":83},"b3","\u003Cp>Nothing about the test setup looks wrong. \u003Ccode>AuditLogService\u003C\u002Fcode> is in the \u003Ccode>providers\u003C\u002Fcode> array. It was overridden with \u003Ccode>useValue\u003C\u002Fcode>. The override even worked — the controller under test is using the mock, not the real thing. The one line that's wrong is the \u003Cem>retrieval\u003C\u002Fem> method, and until you understand what \u003Ccode>get()\u003C\u002Fcode> and \u003Ccode>resolve()\u003C\u002Fcode> are each actually reaching into, the fix looks like superstition: "just switch to \u003Ccode>resolve()\u003C\u002Fcode> and it works," without knowing why.\u003C\u002Fp>",{"id":94,"html":95,"type":83},"b4","\u003Cp>This is written against \u003Cstrong>NestJS 12.0.x\u003C\u002Fstrong> (verified September 2026, current \u003Ccode>@nestjs\u002Fcore\u003C\u002Fcode> release). Everything here — \u003Ccode>Test.createTestingModule\u003C\u002Fcode>, the override methods, \u003Ccode>get()\u003C\u002Fcode>\u002F\u003Ccode>resolve()\u003C\u002Fcode> — has been stable across the v9–v12 line; nothing in this article depends on a v12-specific change.\u003C\u002Fp>",{"id":97,"html":98,"text":99,"type":100,"level":31},"b5","What you'll learn","What you'll learn","heading",{"id":102,"html":103,"type":83},"b6","\u003Cp>By the end of this article you'll be able to:\u003C\u002Fp>",{"id":105,"type":106,"items":107,"ordered":18},"b7","list",[108,109,110,111,112],"Explain what a NestJS testing module actually \u003Cem>is\u003C\u002Fem> — not a mock registry, a real DI container","Use \u003Ccode>overrideProvider().useValue()\u002F.useClass()\u002F.useFactory()\u003C\u002Fcode> to swap a dependency without breaking the rest of the module's wiring","Know exactly when \u003Ccode>module.get()\u003C\u002Fcode> works and when it throws, and reach for \u003Ccode>module.resolve()\u003C\u002Fcode> correctly when it does","Use \u003Ccode>useMocker\u003C\u002Fcode> to stop hand-writing boilerplate mocks — and know when \u003Cem>not\u003C\u002Fem> to","Override a guard, pipe, interceptor, or filter for an end-to-end test, not just a constructor-injected provider",{"id":114,"html":115,"text":115,"type":100,"level":31},"b8","Who this is for",{"id":117,"html":118,"type":83},"b9","\u003Cp>You've written a NestJS service or two, used \u003Ccode>@Injectable()\u003C\u002Fcode> and constructor injection, and you've run \u003Ccode>npm test\u003C\u002Fcode> on a generated Nest project at least once. If you haven't yet read the \u003Ca href=\"https:\u002F\u002Fdev.to\u002Fparsajiravand\u002Fnestjs-dependency-injection-explained-with-cheat-sheet-4bem\">NestJS dependency injection\u003C\u002Fa> episode of this series, the scope material here (\u003Ccode>DEFAULT\u003C\u002Fcode> vs \u003Ccode>REQUEST\u003C\u002Fcode> vs \u003Ccode>TRANSIENT\u003C\u002Fcode>) will make more sense with that as background — but this article stands on its own.\u003C\u002Fp>",{"id":120,"html":121,"text":121,"type":100,"level":31},"b10","Table of contents",{"id":123,"type":106,"items":124,"ordered":18},"b11",[125,126,127,128,129,130,131,132,133,134,135,136],"\u003Ca href=\"#the-problem-mocking-a-nestjs-service-the-naive-way\">The problem: mocking a NestJS service the naive way\u003C\u002Fa>","\u003Ca href=\"#the-mental-model-the-testing-module-is-a-real-container\">The mental model: the testing module is a real container\u003C\u002Fa>","\u003Ca href=\"#stage-1-overrideprovider-the-smallest-correct-example\">Stage 1: overrideProvider, the smallest correct example\u003C\u002Fa>","\u003Ca href=\"#stage-2-usefactory-when-the-mock-needs-its-own-dependencies\">Stage 2: useFactory, when the mock needs its own dependencies\u003C\u002Fa>","\u003Ca href=\"#stage-3-usemocker-auto-mocking-the-rest-of-the-graph\">Stage 3: useMocker, auto-mocking the rest of the graph\u003C\u002Fa>","\u003Ca href=\"#stage-4-get-vs-resolve-the-scoped-provider-gotcha\">Stage 4: get() vs resolve(), the scoped-provider gotcha\u003C\u002Fa>","\u003Ca href=\"#stage-5-overriding-guards-pipes-interceptors-and-filters\">Stage 5: overriding guards, pipes, interceptors, and filters\u003C\u002Fa>","\u003Ca href=\"#edge-cases-and-gotchas\">Edge cases and gotchas\u003C\u002Fa>","\u003Ca href=\"#best-practices\">Best practices\u003C\u002Fa>","\u003Ca href=\"#faq\">FAQ\u003C\u002Fa>","\u003Ca href=\"#cheat-sheet\">Cheat sheet\u003C\u002Fa>","\u003Ca href=\"#key-takeaways\">Key takeaways\u003C\u002Fa>",{"id":138,"html":139,"text":139,"type":100,"level":31},"b12","The problem: mocking a NestJS service the naive way",{"id":141,"html":142,"type":83},"b13","\u003Cp>Say \u003Ccode>OrdersService\u003C\u002Fcode> depends on \u003Ccode>CacheService\u003C\u002Fcode>:\u003C\u002Fp>",{"id":144,"code":145,"type":87,"language":146,"highlight":147},"b14","@Injectable()\nexport class OrdersService {\n  constructor(private readonly cache: CacheService) {}\n\n  async getOrder(id: string) {\n    const cached = await this.cache.get(id);\n    if (cached) return cached;\n    \u002F\u002F ...load from DB, then this.cache.set(id, order)\n  }\n}","ts",[],{"id":149,"html":150,"type":83},"b15","\u003Cp>The instinct, coming from plain Node testing, is to skip Nest entirely:\u003C\u002Fp>",{"id":152,"code":153,"type":87,"language":146,"highlight":154},"b16","\u002F\u002F The wrong way — bypasses Nest's DI graph completely\nconst fakeCache = { get: jest.fn(), set: jest.fn() };\nconst service = new OrdersService(fakeCache as any);",[],{"id":156,"html":157,"type":83},"b17","\u003Cp>This "works" for exactly this constructor. It breaks the moment someone adds a second constructor parameter — every call site of \u003Ccode>new OrdersService(...)\u003C\u002Fcode> in every test file needs updating by hand, because you're testing against the \u003Cem>implementation\u003C\u002Fem> of the constructor, not the \u003Cem>contract\u003C\u002Fem> Nest resolves it through. It also can't test anything that depends on Nest actually wiring the object graph: a guard reading a provider, a module boundary, an \u003Ccode>onModuleInit\u003C\u002Fcode> hook. You've tested a plain JavaScript class, not a NestJS provider.\u003C\u002Fp>",{"id":159,"html":160,"type":83},"b18","\u003Cp>The second instinct is \u003Ccode>jest.mock('.\u002Fcache.service')\u003C\u002Fcode>, patching the module import. This fights Nest's instantiation instead of cooperating with it — it works until the service is constructed through \u003Ccode>useFactory\u003C\u002Fcode> or aliased with \u003Ccode>useExisting\u003C\u002Fcode>, at which point the mock and the real DI graph disagree about what \u003Ccode>CacheService\u003C\u002Fcode> even resolves to, and the failure mode is confusing rather than obvious.\u003C\u002Fp>",{"id":162,"html":163,"type":83},"b19","\u003Cp>Nest ships a purpose-built answer to both problems: \u003Ccode>@nestjs\u002Ftesting\u003C\u002Fcode>.\u003C\u002Fp>",{"id":165,"html":166,"text":166,"type":100,"level":31},"b20","The mental model: the testing module is a real container",{"id":168,"html":169,"type":83},"b21","\u003Cp>\u003Cstrong>The mental model:\u003C\u002Fstrong> \u003Ccode>Test.createTestingModule({...})\u003C\u002Fcode> doesn't create a fake, lightweight stand-in for your app — it builds the \u003Cem>exact same kind of DI container\u003C\u002Fem> Nest builds when your app boots, from the same module metadata. \u003Ccode>overrideProvider(Token)\u003C\u002Fcode> doesn't monkey-patch anything after the fact; it swaps what \u003Ccode>Token\u003C\u002Fcode> resolves to \u003Cstrong>before\u003C\u002Fstrong> \u003Ccode>.compile()\u003C\u002Fcode> runs, so when the container is built, every real consumer that constructor-injects that token gets your replacement — automatically, through the same resolution path as production.\u003C\u002Fp>",{"id":171,"html":172,"type":83},"b22","\u003Cp>That's the whole idea in one sentence: \u003Cstrong>override the registration, then let the real container do the wiring.\u003C\u002Fstrong> You never hand-assemble the object graph yourself, so a test can't quietly drift from how the app is actually wired.\u003C\u002Fp>",{"id":174,"code":175,"type":87,"language":146,"highlight":176},"b23","const moduleRef = await Test.createTestingModule({\n  providers: [OrdersService, CacheService],\n})\n  .overrideProvider(CacheService)\n  .useValue(fakeCache)\n  .compile();\n\nconst service = moduleRef.get(OrdersService);\n\u002F\u002F service.cache is `fakeCache` — Nest injected it, you didn't.",[],{"id":178,"html":179,"type":83},"b24","\u003Cp>\u003Cstrong>Key concept:\u003C\u002Fstrong> \u003Ccode>OrdersService\u003C\u002Fcode> never mentions the mock. It still says \u003Ccode>constructor(private readonly cache: CacheService)\u003C\u002Fcode>. The override happens one layer up, in how the token is registered — which is exactly why it survives constructor changes that don't touch \u003Ccode>CacheService\u003C\u002Fcode>'s shape.\u003C\u002Fp>",{"id":181,"html":182,"text":182,"type":100,"level":31},"b25","Stage 1: overrideProvider, the smallest correct example",{"id":184,"html":185,"type":83},"b26","\u003Cp>The three replacement methods mirror the ones you already know from provider registration itself:\u003C\u002Fp>",{"id":187,"code":188,"type":87,"language":146,"highlight":189},"b27","Test.createTestingModule({ providers: [OrdersService, CacheService] })\n  .overrideProvider(CacheService)\n  .useValue(fakeCache)          \u002F\u002F a plain object\u002Fmock — no DI, no lifecycle\n  .compile();\n\nTest.createTestingModule({ providers: [OrdersService, CacheService] })\n  .overrideProvider(CacheService)\n  .useClass(InMemoryCacheService) \u002F\u002F a real class, its own constructor DI-resolved\n  .compile();",[],{"id":191,"html":192,"type":83},"b28","\u003Cp>\u003Ccode>useValue\u003C\u002Fcode> is the right default: fast, explicit, and you can inspect \u003Ccode>fakeCache.get.mock.calls\u003C\u002Fcode> directly. Reach for \u003Ccode>useClass\u003C\u002Fcode> when the fake needs real behavior (an in-memory cache that actually stores and evicts), because unlike \u003Ccode>useValue\u003C\u002Fcode>, \u003Ccode>useClass\u003C\u002Fcode> still goes through Nest's own instantiation — its constructor can inject other test doubles too.\u003C\u002Fp>",{"id":194,"html":195,"text":195,"type":100,"level":31},"b29","Stage 2: useFactory, when the mock needs its own dependencies",{"id":197,"html":198,"type":83},"b30","\u003Cp>Sometimes the fake itself needs something resolved from the container — a config value, another mock, the module ref:\u003C\u002Fp>",{"id":200,"code":201,"type":87,"language":146,"highlight":202},"b31","Test.createTestingModule({ providers: [OrdersService, CacheService, ConfigService] })\n  .overrideProvider(CacheService)\n  .useFactory({\n    factory: (config: ConfigService) => new FakeCacheWithTtl(config.get('CACHE_TTL')),\n    inject: [ConfigService],\n  })\n  .compile();",[],{"id":204,"html":205,"type":83},"b32","\u003Cp>\u003Cstrong>Key concept:\u003C\u002Fstrong> \u003Ccode>inject\u003C\u002Fcode> is resolved from the \u003Cem>same\u003C\u002Fem> container being built — including other overrides. This is the one case where the mock still participates in DI, rather than being a static value dropped in from outside.\u003C\u002Fp>",{"id":207,"html":208,"text":208,"type":100,"level":31},"b33","Stage 3: useMocker, auto-mocking the rest of the graph",{"id":210,"html":211,"type":83},"b34","\u003Cp>A module with six providers and you only care about testing one of them means five hand-written \u003Ccode>useValue\u003C\u002Fcode> mocks that add nothing to the assertions. \u003Ccode>useMocker\u003C\u002Fcode> removes that boilerplate: pass it a factory, and Nest calls it for every provider you \u003Cem>didn't\u003C\u002Fem> explicitly override, generating a jest auto-mock (every method replaced with \u003Ccode>jest.fn()\u003C\u002Fcode>) by default:\u003C\u002Fp>",{"id":213,"code":214,"type":87,"language":146,"highlight":215},"b35","const moduleRef = await Test.createTestingModule({\n  providers: [OrdersService, CacheService, AuditLogService, MetricsService],\n})\n  .useMocker((token) => {\n    if (token === CacheService) return fakeCache; \u002F\u002F your real, meaningful mock\n    if (typeof token === 'function') return jest.fn(); \u002F\u002F auto-mock the rest\n  })\n  .compile();",[],{"id":217,"html":218,"type":83},"b36","\u003Cp>This is genuinely useful for modules with a lot of incidental dependencies. It is also easy to overuse: if \u003Ccode>useMocker\u003C\u002Fcode> quietly auto-mocks the one provider your test is actually supposed to exercise, the test passes for the wrong reason — it never called anything real. Use it to remove noise around the thing you're testing, never to remove the thing you're testing.\u003C\u002Fp>",{"id":220,"html":221,"text":221,"type":100,"level":31},"b37","Stage 4: get() vs resolve(), the scoped-provider gotcha",{"id":223,"html":224,"type":83},"b38","\u003Cp>This is the error from the opening of this article, and it isn't a bug — it's \u003Ccode>Scope\u003C\u002Fcode> doing exactly what it's documented to do.\u003C\u002Fp>",{"id":226,"html":227,"type":83},"b39","\u003Cp>\u003Cstrong>\u003Ccode>module.get(Token)\u003C\u002Fcode>\u003C\u002Fstrong> reaches into the container's static registrations — the ones built once at \u003Ccode>.compile()\u003C\u002Fcode> time. That's every \u003Ccode>DEFAULT\u003C\u002Fcode>-scoped (singleton) provider. \u003Cstrong>\u003Ccode>module.resolve(Token)\u003C\u002Fcode>\u003C\u002Fstrong> is asynchronous, and creates (or looks up) a \u003Cem>request-scoped sub-tree\u003C\u002Fem> — which is the only kind of container a \u003Ccode>REQUEST\u003C\u002Fcode>- or \u003Ccode>TRANSIENT\u003C\u002Fcode>-scoped provider can live in.\u003C\u002Fp>",{"id":229,"code":230,"type":87,"language":146,"highlight":231},"b40","@Injectable({ scope: Scope.REQUEST })\nexport class AuditLogService { \u002F* ... *\u002F }\n\n\u002F\u002F Throws — a REQUEST-scoped provider has no single static instance to hand back\nmoduleRef.get(AuditLogService);\n\n\u002F\u002F Correct — resolves a fresh instance for this call\nconst auditLog = await moduleRef.resolve(AuditLogService);",[],{"id":233,"html":234,"type":83},"b41","\u003Cp>Two details make this behave differently from \u003Ccode>get()\u003C\u002Fcode> in ways that trip people up:\u003C\u002Fp>",{"id":236,"type":106,"items":237,"ordered":18},"b42",[238,239],"\u003Cstrong>It's a Promise.\u003C\u002Fstrong> Forgetting \u003Ccode>await\u003C\u002Fcode> gives you a \u003Ccode>Promise<AuditLogService>\u003C\u002Fcode> that happily passes typechecking in a loosely-typed test and fails at runtime in a confusing spot.","\u003Cstrong>Every call gets a new instance, by default.\u003C\u002Fstrong> Two \u003Ccode>moduleRef.resolve(AuditLogService)\u003C\u002Fcode> calls in the same test return two different objects — because in production, two different HTTP requests would too. If you need the \u003Cem>same\u003C\u002Fem> instance twice (to simulate one request touching the provider from two places), pass the same context id explicitly: \u003Ccode>ContextIdFactory.create()\u003C\u002Fcode> once, then \u003Ccode>moduleRef.resolve(Token, contextId)\u003C\u002Fcode> for each call that should share it.",{"id":241,"html":242,"type":83},"b43","\u003Cp>\u003Cstrong>Key concept:\u003C\u002Fstrong> \u003Ccode>get()\u003C\u002Fcode> vs \u003Ccode>resolve()\u003C\u002Fcode> isn't a style choice — it's \u003Ccode>Scope.DEFAULT\u003C\u002Fcode> vs everything else, the exact distinction from how NestJS resolves providers in production. A test that gets this right is also proof the provider's scope is doing what you think it's doing.\u003C\u002Fp>",{"id":244,"html":245,"text":245,"type":100,"level":31},"b44","Stage 5: overriding guards, pipes, interceptors, and filters",{"id":247,"html":248,"type":83},"b45","\u003Cp>Everything so far overrides a \u003Cstrong>provider\u003C\u002Fstrong> — something resolved through constructor injection. Guards, pipes, interceptors, and filters applied with \u003Ccode>@UseGuards()\u003C\u002Fcode>, \u003Ccode>@UsePipes()\u003C\u002Fcode>, \u003Ccode>@UseInterceptors()\u003C\u002Fcode>, and \u003Ccode>@UseFilters()\u003C\u002Fcode> (or registered globally) are a separate concern in Nest's request pipeline, so \u003Ccode>TestingModuleBuilder\u003C\u002Fcode> ships parallel methods for them, with the identical \u003Ccode>useValue\u003C\u002Fcode>\u002F\u003Ccode>useClass\u003C\u002Fcode>\u002F\u003Ccode>useFactory\u003C\u002Fcode> chain:\u003C\u002Fp>",{"id":250,"code":251,"type":87,"language":146,"highlight":252},"b46","const moduleRef = await Test.createTestingModule({\n  controllers: [OrdersController],\n})\n  .overrideGuard(RolesGuard)\n  .useValue({ canActivate: () => true }) \u002F\u002F always allow, for this test\n  .compile();\n\nconst app = moduleRef.createNestApplication();\nawait app.init();\n\u002F\u002F now use supertest against `app.getHttpServer()` for a real e2e request",[],{"id":254,"html":255,"type":83},"b47","\u003Cp>This is the tool for an \u003Cstrong>end-to-end\u003C\u002Fstrong> test — one that goes through \u003Ccode>createNestApplication()\u003C\u002Fcode> and an actual HTTP request via \u003Ccode>supertest\u003C\u002Fcode>, exercising the real request lifecycle (middleware → guards → interceptors → pipes → handler → interceptors → filters, covered in \u003Ca href=\"https:\u002F\u002Fdev.to\u002Fparsajiravand\u002Fnestjs-request-lifecycle-explained-with-cheat-sheet-227l\">the request lifecycle episode\u003C\u002Fa> of this series) with just the one guard swapped out. It is the difference between testing "does \u003Ccode>OrdersService.getOrder()\u003C\u002Fcode> return the right shape" and "does a real request to \u003Ccode>GET \u002Forders\u002F:id\u003C\u002Fcode> actually reach the handler."\u003C\u002Fp>",{"id":257,"html":258,"text":258,"type":100,"level":31},"b48","Edge cases and gotchas",{"id":260,"type":106,"items":261,"ordered":18},"b49",[262,263,264,265,266],"\u003Cstrong>Overrides must be declared before \u003Ccode>.compile()\u003C\u002Fcode>.\u003C\u002Fstrong> There is no "override after the fact" — the testing module is immutable once built, same as the real app's container.","\u003Cstrong>Overriding module boundaries doesn't undo \u003Ccode>exports\u003C\u002Fcode>.\u003C\u002Fstrong> If \u003Ccode>CacheService\u003C\u002Fcode> isn't exported from the module that owns it, importing that module into your test setup still won't expose it — the same encapsulation rules from a real app apply inside a test.","\u003Cstrong>\u003Ccode>{ strict: false }\u003C\u002Fcode> on \u003Ccode>get()\u003C\u002Fcode> widens the \u003Cem>search\u003C\u002Fem>, not the \u003Cem>scope\u003C\u002Fem>.\u003C\u002Fstrong> \u003Ccode>moduleRef.get(Token, { strict: false })\u003C\u002Fcode> lets you fetch a provider that lives in a different module in the graph than the one you passed to \u003Ccode>createTestingModule\u003C\u002Fcode> — it does not let \u003Ccode>get()\u003C\u002Fcode> reach a scoped provider. That still needs \u003Ccode>resolve()\u003C\u002Fcode>.","\u003Cstrong>Lifecycle hooks still run.\u003C\u002Fstrong> \u003Ccode>onModuleInit\u003C\u002Fcode>, \u003Ccode>onApplicationBootstrap\u003C\u002Fcode>, and friends fire for real during \u003Ccode>.compile()\u003C\u002Fcode> (and \u003Ccode>app.init()\u003C\u002Fcode> for a full app) exactly as they would in production. A provider that opens a real connection in \u003Ccode>onModuleInit\u003C\u002Fcode> will try to open one in your test too, unless it's the thing you overrode.","\u003Cstrong>\u003Ccode>overrideModule\u003C\u002Fcode> swaps a whole module, not a token.\u003C\u002Fstrong> It's the heaviest override available — useful for replacing an entire \u003Ccode>DatabaseModule\u003C\u002Fcode> with an in-memory test double — and correspondingly rare; reach for \u003Ccode>overrideProvider\u003C\u002Fcode> first.",{"id":268,"html":269,"text":269,"type":100,"level":31},"b50","Best practices",{"id":271,"type":106,"items":272,"ordered":18},"b51",[273,274,275,276,277],"\u003Cstrong>Override the narrowest token that makes the test honest.\u003C\u002Fstrong> Swap \u003Ccode>CacheService\u003C\u002Fcode>, not \u003Ccode>OrdersModule\u003C\u002Fcode> — the more of the real graph you keep, the more the test proves.","\u003Cstrong>Prefer real modules plus \u003Ccode>overrideProvider\u003C\u002Fcode> over hand-built instances.\u003C\u002Fstrong> Let Nest do the constructor wiring; don't reimplement it in a test helper that can drift from the real module.","\u003Cstrong>Reach for \u003Ccode>useMocker\u003C\u002Fcode> to cut noise, not to cut assertions.\u003C\u002Fstrong> If a test can pass without the "real" mock ever being asked to do anything, that mock probably shouldn't be auto-generated.","\u003Cstrong>Match the real provider's scope in the fake.\u003C\u002Fstrong> A \u003Ccode>useValue\u003C\u002Fcode> mock standing in for a \u003Ccode>REQUEST\u003C\u002Fcode>-scoped provider is fine for a unit test that doesn't care about per-request identity — but if the article's \u003Ccode>resolve()\u003C\u002Fcode> distinction matters to what you're testing, keep the scope on the override too.","\u003Cstrong>Use \u003Ccode>createNestApplication()\u003C\u002Fcode> sparingly.\u003C\u002Fstrong> It's the right tool for a genuine end-to-end test of routing, guards, and the lifecycle — not the default for testing one service's logic.",{"id":279,"html":280,"text":280,"type":100,"level":31},"b52","FAQ",{"id":282,"html":283,"text":284,"type":100,"level":43},"b53","Why does \u003Ccode>moduleRef.get()\u003C\u002Fcode> throw for a provider I know is registered?","Why does moduleRef.get() throw for a provider I know is registered?",{"id":286,"html":287,"type":83},"b54","\u003Cp>Because it's \u003Ccode>DEFAULT\u003C\u002Fcode>-scoped only. \u003Ccode>get()\u003C\u002Fcode> reads the container's static registrations, built once at \u003Ccode>.compile()\u003C\u002Fcode>. A \u003Ccode>REQUEST\u003C\u002Fcode>- or \u003Ccode>TRANSIENT\u003C\u002Fcode>-scoped provider has no single static instance — use \u003Ccode>moduleRef.resolve()\u003C\u002Fcode> instead, and \u003Ccode>await\u003C\u002Fcode> it.\u003C\u002Fp>",{"id":289,"html":290,"text":290,"type":100,"level":43},"b55","Can I call overrideProvider() after compile()?",{"id":292,"html":293,"type":83},"b56","\u003Cp>No. Every override method has to be chained onto the builder before \u003Ccode>.compile()\u003C\u002Fcode> runs; the compiled \u003Ccode>TestingModule\u003C\u002Fcode> is a finished container.\u003C\u002Fp>",{"id":295,"html":296,"text":296,"type":100,"level":43},"b57","Is overrideProvider the same as jest.mock()?",{"id":298,"html":299,"type":83},"b58","\u003Cp>No, and that's the point. \u003Ccode>jest.mock()\u003C\u002Fcode> patches a module import at the file-system\u002Frequire level, outside Nest's awareness. \u003Ccode>overrideProvider()\u003C\u002Fcode> changes what a token resolves to \u003Cem>inside Nest's own DI graph\u003C\u002Fem>, so every real consumer that constructor-injects it gets the override through the identical resolution path production uses.\u003C\u002Fp>",{"id":301,"html":302,"text":302,"type":100,"level":43},"b59","Does useMocker replace the need for overrideProvider?",{"id":304,"html":305,"type":83},"b60","\u003Cp>No — they compose. Use explicit \u003Ccode>overrideProvider().useValue()\u003C\u002Fcode> for the providers your assertions actually check, and let \u003Ccode>useMocker\u003C\u002Fcode> fill in everything else so you're not hand-writing mocks for providers the test doesn't care about.\u003C\u002Fp>",{"id":307,"html":308,"text":308,"type":100,"level":43},"b61","Do I need createNestApplication() for a unit test?",{"id":310,"html":311,"type":83},"b62","\u003Cp>No. \u003Ccode>moduleRef.get()\u003C\u002Fcode>\u002F\u003Ccode>.resolve()\u003C\u002Fcode> against the compiled \u003Ccode>TestingModule\u003C\u002Fcode> is enough for testing a single provider's logic. \u003Ccode>createNestApplication()\u003C\u002Fcode> is for when the test needs the real HTTP request lifecycle — routing, guards, pipes, filters — not just a provider's method.\u003C\u002Fp>",{"id":313,"html":314,"type":83},"b63","\u003C!-- playground:start -->",{"id":316,"html":317,"text":317,"type":100,"level":31},"b64","🎮 Try it yourself",{"id":319,"html":320,"type":83},"b65","\u003Cp>\u003Cstrong>\u003Ca href=\"https:\u002F\u002Fbestpractic.org\u002Fblog\u002Fnestjs-weekly-testing-provider-overrides\u002Fplayground\">▶️ Open the interactive playground →\u003C\u002Fa>\u003C\u002Fstrong>\u003C\u002Fp>",{"id":322,"html":323,"type":83},"b66","\u003Cp>\u003Cem>Runs right in your browser — poke at it and watch the concept react live.\u003C\u002Fem>\u003C\u002Fp>",{"id":325,"html":326,"type":83},"b67","\u003C!-- playground:end -->",{"id":328,"html":329,"text":329,"type":100,"level":31},"b68","Cheat sheet",{"id":331,"head":332,"rows":336,"type":377},"b69",[333,334,335],"Task","Code","Notes",[337,341,345,349,353,357,361,365,369,373],[338,339,340],"Build a test module","\u003Ccode>await Test.createTestingModule({ providers, imports, controllers }).compile()\u003C\u002Fcode>","Same DI graph shape as a real app module",[342,343,344],"Replace a value\u002Fmock","\u003Ccode>.overrideProvider(Token).useValue(mock)\u003C\u002Fcode>","No DI on the mock itself",[346,347,348],"Replace with a real fake class","\u003Ccode>.overrideProvider(Token).useClass(FakeImpl)\u003C\u002Fcode>","\u003Ccode>FakeImpl\u003C\u002Fcode>'s own constructor is still DI-resolved",[350,351,352],"Replace with a computed value","\u003Ccode>.overrideProvider(Token).useFactory({ factory, inject })\u003C\u002Fcode>","\u003Ccode>inject\u003C\u002Fcode> resolves from the same container",[354,355,356],"Auto-mock everything else","\u003Ccode>.useMocker((token) => ...)\u003C\u002Fcode>","Return \u003Ccode>undefined\u003C\u002Fcode> to let Nest auto-mock; explicit mocks for what you assert on",[358,359,360],"Get a \u003Ccode>DEFAULT\u003C\u002Fcode>-scoped provider","\u003Ccode>moduleRef.get(Token)\u003C\u002Fcode>","Throws for \u003Ccode>REQUEST\u003C\u002Fcode>\u002F\u003Ccode>TRANSIENT\u003C\u002Fcode> scope",[362,363,364],"Get a scoped provider","\u003Ccode>await moduleRef.resolve(Token)\u003C\u002Fcode>","Async; new instance per call unless given the same \u003Ccode>contextId\u003C\u002Fcode>",[366,367,368],"Search outside the local module","\u003Ccode>moduleRef.get(Token, { strict: false })\u003C\u002Fcode>","Widens \u003Cem>search\u003C\u002Fem>, not scope — still can't fetch a scoped provider",[370,371,372],"Override a guard\u002Fpipe\u002Finterceptor\u002Ffilter","\u003Ccode>.overrideGuard(G).useValue({ canActivate: () => true })\u003C\u002Fcode>","Same chain as \u003Ccode>overrideProvider\u003C\u002Fcode>; needs \u003Ccode>createNestApplication()\u003C\u002Fcode> for e2e",[374,375,376],"Swap an entire module","\u003Ccode>.overrideModule(RealModule).useModule(FakeModule)\u003C\u002Fcode>","Heaviest option — use rarely","table",{"id":379,"html":380,"type":83},"b70","\u003C!-- quiz:start -->",{"id":382,"html":383,"text":383,"type":100,"level":31},"b71","🧠 Test yourself",{"id":385,"html":386,"type":83},"b72","\u003Cp>Think it clicked? \u003Cstrong>\u003Ca href=\"https:\u002F\u002Fbestpractic.org\u002Fblog\u002Fnestjs-weekly-testing-provider-overrides\u002Fquiz\">Take the 10-question quiz →\u003C\u002Fa>\u003C\u002Fstrong>\u003C\u002Fp>",{"id":388,"html":389,"type":83},"b73","\u003Cp>\u003Cem>Instant feedback, a hint on every question, and an explanation for each answer — right or wrong.\u003C\u002Fem>\u003C\u002Fp>",{"id":391,"html":392,"type":83},"b74","\u003C!-- quiz:end -->",{"id":394,"html":395,"text":395,"type":100,"level":31},"b75","Key takeaways",{"id":397,"type":106,"items":398,"ordered":18},"b76",[399,400,401,402,403],"\u003Ccode>Test.createTestingModule\u003C\u002Fcode> compiles a \u003Cstrong>real\u003C\u002Fstrong> DI container from the same module metadata your app boots with — it isn't a mock registry.","\u003Ccode>overrideProvider\u003C\u002Fcode> swaps a token's registration \u003Cstrong>before\u003C\u002Fstrong> compilation, so every real consumer still gets wired to it through normal constructor injection.","\u003Ccode>module.get()\u003C\u002Fcode> only reaches \u003Ccode>DEFAULT\u003C\u002Fcode>-scoped providers; \u003Ccode>REQUEST\u003C\u002Fcode> and \u003Ccode>TRANSIENT\u003C\u002Fcode> scope require \u003Ccode>await module.resolve()\u003C\u002Fcode> — a different method, not an option flag.","\u003Ccode>useMocker\u003C\u002Fcode> auto-generates mocks for providers you didn't explicitly override — a time-saver that can also hide a test that never exercises anything real.","Guards, pipes, interceptors, and filters get their own override methods, aimed at end-to-end tests through \u003Ccode>createNestApplication()\u003C\u002Fcode>, not at constructor-injected providers.",{"id":405,"html":406,"type":83},"b77","\u003Cp>That confusing "use resolve() instead of get()" error from the opening isn't NestJS being finicky — it's the same \u003Ccode>Scope\u003C\u002Fcode> contract from the DI container showing up at test time instead of in production, which is exactly where you'd rather find it. Now when a test throws that error, you'll know precisely which of the two questions it's actually asking: is this provider a singleton, or isn't it?\u003C\u002Fp>",{"id":408,"html":409,"type":83},"b78","\u003Cp>What's the trickiest NestJS testing bug you've run into — a scope mismatch, a missing override, something else entirely? Drop it in the comments.\u003C\u002Fp>",{"id":411,"type":412},"b79","divider",{"id":414,"html":415,"type":83},"b80","\u003Cp>🚀 \u003Cstrong>Want more like this?\u003C\u002Fstrong> Every guide, playground, and quiz lives on \u003Cstrong>\u003Ca href=\"https:\u002F\u002Fbestpractic.org\u002F\">bestpractic.org\u003C\u002Fa>\u003C\u002Fstrong> — open it and \u003Cstrong>\u003Ca href=\"https:\u002F\u002Fbestpractic.org\u002F\">sign up free\u003C\u002Fa>\u003C\u002Fstrong> so the next one finds you.\u003C\u002Fp>",{"id":417,"html":418,"type":83},"b81","\u003Cp>\u003Cem>Thanks for reading! Let's stay connected:\u003C\u002Fem>\u003C\u002Fp>",{"id":420,"type":106,"items":421,"ordered":18},"b82",[422,423,424],"⭐ \u003Cstrong>GitHub\u003C\u002Fstrong> — follow me and star the projects: \u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fparsajiravand\">github.com\u002Fparsajiravand\u003C\u002Fa>","💬 \u003Cstrong>Discord\u003C\u002Fstrong> — join the frontend best-practices community: \u003Ca href=\"https:\u002F\u002Fdiscord.gg\u002Fd9KRhuAwQ\">discord.gg\u002Fd9KRhuAwQ\u003C\u002Fa>","📸 \u003Cstrong>Instagram\u003C\u002Fstrong> — frontend best practices, daily: \u003Ca href=\"https:\u002F\u002Fwww.instagram.com\u002Fbestpractice___\u002F\">@bestpractice___\u003C\u002Fa>","A unit test for `OrdersController` calls `Test.createTestingModule({...}).compile()`, then `moduleRef.get(AuditLogService)` to grab the mock and assert it was called. Every other provider in the test resolves without a hitch. This one throws:\n\n```\nError: AuditLogService is a scoped provider. Use \"moduleRef.resolve()\" instead of \"moduleRef.get()\".\n```\n\nNothing about the test setup looks wrong. `AuditLogService` is in the `providers` array. It was overridden with `useValue`. The override even worked — the controller under test is using the mock, not the real thing. The one line that's wrong is the *retrieval* method, and until you understand what `get()` and `resolve()` are each actually reaching into, the fix looks like superstition: \"just switch to `resolve()` and it works,\" without knowing why.\n\nThis is written against **NestJS 12.0.x** (verified September 2026, current `@nestjs\u002Fcore` release). Everything here — `Test.createTestingModule`, the override methods, `get()`\u002F`resolve()` — has been stable across the v9–v12 line; nothing in this article depends on a v12-specific change.\n\n## What you'll learn\n\nBy the end of this article you'll be able to:\n\n- Explain what a NestJS testing module actually *is* — not a mock registry, a real DI container\n- Use `overrideProvider().useValue()\u002F.useClass()\u002F.useFactory()` to swap a dependency without breaking the rest of the module's wiring\n- Know exactly when `module.get()` works and when it throws, and reach for `module.resolve()` correctly when it does\n- Use `useMocker` to stop hand-writing boilerplate mocks — and know when *not* to\n- Override a guard, pipe, interceptor, or filter for an end-to-end test, not just a constructor-injected provider\n\n## Who this is for\n\nYou've written a NestJS service or two, used `@Injectable()` and constructor injection, and you've run `npm test` on a generated Nest project at least once. If you haven't yet read the [NestJS dependency injection](https:\u002F\u002Fdev.to\u002Fparsajiravand\u002Fnestjs-dependency-injection-explained-with-cheat-sheet-4bem) episode of this series, the scope material here (`DEFAULT` vs `REQUEST` vs `TRANSIENT`) will make more sense with that as background — but this article stands on its own.\n\n## Table of contents\n\n- [The problem: mocking a NestJS service the naive way](#the-problem-mocking-a-nestjs-service-the-naive-way)\n- [The mental model: the testing module is a real container](#the-mental-model-the-testing-module-is-a-real-container)\n- [Stage 1: overrideProvider, the smallest correct example](#stage-1-overrideprovider-the-smallest-correct-example)\n- [Stage 2: useFactory, when the mock needs its own dependencies](#stage-2-usefactory-when-the-mock-needs-its-own-dependencies)\n- [Stage 3: useMocker, auto-mocking the rest of the graph](#stage-3-usemocker-auto-mocking-the-rest-of-the-graph)\n- [Stage 4: get() vs resolve(), the scoped-provider gotcha](#stage-4-get-vs-resolve-the-scoped-provider-gotcha)\n- [Stage 5: overriding guards, pipes, interceptors, and filters](#stage-5-overriding-guards-pipes-interceptors-and-filters)\n- [Edge cases and gotchas](#edge-cases-and-gotchas)\n- [Best practices](#best-practices)\n- [FAQ](#faq)\n- [Cheat sheet](#cheat-sheet)\n- [Key takeaways](#key-takeaways)\n\n## The problem: mocking a NestJS service the naive way\n\nSay `OrdersService` depends on `CacheService`:\n\n```typescript\n@Injectable()\nexport class OrdersService {\n  constructor(private readonly cache: CacheService) {}\n\n  async getOrder(id: string) {\n    const cached = await this.cache.get(id);\n    if (cached) return cached;\n    \u002F\u002F ...load from DB, then this.cache.set(id, order)\n  }\n}\n```\n\nThe instinct, coming from plain Node testing, is to skip Nest entirely:\n\n```typescript\n\u002F\u002F The wrong way — bypasses Nest's DI graph completely\nconst fakeCache = { get: jest.fn(), set: jest.fn() };\nconst service = new OrdersService(fakeCache as any);\n```\n\nThis \"works\" for exactly this constructor. It breaks the moment someone adds a second constructor parameter — every call site of `new OrdersService(...)` in every test file needs updating by hand, because you're testing against the *implementation* of the constructor, not the *contract* Nest resolves it through. It also can't test anything that depends on Nest actually wiring the object graph: a guard reading a provider, a module boundary, an `onModuleInit` hook. You've tested a plain JavaScript class, not a NestJS provider.\n\nThe second instinct is `jest.mock('.\u002Fcache.service')`, patching the module import. This fights Nest's instantiation instead of cooperating with it — it works until the service is constructed through `useFactory` or aliased with `useExisting`, at which point the mock and the real DI graph disagree about what `CacheService` even resolves to, and the failure mode is confusing rather than obvious.\n\nNest ships a purpose-built answer to both problems: `@nestjs\u002Ftesting`.\n\n## The mental model: the testing module is a real container\n\n**The mental model:** `Test.createTestingModule({...})` doesn't create a fake, lightweight stand-in for your app — it builds the *exact same kind of DI container* Nest builds when your app boots, from the same module metadata. `overrideProvider(Token)` doesn't monkey-patch anything after the fact; it swaps what `Token` resolves to **before** `.compile()` runs, so when the container is built, every real consumer that constructor-injects that token gets your replacement — automatically, through the same resolution path as production.\n\nThat's the whole idea in one sentence: **override the registration, then let the real container do the wiring.** You never hand-assemble the object graph yourself, so a test can't quietly drift from how the app is actually wired.\n\n```typescript\nconst moduleRef = await Test.createTestingModule({\n  providers: [OrdersService, CacheService],\n})\n  .overrideProvider(CacheService)\n  .useValue(fakeCache)\n  .compile();\n\nconst service = moduleRef.get(OrdersService);\n\u002F\u002F service.cache is `fakeCache` — Nest injected it, you didn't.\n```\n\n**Key concept:** `OrdersService` never mentions the mock. It still says `constructor(private readonly cache: CacheService)`. The override happens one layer up, in how the token is registered — which is exactly why it survives constructor changes that don't touch `CacheService`'s shape.\n\n## Stage 1: overrideProvider, the smallest correct example\n\nThe three replacement methods mirror the ones you already know from provider registration itself:\n\n```typescript\nTest.createTestingModule({ providers: [OrdersService, CacheService] })\n  .overrideProvider(CacheService)\n  .useValue(fakeCache)          \u002F\u002F a plain object\u002Fmock — no DI, no lifecycle\n  .compile();\n\nTest.createTestingModule({ providers: [OrdersService, CacheService] })\n  .overrideProvider(CacheService)\n  .useClass(InMemoryCacheService) \u002F\u002F a real class, its own constructor DI-resolved\n  .compile();\n```\n\n`useValue` is the right default: fast, explicit, and you can inspect `fakeCache.get.mock.calls` directly. Reach for `useClass` when the fake needs real behavior (an in-memory cache that actually stores and evicts), because unlike `useValue`, `useClass` still goes through Nest's own instantiation — its constructor can inject other test doubles too.\n\n## Stage 2: useFactory, when the mock needs its own dependencies\n\nSometimes the fake itself needs something resolved from the container — a config value, another mock, the module ref:\n\n```typescript\nTest.createTestingModule({ providers: [OrdersService, CacheService, ConfigService] })\n  .overrideProvider(CacheService)\n  .useFactory({\n    factory: (config: ConfigService) => new FakeCacheWithTtl(config.get('CACHE_TTL')),\n    inject: [ConfigService],\n  })\n  .compile();\n```\n\n**Key concept:** `inject` is resolved from the *same* container being built — including other overrides. This is the one case where the mock still participates in DI, rather than being a static value dropped in from outside.\n\n## Stage 3: useMocker, auto-mocking the rest of the graph\n\nA module with six providers and you only care about testing one of them means five hand-written `useValue` mocks that add nothing to the assertions. `useMocker` removes that boilerplate: pass it a factory, and Nest calls it for every provider you *didn't* explicitly override, generating a jest auto-mock (every method replaced with `jest.fn()`) by default:\n\n```typescript\nconst moduleRef = await Test.createTestingModule({\n  providers: [OrdersService, CacheService, AuditLogService, MetricsService],\n})\n  .useMocker((token) => {\n    if (token === CacheService) return fakeCache; \u002F\u002F your real, meaningful mock\n    if (typeof token === 'function') return jest.fn(); \u002F\u002F auto-mock the rest\n  })\n  .compile();\n```\n\nThis is genuinely useful for modules with a lot of incidental dependencies. It is also easy to overuse: if `useMocker` quietly auto-mocks the one provider your test is actually supposed to exercise, the test passes for the wrong reason — it never called anything real. Use it to remove noise around the thing you're testing, never to remove the thing you're testing.\n\n## Stage 4: get() vs resolve(), the scoped-provider gotcha\n\nThis is the error from the opening of this article, and it isn't a bug — it's `Scope` doing exactly what it's documented to do.\n\n**`module.get(Token)`** reaches into the container's static registrations — the ones built once at `.compile()` time. That's every `DEFAULT`-scoped (singleton) provider. **`module.resolve(Token)`** is asynchronous, and creates (or looks up) a *request-scoped sub-tree* — which is the only kind of container a `REQUEST`- or `TRANSIENT`-scoped provider can live in.\n\n```typescript\n@Injectable({ scope: Scope.REQUEST })\nexport class AuditLogService { \u002F* ... *\u002F }\n\n\u002F\u002F Throws — a REQUEST-scoped provider has no single static instance to hand back\nmoduleRef.get(AuditLogService);\n\n\u002F\u002F Correct — resolves a fresh instance for this call\nconst auditLog = await moduleRef.resolve(AuditLogService);\n```\n\nTwo details make this behave differently from `get()` in ways that trip people up:\n\n- **It's a Promise.** Forgetting `await` gives you a `Promise\u003CAuditLogService>` that happily passes typechecking in a loosely-typed test and fails at runtime in a confusing spot.\n- **Every call gets a new instance, by default.** Two `moduleRef.resolve(AuditLogService)` calls in the same test return two different objects — because in production, two different HTTP requests would too. If you need the *same* instance twice (to simulate one request touching the provider from two places), pass the same context id explicitly: `ContextIdFactory.create()` once, then `moduleRef.resolve(Token, contextId)` for each call that should share it.\n\n**Key concept:** `get()` vs `resolve()` isn't a style choice — it's `Scope.DEFAULT` vs everything else, the exact distinction from how NestJS resolves providers in production. A test that gets this right is also proof the provider's scope is doing what you think it's doing.\n\n## Stage 5: overriding guards, pipes, interceptors, and filters\n\nEverything so far overrides a **provider** — something resolved through constructor injection. Guards, pipes, interceptors, and filters applied with `@UseGuards()`, `@UsePipes()`, `@UseInterceptors()`, and `@UseFilters()` (or registered globally) are a separate concern in Nest's request pipeline, so `TestingModuleBuilder` ships parallel methods for them, with the identical `useValue`\u002F`useClass`\u002F`useFactory` chain:\n\n```typescript\nconst moduleRef = await Test.createTestingModule({\n  controllers: [OrdersController],\n})\n  .overrideGuard(RolesGuard)\n  .useValue({ canActivate: () => true }) \u002F\u002F always allow, for this test\n  .compile();\n\nconst app = moduleRef.createNestApplication();\nawait app.init();\n\u002F\u002F now use supertest against `app.getHttpServer()` for a real e2e request\n```\n\nThis is the tool for an **end-to-end** test — one that goes through `createNestApplication()` and an actual HTTP request via `supertest`, exercising the real request lifecycle (middleware → guards → interceptors → pipes → handler → interceptors → filters, covered in [the request lifecycle episode](https:\u002F\u002Fdev.to\u002Fparsajiravand\u002Fnestjs-request-lifecycle-explained-with-cheat-sheet-227l) of this series) with just the one guard swapped out. It is the difference between testing \"does `OrdersService.getOrder()` return the right shape\" and \"does a real request to `GET \u002Forders\u002F:id` actually reach the handler.\"\n\n## Edge cases and gotchas\n\n- **Overrides must be declared before `.compile()`.** There is no \"override after the fact\" — the testing module is immutable once built, same as the real app's container.\n- **Overriding module boundaries doesn't undo `exports`.** If `CacheService` isn't exported from the module that owns it, importing that module into your test setup still won't expose it — the same encapsulation rules from a real app apply inside a test.\n- **`{ strict: false }` on `get()` widens the *search*, not the *scope*.** `moduleRef.get(Token, { strict: false })` lets you fetch a provider that lives in a different module in the graph than the one you passed to `createTestingModule` — it does not let `get()` reach a scoped provider. That still needs `resolve()`.\n- **Lifecycle hooks still run.** `onModuleInit`, `onApplicationBootstrap`, and friends fire for real during `.compile()` (and `app.init()` for a full app) exactly as they would in production. A provider that opens a real connection in `onModuleInit` will try to open one in your test too, unless it's the thing you overrode.\n- **`overrideModule` swaps a whole module, not a token.** It's the heaviest override available — useful for replacing an entire `DatabaseModule` with an in-memory test double — and correspondingly rare; reach for `overrideProvider` first.\n\n## Best practices\n\n- **Override the narrowest token that makes the test honest.** Swap `CacheService`, not `OrdersModule` — the more of the real graph you keep, the more the test proves.\n- **Prefer real modules plus `overrideProvider` over hand-built instances.** Let Nest do the constructor wiring; don't reimplement it in a test helper that can drift from the real module.\n- **Reach for `useMocker` to cut noise, not to cut assertions.** If a test can pass without the \"real\" mock ever being asked to do anything, that mock probably shouldn't be auto-generated.\n- **Match the real provider's scope in the fake.** A `useValue` mock standing in for a `REQUEST`-scoped provider is fine for a unit test that doesn't care about per-request identity — but if the article's `resolve()` distinction matters to what you're testing, keep the scope on the override too.\n- **Use `createNestApplication()` sparingly.** It's the right tool for a genuine end-to-end test of routing, guards, and the lifecycle — not the default for testing one service's logic.\n\n## FAQ\n\n### Why does `moduleRef.get()` throw for a provider I know is registered?\n\nBecause it's `DEFAULT`-scoped only. `get()` reads the container's static registrations, built once at `.compile()`. A `REQUEST`- or `TRANSIENT`-scoped provider has no single static instance — use `moduleRef.resolve()` instead, and `await` it.\n\n### Can I call overrideProvider() after compile()?\n\nNo. Every override method has to be chained onto the builder before `.compile()` runs; the compiled `TestingModule` is a finished container.\n\n### Is overrideProvider the same as jest.mock()?\n\nNo, and that's the point. `jest.mock()` patches a module import at the file-system\u002Frequire level, outside Nest's awareness. `overrideProvider()` changes what a token resolves to *inside Nest's own DI graph*, so every real consumer that constructor-injects it gets the override through the identical resolution path production uses.\n\n### Does useMocker replace the need for overrideProvider?\n\nNo — they compose. Use explicit `overrideProvider().useValue()` for the providers your assertions actually check, and let `useMocker` fill in everything else so you're not hand-writing mocks for providers the test doesn't care about.\n\n### Do I need createNestApplication() for a unit test?\n\nNo. `moduleRef.get()`\u002F`.resolve()` against the compiled `TestingModule` is enough for testing a single provider's logic. `createNestApplication()` is for when the test needs the real HTTP request lifecycle — routing, guards, pipes, filters — not just a provider's method.\n\n\u003C!-- playground:start -->\n\n## 🎮 Try it yourself\n\n**[▶️ Open the interactive playground →](https:\u002F\u002Fbestpractic.org\u002Fblog\u002Fnestjs-weekly-testing-provider-overrides\u002Fplayground)**\n\n_Runs right in your browser — poke at it and watch the concept react live._\n\n\u003C!-- playground:end -->\n\n## Cheat sheet\n\n| Task | Code | Notes |\n| --- | --- | --- |\n| Build a test module | `await Test.createTestingModule({ providers, imports, controllers }).compile()` | Same DI graph shape as a real app module |\n| Replace a value\u002Fmock | `.overrideProvider(Token).useValue(mock)` | No DI on the mock itself |\n| Replace with a real fake class | `.overrideProvider(Token).useClass(FakeImpl)` | `FakeImpl`'s own constructor is still DI-resolved |\n| Replace with a computed value | `.overrideProvider(Token).useFactory({ factory, inject })` | `inject` resolves from the same container |\n| Auto-mock everything else | `.useMocker((token) => ...)` | Return `undefined` to let Nest auto-mock; explicit mocks for what you assert on |\n| Get a `DEFAULT`-scoped provider | `moduleRef.get(Token)` | Throws for `REQUEST`\u002F`TRANSIENT` scope |\n| Get a scoped provider | `await moduleRef.resolve(Token)` | Async; new instance per call unless given the same `contextId` |\n| Search outside the local module | `moduleRef.get(Token, { strict: false })` | Widens *search*, not scope — still can't fetch a scoped provider |\n| Override a guard\u002Fpipe\u002Finterceptor\u002Ffilter | `.overrideGuard(G).useValue({ canActivate: () => true })` | Same chain as `overrideProvider`; needs `createNestApplication()` for e2e |\n| Swap an entire module | `.overrideModule(RealModule).useModule(FakeModule)` | Heaviest option — use rarely |\n\n\u003C!-- quiz:start -->\n\n## 🧠 Test yourself\n\nThink it clicked? **[Take the 10-question quiz →](https:\u002F\u002Fbestpractic.org\u002Fblog\u002Fnestjs-weekly-testing-provider-overrides\u002Fquiz)**\n\n_Instant feedback, a hint on every question, and an explanation for each answer — right or wrong._\n\n\u003C!-- quiz:end -->\n\n## Key takeaways\n\n- `Test.createTestingModule` compiles a **real** DI container from the same module metadata your app boots with — it isn't a mock registry.\n- `overrideProvider` swaps a token's registration **before** compilation, so every real consumer still gets wired to it through normal constructor injection.\n- `module.get()` only reaches `DEFAULT`-scoped providers; `REQUEST` and `TRANSIENT` scope require `await module.resolve()` — a different method, not an option flag.\n- `useMocker` auto-generates mocks for providers you didn't explicitly override — a time-saver that can also hide a test that never exercises anything real.\n- Guards, pipes, interceptors, and filters get their own override methods, aimed at end-to-end tests through `createNestApplication()`, not at constructor-injected providers.\n\nThat confusing \"use resolve() instead of get()\" error from the opening isn't NestJS being finicky — it's the same `Scope` contract from the DI container showing up at test time instead of in production, which is exactly where you'd rather find it. Now when a test throws that error, you'll know precisely which of the two questions it's actually asking: is this provider a singleton, or isn't it?\n\nWhat's the trickiest NestJS testing bug you've run into — a scope mismatch, a missing override, something else entirely? Drop it in the comments.\n\n---\n\n🚀 **Want more like this?** Every guide, playground, and quiz lives on **[bestpractic.org](https:\u002F\u002Fbestpractic.org\u002F)** — open it and **[sign up free](https:\u002F\u002Fbestpractic.org\u002F)** so the next one finds you.\n\n*Thanks for reading! Let's stay connected:*\n\n- ⭐ **GitHub** — follow me and star the projects: [github.com\u002Fparsajiravand](https:\u002F\u002Fgithub.com\u002Fparsajiravand)\n- 💬 **Discord** — join the frontend best-practices community: [discord.gg\u002Fd9KRhuAwQ](https:\u002F\u002Fdiscord.gg\u002Fd9KRhuAwQ)\n- 📸 **Instagram** — frontend best practices, daily: [@bestpractice___](https:\u002F\u002Fwww.instagram.com\u002Fbestpractice___\u002F)",{"title":47,"canonical":427,"description":49},"https:\u002F\u002Fbestpractic.org\u002Fblog\u002Fnestjs-weekly-testing-provider-overrides","01a0a630-c856-72d3-bae5-36cc8ebc2527",{"name":430,"part":431,"total":431,"items":432},"NestJS Deep Dive",4,[433,437,442,446],{"slug":434,"title":435,"publishedAt":436,"readingMinutes":51},"nestjs-weekly-request-lifecycle","NestJS Request Lifecycle Explained (with Cheat Sheet)","2026-08-28T17:01:41.941Z",{"slug":438,"title":439,"publishedAt":440,"readingMinutes":441},"nestjs-weekly-dependency-injection-providers-scopes","NestJS Dependency Injection Explained (with Cheat Sheet)","2026-09-13T08:40:18.434Z",14,{"slug":443,"title":444,"publishedAt":445,"readingMinutes":441},"nestjs-weekly-module-encapsulation-exports","NestJS Module Encapsulation Explained (with Cheat Sheet)","2026-09-13T08:40:50.070Z",{"slug":46,"title":47,"publishedAt":52,"readingMinutes":51},{"id":448,"locked":18},"01a0a630-c902-76aa-9cce-cd542c946f7f",[450],{"id":451,"slug":46,"title":452,"_count":453},"01a0a630-c936-700c-99fd-210aa7b61238","NestJS Testing Module: Provider Overrides",{"questions":454},10,[456],{"locale":13,"slug":46},{"id":451,"slug":46,"title":452,"_count":458,"questionCount":454},{"questions":454},[460,464,468,472,476,478,480,484,487,489,492,496],{"slug":461,"name":462,"articles":463},"webdev","Webdev",100,{"slug":465,"name":466,"articles":467},"javascript","Javascript",83,{"slug":469,"name":470,"articles":471},"frontend","Frontend",71,{"slug":473,"name":474,"articles":475},"css","Css",34,{"slug":72,"name":73,"articles":477},28,{"slug":69,"name":70,"articles":479},15,{"slug":481,"name":482,"articles":483},"react","React",12,{"slug":485,"name":486,"articles":483},"performance","Performance",{"slug":66,"name":67,"articles":488},9,{"slug":490,"name":491,"articles":488},"browser","Browser",{"slug":493,"name":494,"articles":495},"accessibility","Accessibility",6,{"slug":497,"name":498,"articles":495},"grammar","Grammar",{"items":500,"meta":558},[501,513,528,543],{"id":45,"slug":46,"title":47,"subtitle":48,"excerpt":49,"coverUrl":50,"locale":13,"readingMinutes":51,"publishedAt":52,"viewCount":502,"likeCount":19,"commentCount":19,"author":503,"vertical":504,"topic":505,"tags":506,"_count":511,"playground":512,"hasQuiz":17,"hasPlayground":17},19,{"id":55,"name":56,"username":57,"avatarUrl":48,"headline":58},{"slug":6,"name":7,"accentFrom":10,"accentTo":11},{"slug":61,"name":62},[507,508,509,510],{"slug":61,"name":62,"color":48},{"slug":66,"name":67,"color":48},{"slug":69,"name":70,"color":48},{"slug":72,"name":73,"color":48},{"assessments":75},{"slug":46},{"id":514,"slug":443,"title":444,"subtitle":48,"excerpt":515,"coverUrl":516,"locale":13,"readingMinutes":441,"publishedAt":445,"viewCount":517,"likeCount":19,"commentCount":19,"author":518,"vertical":519,"topic":520,"tags":521,"_count":526,"playground":527,"hasQuiz":17,"hasPlayground":17},"01a0821b-4733-762d-bf96-b68c7eb140c0","How NestJS module boundaries actually work: what exports really cross, why @Global() isn't a shortcut, and how forwardRef breaks circular module dependencies.","\u002Fmedia\u002Fcovers\u002Fnestjs-weekly-module-encapsulation-exports.png",150,{"id":55,"name":56,"username":57,"avatarUrl":48,"headline":58},{"slug":6,"name":7,"accentFrom":10,"accentTo":11},{"slug":61,"name":62},[522,523,524,525],{"slug":61,"name":62,"color":48},{"slug":66,"name":67,"color":48},{"slug":69,"name":70,"color":48},{"slug":72,"name":73,"color":48},{"assessments":75},{"slug":443},{"id":529,"slug":438,"title":439,"subtitle":48,"excerpt":530,"coverUrl":531,"locale":13,"readingMinutes":441,"publishedAt":440,"viewCount":532,"likeCount":19,"commentCount":19,"author":533,"vertical":534,"topic":535,"tags":536,"_count":541,"playground":542,"hasQuiz":17,"hasPlayground":17},"01a05e06-53b7-7415-9cd3-05504882514b","How the NestJS DI container resolves providers: tokens, module scope, singleton vs request vs transient, and why 'singleton' can still mean two instances.","\u002Fmedia\u002Fcovers\u002Fnestjs-weekly-dependency-injection-providers-scopes.png",115,{"id":55,"name":56,"username":57,"avatarUrl":48,"headline":58},{"slug":6,"name":7,"accentFrom":10,"accentTo":11},{"slug":61,"name":62},[537,538,539,540],{"slug":61,"name":62,"color":48},{"slug":66,"name":67,"color":48},{"slug":69,"name":70,"color":48},{"slug":72,"name":73,"color":48},{"assessments":75},{"slug":438},{"id":544,"slug":434,"title":435,"subtitle":48,"excerpt":545,"coverUrl":546,"locale":13,"readingMinutes":51,"publishedAt":436,"viewCount":547,"likeCount":19,"commentCount":19,"author":548,"vertical":549,"topic":550,"tags":551,"_count":556,"playground":557,"hasQuiz":17,"hasPlayground":17},"01a03cdb-22ef-748a-b555-8071c7a905e6","A complete guide to the NestJS request lifecycle: the exact order middleware, guards, interceptors, pipes, and filters run, and why it matters.","\u002Fmedia\u002Fcovers\u002Fnestjs-weekly-request-lifecycle.png",322,{"id":55,"name":56,"username":57,"avatarUrl":48,"headline":58},{"slug":6,"name":7,"accentFrom":10,"accentTo":11},{"slug":61,"name":62},[552,553,554,555],{"slug":61,"name":62,"color":48},{"slug":66,"name":67,"color":48},{"slug":69,"name":70,"color":48},{"slug":72,"name":73,"color":48},{"assessments":75},{"slug":434},{"page":75,"perPage":559,"total":431,"totalPages":75},7,"\u003Cdiv class=\"shj shj-lang-plain shj-oneline\" data-lang=\"plain\">Error: AuditLogService is a scoped provider. Use \u003Cspan class=\"shj-str\">\"moduleRef.resolve()\"\u003C\u002Fspan> instead of \u003Cspan class=\"shj-str\">\"moduleRef.get()\"\u003C\u002Fspan>.\u003C\u002Fdiv>","\u003Cdiv class=\"shj shj-lang-ts shj-multiline\" data-lang=\"ts\">\u003Cdiv class=\"shj-scroll\">\u003Cdiv class=\"shj-numbers\">\u003Cdiv>1\u003C\u002Fdiv>\u003Cdiv>2\u003C\u002Fdiv>\u003Cdiv>3\u003C\u002Fdiv>\u003Cdiv>4\u003C\u002Fdiv>\u003Cdiv>5\u003C\u002Fdiv>\u003Cdiv>6\u003C\u002Fdiv>\u003Cdiv>7\u003C\u002Fdiv>\u003Cdiv>8\u003C\u002Fdiv>\u003Cdiv>9\u003C\u002Fdiv>\u003Cdiv>10\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"shj-code\">@\u003Cspan class=\"shj-class\">Injectable\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">(\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">)\u003C\u002Fspan>\n\u003Cspan class=\"shj-kwd\">export\u003C\u002Fspan> \u003Cspan class=\"shj-kwd\">class\u003C\u002Fspan> \u003Cspan class=\"shj-class\">OrdersService\u003C\u002Fspan> \u003Cspan class=\"shj-bracket\">{\u003C\u002Fspan>\n  \u003Cspan class=\"shj-kwd\">constructor\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">(\u003C\u002Fspan>\u003Cspan class=\"shj-kwd\">private\u003C\u002Fspan> \u003Cspan class=\"shj-kwd\">readonly\u003C\u002Fspan> cache\u003Cspan class=\"shj-oper\">:\u003C\u002Fspan> \u003Cspan class=\"shj-class\">CacheService\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">)\u003C\u002Fspan> \u003Cspan class=\"shj-bracket\">{\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">}\u003C\u002Fspan>\n\n  \u003Cspan class=\"shj-kwd\">async\u003C\u002Fspan> \u003Cspan class=\"shj-func\">getOrder\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">(\u003C\u002Fspan>id\u003Cspan class=\"shj-type\">: string\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">)\u003C\u002Fspan> \u003Cspan class=\"shj-bracket\">{\u003C\u002Fspan>\n    \u003Cspan class=\"shj-kwd\">const\u003C\u002Fspan> cached \u003Cspan class=\"shj-oper\">=\u003C\u002Fspan> \u003Cspan class=\"shj-kwd\">await\u003C\u002Fspan> \u003Cspan class=\"shj-kwd\">this\u003C\u002Fspan>\u003Cspan class=\"shj-oper\">.\u003C\u002Fspan>cache\u003Cspan class=\"shj-oper\">.\u003C\u002Fspan>\u003Cspan class=\"shj-kwd\">get\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">(\u003C\u002Fspan>id\u003Cspan class=\"shj-bracket\">)\u003C\u002Fspan>;\n    \u003Cspan class=\"shj-kwd\">if\u003C\u002Fspan> \u003Cspan class=\"shj-bracket\">(\u003C\u002Fspan>cached\u003Cspan class=\"shj-bracket\">)\u003C\u002Fspan> \u003Cspan class=\"shj-kwd\">return\u003C\u002Fspan> cached;\n    \u003Cspan class=\"shj-cmnt\">\u002F\u002F ...load from DB, then this.cache.set(id, order)\n\u003C\u002Fspan>  \u003Cspan class=\"shj-bracket\">}\u003C\u002Fspan>\n\u003Cspan class=\"shj-bracket\">}\u003C\u002Fspan>\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fdiv>","\u003Cdiv class=\"shj shj-lang-ts shj-multiline\" data-lang=\"ts\">\u003Cdiv class=\"shj-scroll\">\u003Cdiv class=\"shj-numbers\">\u003Cdiv>1\u003C\u002Fdiv>\u003Cdiv>2\u003C\u002Fdiv>\u003Cdiv>3\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"shj-code\">\u003Cspan class=\"shj-cmnt\">\u002F\u002F The wrong way — bypasses Nest's DI graph completely\n\u003C\u002Fspan>\u003Cspan class=\"shj-kwd\">const\u003C\u002Fspan> fakeCache \u003Cspan class=\"shj-oper\">=\u003C\u002Fspan> \u003Cspan class=\"shj-bracket\">{\u003C\u002Fspan> get\u003Cspan class=\"shj-oper\">:\u003C\u002Fspan> jest\u003Cspan class=\"shj-oper\">.\u003C\u002Fspan>\u003Cspan class=\"shj-func\">fn\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">(\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">)\u003C\u002Fspan>\u003Cspan class=\"shj-oper\">,\u003C\u002Fspan> set\u003Cspan class=\"shj-oper\">:\u003C\u002Fspan> jest\u003Cspan class=\"shj-oper\">.\u003C\u002Fspan>\u003Cspan class=\"shj-func\">fn\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">(\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">)\u003C\u002Fspan> \u003Cspan class=\"shj-bracket\">}\u003C\u002Fspan>;\n\u003Cspan class=\"shj-kwd\">const\u003C\u002Fspan> service \u003Cspan class=\"shj-oper\">=\u003C\u002Fspan> \u003Cspan class=\"shj-kwd\">new\u003C\u002Fspan> \u003Cspan class=\"shj-class\">OrdersService\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">(\u003C\u002Fspan>fakeCache \u003Cspan class=\"shj-kwd\">as\u003C\u002Fspan> any\u003Cspan class=\"shj-bracket\">)\u003C\u002Fspan>;\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fdiv>","\u003Cdiv class=\"shj shj-lang-ts shj-multiline\" data-lang=\"ts\">\u003Cdiv class=\"shj-scroll\">\u003Cdiv class=\"shj-numbers\">\u003Cdiv>1\u003C\u002Fdiv>\u003Cdiv>2\u003C\u002Fdiv>\u003Cdiv>3\u003C\u002Fdiv>\u003Cdiv>4\u003C\u002Fdiv>\u003Cdiv>5\u003C\u002Fdiv>\u003Cdiv>6\u003C\u002Fdiv>\u003Cdiv>7\u003C\u002Fdiv>\u003Cdiv>8\u003C\u002Fdiv>\u003Cdiv>9\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"shj-code\">\u003Cspan class=\"shj-kwd\">const\u003C\u002Fspan> moduleRef \u003Cspan class=\"shj-oper\">=\u003C\u002Fspan> \u003Cspan class=\"shj-kwd\">await\u003C\u002Fspan> \u003Cspan class=\"shj-class\">Test\u003C\u002Fspan>\u003Cspan class=\"shj-oper\">.\u003C\u002Fspan>\u003Cspan class=\"shj-func\">createTestingModule\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">(\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">{\u003C\u002Fspan>\n  providers\u003Cspan class=\"shj-oper\">:\u003C\u002Fspan> \u003Cspan class=\"shj-bracket\">[\u003C\u002Fspan>\u003Cspan class=\"shj-class\">OrdersService\u003C\u002Fspan>\u003Cspan class=\"shj-oper\">,\u003C\u002Fspan> \u003Cspan class=\"shj-class\">CacheService\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">]\u003C\u002Fspan>\u003Cspan class=\"shj-oper\">,\u003C\u002Fspan>\n\u003Cspan class=\"shj-bracket\">}\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">)\u003C\u002Fspan>\n  \u003Cspan class=\"shj-oper\">.\u003C\u002Fspan>\u003Cspan class=\"shj-func\">overrideProvider\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">(\u003C\u002Fspan>\u003Cspan class=\"shj-class\">CacheService\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">)\u003C\u002Fspan>\n  \u003Cspan class=\"shj-oper\">.\u003C\u002Fspan>\u003Cspan class=\"shj-func\">useValue\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">(\u003C\u002Fspan>fakeCache\u003Cspan class=\"shj-bracket\">)\u003C\u002Fspan>\n  \u003Cspan class=\"shj-oper\">.\u003C\u002Fspan>\u003Cspan class=\"shj-func\">compile\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">(\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">)\u003C\u002Fspan>;\n\n\u003Cspan class=\"shj-kwd\">const\u003C\u002Fspan> service \u003Cspan class=\"shj-oper\">=\u003C\u002Fspan> moduleRef\u003Cspan class=\"shj-oper\">.\u003C\u002Fspan>\u003Cspan class=\"shj-kwd\">get\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">(\u003C\u002Fspan>\u003Cspan class=\"shj-class\">OrdersService\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">)\u003C\u002Fspan>;\n\u003Cspan class=\"shj-cmnt\">\u002F\u002F service.cache is `fakeCache` — Nest injected it, you didn't.\u003C\u002Fspan>\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fdiv>","\u003Cdiv class=\"shj shj-lang-ts shj-multiline\" data-lang=\"ts\">\u003Cdiv class=\"shj-scroll\">\u003Cdiv class=\"shj-numbers\">\u003Cdiv>1\u003C\u002Fdiv>\u003Cdiv>2\u003C\u002Fdiv>\u003Cdiv>3\u003C\u002Fdiv>\u003Cdiv>4\u003C\u002Fdiv>\u003Cdiv>5\u003C\u002Fdiv>\u003Cdiv>6\u003C\u002Fdiv>\u003Cdiv>7\u003C\u002Fdiv>\u003Cdiv>8\u003C\u002Fdiv>\u003Cdiv>9\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"shj-code\">\u003Cspan class=\"shj-class\">Test\u003C\u002Fspan>\u003Cspan class=\"shj-oper\">.\u003C\u002Fspan>\u003Cspan class=\"shj-func\">createTestingModule\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">(\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">{\u003C\u002Fspan> providers\u003Cspan class=\"shj-oper\">:\u003C\u002Fspan> \u003Cspan class=\"shj-bracket\">[\u003C\u002Fspan>\u003Cspan class=\"shj-class\">OrdersService\u003C\u002Fspan>\u003Cspan class=\"shj-oper\">,\u003C\u002Fspan> \u003Cspan class=\"shj-class\">CacheService\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">]\u003C\u002Fspan> \u003Cspan class=\"shj-bracket\">}\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">)\u003C\u002Fspan>\n  \u003Cspan class=\"shj-oper\">.\u003C\u002Fspan>\u003Cspan class=\"shj-func\">overrideProvider\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">(\u003C\u002Fspan>\u003Cspan class=\"shj-class\">CacheService\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">)\u003C\u002Fspan>\n  \u003Cspan class=\"shj-oper\">.\u003C\u002Fspan>\u003Cspan class=\"shj-func\">useValue\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">(\u003C\u002Fspan>fakeCache\u003Cspan class=\"shj-bracket\">)\u003C\u002Fspan>          \u003Cspan class=\"shj-cmnt\">\u002F\u002F a plain object\u002Fmock — no DI, no lifecycle\n\u003C\u002Fspan>  \u003Cspan class=\"shj-oper\">.\u003C\u002Fspan>\u003Cspan class=\"shj-func\">compile\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">(\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">)\u003C\u002Fspan>;\n\n\u003Cspan class=\"shj-class\">Test\u003C\u002Fspan>\u003Cspan class=\"shj-oper\">.\u003C\u002Fspan>\u003Cspan class=\"shj-func\">createTestingModule\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">(\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">{\u003C\u002Fspan> providers\u003Cspan class=\"shj-oper\">:\u003C\u002Fspan> \u003Cspan class=\"shj-bracket\">[\u003C\u002Fspan>\u003Cspan class=\"shj-class\">OrdersService\u003C\u002Fspan>\u003Cspan class=\"shj-oper\">,\u003C\u002Fspan> \u003Cspan class=\"shj-class\">CacheService\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">]\u003C\u002Fspan> \u003Cspan class=\"shj-bracket\">}\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">)\u003C\u002Fspan>\n  \u003Cspan class=\"shj-oper\">.\u003C\u002Fspan>\u003Cspan class=\"shj-func\">overrideProvider\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">(\u003C\u002Fspan>\u003Cspan class=\"shj-class\">CacheService\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">)\u003C\u002Fspan>\n  \u003Cspan class=\"shj-oper\">.\u003C\u002Fspan>\u003Cspan class=\"shj-func\">useClass\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">(\u003C\u002Fspan>\u003Cspan class=\"shj-class\">InMemoryCacheService\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">)\u003C\u002Fspan> \u003Cspan class=\"shj-cmnt\">\u002F\u002F a real class, its own constructor DI-resolved\n\u003C\u002Fspan>  \u003Cspan class=\"shj-oper\">.\u003C\u002Fspan>\u003Cspan class=\"shj-func\">compile\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">(\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">)\u003C\u002Fspan>;\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fdiv>","\u003Cdiv class=\"shj shj-lang-ts shj-multiline\" data-lang=\"ts\">\u003Cdiv class=\"shj-scroll\">\u003Cdiv class=\"shj-numbers\">\u003Cdiv>1\u003C\u002Fdiv>\u003Cdiv>2\u003C\u002Fdiv>\u003Cdiv>3\u003C\u002Fdiv>\u003Cdiv>4\u003C\u002Fdiv>\u003Cdiv>5\u003C\u002Fdiv>\u003Cdiv>6\u003C\u002Fdiv>\u003Cdiv>7\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"shj-code\">\u003Cspan class=\"shj-class\">Test\u003C\u002Fspan>\u003Cspan class=\"shj-oper\">.\u003C\u002Fspan>\u003Cspan class=\"shj-func\">createTestingModule\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">(\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">{\u003C\u002Fspan> providers\u003Cspan class=\"shj-oper\">:\u003C\u002Fspan> \u003Cspan class=\"shj-bracket\">[\u003C\u002Fspan>\u003Cspan class=\"shj-class\">OrdersService\u003C\u002Fspan>\u003Cspan class=\"shj-oper\">,\u003C\u002Fspan> \u003Cspan class=\"shj-class\">CacheService\u003C\u002Fspan>\u003Cspan class=\"shj-oper\">,\u003C\u002Fspan> \u003Cspan class=\"shj-class\">ConfigService\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">]\u003C\u002Fspan> \u003Cspan class=\"shj-bracket\">}\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">)\u003C\u002Fspan>\n  \u003Cspan class=\"shj-oper\">.\u003C\u002Fspan>\u003Cspan class=\"shj-func\">overrideProvider\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">(\u003C\u002Fspan>\u003Cspan class=\"shj-class\">CacheService\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">)\u003C\u002Fspan>\n  \u003Cspan class=\"shj-oper\">.\u003C\u002Fspan>\u003Cspan class=\"shj-func\">useFactory\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">(\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">{\u003C\u002Fspan>\n    factory\u003Cspan class=\"shj-oper\">:\u003C\u002Fspan> \u003Cspan class=\"shj-bracket\">(\u003C\u002Fspan>config\u003Cspan class=\"shj-oper\">:\u003C\u002Fspan> \u003Cspan class=\"shj-class\">ConfigService\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">)\u003C\u002Fspan> \u003Cspan class=\"shj-kwd\">=>\u003C\u002Fspan> \u003Cspan class=\"shj-kwd\">new\u003C\u002Fspan> \u003Cspan class=\"shj-class\">FakeCacheWithTtl\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">(\u003C\u002Fspan>config\u003Cspan class=\"shj-oper\">.\u003C\u002Fspan>\u003Cspan class=\"shj-kwd\">get\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">(\u003C\u002Fspan>\u003Cspan class=\"shj-str\">'CACHE_TTL'\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">)\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">)\u003C\u002Fspan>\u003Cspan class=\"shj-oper\">,\u003C\u002Fspan>\n    inject\u003Cspan class=\"shj-oper\">:\u003C\u002Fspan> \u003Cspan class=\"shj-bracket\">[\u003C\u002Fspan>\u003Cspan class=\"shj-class\">ConfigService\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">]\u003C\u002Fspan>\u003Cspan class=\"shj-oper\">,\u003C\u002Fspan>\n  \u003Cspan class=\"shj-bracket\">}\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">)\u003C\u002Fspan>\n  \u003Cspan class=\"shj-oper\">.\u003C\u002Fspan>\u003Cspan class=\"shj-func\">compile\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">(\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">)\u003C\u002Fspan>;\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fdiv>","\u003Cdiv class=\"shj shj-lang-ts shj-multiline\" data-lang=\"ts\">\u003Cdiv class=\"shj-scroll\">\u003Cdiv class=\"shj-numbers\">\u003Cdiv>1\u003C\u002Fdiv>\u003Cdiv>2\u003C\u002Fdiv>\u003Cdiv>3\u003C\u002Fdiv>\u003Cdiv>4\u003C\u002Fdiv>\u003Cdiv>5\u003C\u002Fdiv>\u003Cdiv>6\u003C\u002Fdiv>\u003Cdiv>7\u003C\u002Fdiv>\u003Cdiv>8\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"shj-code\">\u003Cspan class=\"shj-kwd\">const\u003C\u002Fspan> moduleRef \u003Cspan class=\"shj-oper\">=\u003C\u002Fspan> \u003Cspan class=\"shj-kwd\">await\u003C\u002Fspan> \u003Cspan class=\"shj-class\">Test\u003C\u002Fspan>\u003Cspan class=\"shj-oper\">.\u003C\u002Fspan>\u003Cspan class=\"shj-func\">createTestingModule\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">(\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">{\u003C\u002Fspan>\n  providers\u003Cspan class=\"shj-oper\">:\u003C\u002Fspan> \u003Cspan class=\"shj-bracket\">[\u003C\u002Fspan>\u003Cspan class=\"shj-class\">OrdersService\u003C\u002Fspan>\u003Cspan class=\"shj-oper\">,\u003C\u002Fspan> \u003Cspan class=\"shj-class\">CacheService\u003C\u002Fspan>\u003Cspan class=\"shj-oper\">,\u003C\u002Fspan> \u003Cspan class=\"shj-class\">AuditLogService\u003C\u002Fspan>\u003Cspan class=\"shj-oper\">,\u003C\u002Fspan> \u003Cspan class=\"shj-class\">MetricsService\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">]\u003C\u002Fspan>\u003Cspan class=\"shj-oper\">,\u003C\u002Fspan>\n\u003Cspan class=\"shj-bracket\">}\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">)\u003C\u002Fspan>\n  \u003Cspan class=\"shj-oper\">.\u003C\u002Fspan>\u003Cspan class=\"shj-func\">useMocker\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">(\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">(\u003C\u002Fspan>token\u003Cspan class=\"shj-bracket\">)\u003C\u002Fspan> \u003Cspan class=\"shj-kwd\">=>\u003C\u002Fspan> \u003Cspan class=\"shj-bracket\">{\u003C\u002Fspan>\n    \u003Cspan class=\"shj-kwd\">if\u003C\u002Fspan> \u003Cspan class=\"shj-bracket\">(\u003C\u002Fspan>token \u003Cspan class=\"shj-oper\">===\u003C\u002Fspan> \u003Cspan class=\"shj-class\">CacheService\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">)\u003C\u002Fspan> \u003Cspan class=\"shj-kwd\">return\u003C\u002Fspan> fakeCache; \u003Cspan class=\"shj-cmnt\">\u002F\u002F your real, meaningful mock\n\u003C\u002Fspan>    \u003Cspan class=\"shj-kwd\">if\u003C\u002Fspan> \u003Cspan class=\"shj-bracket\">(\u003C\u002Fspan>\u003Cspan class=\"shj-kwd\">typeof\u003C\u002Fspan> token \u003Cspan class=\"shj-oper\">===\u003C\u002Fspan> \u003Cspan class=\"shj-str\">'function'\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">)\u003C\u002Fspan> \u003Cspan class=\"shj-kwd\">return\u003C\u002Fspan> jest\u003Cspan class=\"shj-oper\">.\u003C\u002Fspan>\u003Cspan class=\"shj-func\">fn\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">(\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">)\u003C\u002Fspan>; \u003Cspan class=\"shj-cmnt\">\u002F\u002F auto-mock the rest\n\u003C\u002Fspan>  \u003Cspan class=\"shj-bracket\">}\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">)\u003C\u002Fspan>\n  \u003Cspan class=\"shj-oper\">.\u003C\u002Fspan>\u003Cspan class=\"shj-func\">compile\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">(\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">)\u003C\u002Fspan>;\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fdiv>","\u003Cdiv class=\"shj shj-lang-ts shj-multiline\" data-lang=\"ts\">\u003Cdiv class=\"shj-scroll\">\u003Cdiv class=\"shj-numbers\">\u003Cdiv>1\u003C\u002Fdiv>\u003Cdiv>2\u003C\u002Fdiv>\u003Cdiv>3\u003C\u002Fdiv>\u003Cdiv>4\u003C\u002Fdiv>\u003Cdiv>5\u003C\u002Fdiv>\u003Cdiv>6\u003C\u002Fdiv>\u003Cdiv>7\u003C\u002Fdiv>\u003Cdiv>8\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"shj-code\">@\u003Cspan class=\"shj-class\">Injectable\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">(\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">{\u003C\u002Fspan> scope\u003Cspan class=\"shj-oper\">:\u003C\u002Fspan> \u003Cspan class=\"shj-class\">Scope\u003C\u002Fspan>\u003Cspan class=\"shj-oper\">.\u003C\u002Fspan>\u003Cspan class=\"shj-num\">REQUEST\u003C\u002Fspan> \u003Cspan class=\"shj-bracket\">}\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">)\u003C\u002Fspan>\n\u003Cspan class=\"shj-kwd\">export\u003C\u002Fspan> \u003Cspan class=\"shj-kwd\">class\u003C\u002Fspan> \u003Cspan class=\"shj-class\">AuditLogService\u003C\u002Fspan> \u003Cspan class=\"shj-bracket\">{\u003C\u002Fspan> \u003Cspan class=\"shj-cmnt\">\u002F* ... *\u002F\u003C\u002Fspan> \u003Cspan class=\"shj-bracket\">}\u003C\u002Fspan>\n\n\u003Cspan class=\"shj-cmnt\">\u002F\u002F Throws — a REQUEST-scoped provider has no single static instance to hand back\n\u003C\u002Fspan>moduleRef\u003Cspan class=\"shj-oper\">.\u003C\u002Fspan>\u003Cspan class=\"shj-kwd\">get\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">(\u003C\u002Fspan>\u003Cspan class=\"shj-class\">AuditLogService\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">)\u003C\u002Fspan>;\n\n\u003Cspan class=\"shj-cmnt\">\u002F\u002F Correct — resolves a fresh instance for this call\n\u003C\u002Fspan>\u003Cspan class=\"shj-kwd\">const\u003C\u002Fspan> auditLog \u003Cspan class=\"shj-oper\">=\u003C\u002Fspan> \u003Cspan class=\"shj-kwd\">await\u003C\u002Fspan> moduleRef\u003Cspan class=\"shj-oper\">.\u003C\u002Fspan>\u003Cspan class=\"shj-func\">resolve\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">(\u003C\u002Fspan>\u003Cspan class=\"shj-class\">AuditLogService\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">)\u003C\u002Fspan>;\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fdiv>","\u003Cdiv class=\"shj shj-lang-ts shj-multiline\" data-lang=\"ts\">\u003Cdiv class=\"shj-scroll\">\u003Cdiv class=\"shj-numbers\">\u003Cdiv>1\u003C\u002Fdiv>\u003Cdiv>2\u003C\u002Fdiv>\u003Cdiv>3\u003C\u002Fdiv>\u003Cdiv>4\u003C\u002Fdiv>\u003Cdiv>5\u003C\u002Fdiv>\u003Cdiv>6\u003C\u002Fdiv>\u003Cdiv>7\u003C\u002Fdiv>\u003Cdiv>8\u003C\u002Fdiv>\u003Cdiv>9\u003C\u002Fdiv>\u003Cdiv>10\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"shj-code\">\u003Cspan class=\"shj-kwd\">const\u003C\u002Fspan> moduleRef \u003Cspan class=\"shj-oper\">=\u003C\u002Fspan> \u003Cspan class=\"shj-kwd\">await\u003C\u002Fspan> \u003Cspan class=\"shj-class\">Test\u003C\u002Fspan>\u003Cspan class=\"shj-oper\">.\u003C\u002Fspan>\u003Cspan class=\"shj-func\">createTestingModule\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">(\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">{\u003C\u002Fspan>\n  controllers\u003Cspan class=\"shj-oper\">:\u003C\u002Fspan> \u003Cspan class=\"shj-bracket\">[\u003C\u002Fspan>\u003Cspan class=\"shj-class\">OrdersController\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">]\u003C\u002Fspan>\u003Cspan class=\"shj-oper\">,\u003C\u002Fspan>\n\u003Cspan class=\"shj-bracket\">}\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">)\u003C\u002Fspan>\n  \u003Cspan class=\"shj-oper\">.\u003C\u002Fspan>\u003Cspan class=\"shj-func\">overrideGuard\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">(\u003C\u002Fspan>\u003Cspan class=\"shj-class\">RolesGuard\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">)\u003C\u002Fspan>\n  \u003Cspan class=\"shj-oper\">.\u003C\u002Fspan>\u003Cspan class=\"shj-func\">useValue\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">(\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">{\u003C\u002Fspan> canActivate\u003Cspan class=\"shj-oper\">:\u003C\u002Fspan> \u003Cspan class=\"shj-bracket\">(\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">)\u003C\u002Fspan> \u003Cspan class=\"shj-kwd\">=>\u003C\u002Fspan> \u003Cspan class=\"shj-bool\">true\u003C\u002Fspan> \u003Cspan class=\"shj-bracket\">}\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">)\u003C\u002Fspan> \u003Cspan class=\"shj-cmnt\">\u002F\u002F always allow, for this test\n\u003C\u002Fspan>  \u003Cspan class=\"shj-oper\">.\u003C\u002Fspan>\u003Cspan class=\"shj-func\">compile\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">(\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">)\u003C\u002Fspan>;\n\n\u003Cspan class=\"shj-kwd\">const\u003C\u002Fspan> app \u003Cspan class=\"shj-oper\">=\u003C\u002Fspan> moduleRef\u003Cspan class=\"shj-oper\">.\u003C\u002Fspan>\u003Cspan class=\"shj-func\">createNestApplication\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">(\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">)\u003C\u002Fspan>;\n\u003Cspan class=\"shj-kwd\">await\u003C\u002Fspan> app\u003Cspan class=\"shj-oper\">.\u003C\u002Fspan>\u003Cspan class=\"shj-func\">init\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">(\u003C\u002Fspan>\u003Cspan class=\"shj-bracket\">)\u003C\u002Fspan>;\n\u003Cspan class=\"shj-cmnt\">\u002F\u002F now use supertest against `app.getHttpServer()` for a real e2e request\u003C\u002Fspan>\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fdiv>",{"locked":18,"total":19,"comments":570},[]]