11 / 12

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

Difficulty: 5/10
Dynamic Modules, TestingModule, Provider Override

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. 1

    Provide mock values for the tokens the dynamic module registers, not the module itself.

  2. 2

    This isolates the test from infrastructure — no real database, HTTP client, or external service needed.

  3. 3

    Use overrideProvider() when importing the real module graph but needing to swap one provider.

  4. 4

    Export all token constants from your dynamic modules so tests can reference them without magic strings.

Scenario Questions

0-2 years experience

  1. 1You 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. 2If 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. 1During 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. 2Explain 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. 1Our 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. 2When 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. 1We 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. 2How 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?
Share

Share via WhatsApp, X, Facebook, LinkedIn or copy link. Open Graph preview enabled.