nest: [bug] 6.0.1 Dependency Injection in Testing Module

I’m submitting a…


[ ] Regression 
[x ] Bug report
[ ] Feature request
[ ] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead post your question on Stack Overflow.

Current behavior

It is not possible to inject dependencies into modules in test scenarios using the overrideProvider mechanism

Expected behavior

It should be possible to inject dependencies into modules in test scenarios using the overrideProvider mechanism

Minimal reproduction of the problem with instructions

https://github.com/WonderPanda/nest-testing-bug Just run yarn test:e2e and you’ll see the following output:

Nest can't resolve dependencies of the BugModule (?). Please make sure that the argument at index [0] is available in the BugModule context.

      at Injector.lookupComponentInExports (../node_modules/@nestjs/core/injector/injector.js:180:19)

Prior to version 6, it was simple to provide mocks for dependencies (both for other providers/controllers as well as modules) using the overrideProvider fluent methods. The change introduced here https://github.com/nestjs/nest/pull/1722/files with an additional check for this.hasProvider(toReplace) seems to have broken those scenarios. It’s a very common scenario in both the libraries I’ve built and the tests that I’ve written to want to be able to supply a provider without it needing to have been previously available in the module context.

The attached repo shows a simple example of this where there is a module that requires a dependency in it’s constructor:

@Module({})
export class BugModule {
  constructor(@Inject('BugProvider') private readonly bugProvider: string) {}
}

but there doesn’t appear to be any mechanism now to be able to achieve this in tests.

I’m a little concerned with the initial launch of version 6 as this and the bug that was fixed as part of 6.0.1 are both core testing scenarios that have come up very often in mine and my team’s use of NestJS. It seems like there’s a gap right now in tests that actually validate that the TestingModule works properly and I’m hesitant to suggest people try version 6 until this is addressed.

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Comments: 16 (9 by maintainers)

Most upvoted comments

I’ll provide more detailed information shortly 😃

Maybe the documentation is misleading. My first approach for our unit test (isolated tests) was to use catsController = new CatsController(catsService); and not Test.createTestingModule. But because of the documentation, my team convinced me that we should use Test.createTestingModule and I am always in favor to follow the doc. I guess, we need to clarify the doc to make this more understandable. Maybe you could move the Testing utilities section inside of End-to-end testing. Or if you want to keep it after the Unit testing section, you could put a hint “In the most cases, you won’t need Test.createTestingModule for unit testing”. Or something like that, but yeah, writing docs is always super difficult -.-

https://docs.nestjs.com/fundamentals/testing#unit-testing

We didn’t make use of any existing Nest testing utility so far. Since we have manually taken care of instantiating tested classes, above test suite has nothing to do with Nest. This type of testing is called isolated tests.

These are two different types of tests. In the most cases, you won’t need Test.createTestingModule.

@kamilmysliwiec could you elaborate on the current best practice for 6.0? We’re in the situation that’ we’d like to overrideProvider a globally provided Config-injectable. This does no longer work with v6. We could refactor the tests to just list { provide: Config, useValue: mockConfig } in the providers of the testing-module, instead of using overrideProvider like we used to.

Is this still viable?