How do you unit-test a module that uses a dynamic module dependency in NestJS?

Use Test.createTestingModule() and provide mock values for the tokens that the dynamic module would have registered. This avoids spinning up the real dynamic module — which might connect to a real database — while still testing the service logic correctly.

Unit testing a service that depends on a dynamic module token

Testing strategy for dynamic module dependencies:

1
Provide mock values for the tokens the dynamic module registers, not the module itself.
2
This isolates the test from infrastructure — no real database, HTTP client, or external service needed.
3
Use overrideProvider() when importing the real module graph but needing to swap one provider.
4
Export all token constants from your dynamic modules so tests can reference them without magic strings.

Difficulty: 5/10

Topics: Dynamic Modules, TestingModule, Provider Override

Scenario Questions

0-2 years experience

1
You have a NestJS service that depends on a LoggerModule imported via LoggerModule.forRoot({ level: 'debug' }). How would you write a unit test for the service without pulling in the real LoggerModule?
2
If you forget to call .compile() on the TestingModule when testing a module that uses a dynamic dependency, what error would you see and how would you fix it?

2-5 years experience

1
During a sprint you added ConfigModule.forRoot({ envFilePath: '.env' }) to a feature module, and existing unit tests for a dependent service started failing. Walk me through how you'd debug and adjust the tests.
2
Explain the trade‑offs between using Test.createTestingModule with .overrideProvider versus providing a mock implementation directly in the imports array when dealing with a dynamic module.

5-8 years experience

1
Our monorepo contains several feature modules that each import a shared dynamic DatabaseModule.forRootAsync(...). We need to keep unit test suites fast. How would you design a testing strategy that isolates each module while avoiding repeated heavy setup?
2
When mocking a dynamic module that registers providers based on runtime configuration, what edge cases can cause the mock to diverge from production behavior, and how would you mitigate them?

8+ years experience

1
We plan to migrate many existing dynamic modules to a new plugin architecture. From a testing perspective, what changes would you propose to the current unit‑testing approach to ensure long‑term maintainability and cross‑team consistency?
2
How would you establish guidelines for mocking dynamic modules across multiple services to prevent hidden coupling and ensure that integration tests still catch configuration errors?

Follow-up Questions

❓What would you do if the dynamic module registers providers conditionally at runtime?
❓How do you verify that your mock still reflects the contract of the real module?
❓Can you share a tip for keeping test suites fast when many modules depend on the same dynamic import?