NestJS ConfigService and external client provider override precedence in Test.createTestingModule

Answer

When a module creates an external HTTP client during initialization, the client will read ConfigService values in its constructor or factory. If you only override the ConfigService after the client has been instantiated, the client already holds the original configuration and may still attempt real HTTP calls. Therefore, the safest and most reliable approach is to override the client provider token itself with a test double.

Why overriding the client provider is required

• Providers are resolved once per module during onModuleInit.
• A client that reads configuration in its constructor captures the values at that moment.
• Changing ConfigService values later does not affect the already‑created client.
• Overriding the provider guarantees that every injection receives the mock, regardless of when ConfigService is overridden.

Choosing the override target

1. Global ConfigModule: The provider is registered in the global registry. You can override it anywhere in the test module with .overrideProvider(ClientToken).useValue(mockClient) and it will replace the global instance.
2. Non‑global ConfigModule: The client provider is scoped to the module that declares it. In this case, you must target that module in Test.createTestingModule:

   
   Test.createTestingModule({
     imports: [YourModule],
     providers: [
       { provide: ClientToken, useValue: mockClient },
     ],
   }).overrideProvider(ClientToken).useValue(mockClient);
   

@nestjs/testing version differences

• v8 and earlier: overrideProvider(...).useValue(...) is the standard method.
• v9+: useMocker is introduced for auto‑mocking but it still requires an explicit overrideProvider for the client if you want to avoid real HTTP calls. useMocker only mocks providers that are not already overridden.

Practical steps for a test module

1. Create a mock client that implements the same interface:

   
   const mockClient = {
     get: jest.fn().mockResolvedValue({ data: 'mock' }),
     post: jest.fn().mockResolvedValue({ data: 'mock' }),
   };
   

2. Build the testing module, overriding the client provider:

   
   const module = await Test.createTestingModule({
     imports: [YourModule],
   }).overrideProvider(ClientToken).useValue(mockClient).compile();
   

3. Retrieve the client and assert it is the mock:

   
   const client = module.get(ClientToken);
   expect(client).toBe(mockClient);
   

4. Run your unit tests; any call to client.get or client.post will hit the mock, and no real HTTP requests will be made.

Optional: Override ConfigService values

If the client also uses configuration at runtime (e.g., for retries or headers), you can still override ConfigService values in the test module to control those aspects. However, this is an additional safety net, not a replacement for overriding the client provider.

Diagnostic question

To refine the recommendation further, could you confirm whether the client provider is defined via a factory (possibly async) or as a class constructor? Knowing this will help ensure the mock matches the expected shape and lifecycle.

Conclusion

Override the external HTTP client provider token directly in your test module. This guarantees that the mock is used regardless of when configuration values are set or whether the ConfigModule is global. Use overrideProvider for NestJS v8 and earlier, and pair it with useMocker in v9+ if you want automatic provider mocking but still need to guard the client explicitly.