Use Test.createTestingModule() to create an isolated module, replace real providers with jest mock objects using useValue, compile the module, then retrieve the service under test with module.get(). This allows testing service logic without needing a real database, HTTP client, or other infrastructure.
Use useValue with jest.fn() mocks — avoids spinning up real infrastructure.
module.get(Token) retrieves the instantiated provider from the test container.
Assign the mock to a variable so you can configure return values per test with mockResolvedValue or mockReturnValue.
For providers from imported modules use .overrideProvider(Token).useValue(mock) instead of redeclaring them.
You have a simple NestJS service that depends on a ConfigService. Walk me through how you would write a unit test for a method that reads a config value.
If you forget to provide a mock for an injected dependency, what error will you see when the test runs, and how do you fix it?
Imagine you need to add a new method to an existing service that calls an external API client injected via the constructor. How would you structure the unit test to isolate the service logic and simulate different API responses?
During a code review you notice the test suite is flaky because the mock for a database repository returns undefined on some runs. How would you debug and stabilize the mock implementation?
You are leading a team that is refactoring several services to share a common logging provider. What testing strategy would you adopt to ensure each service's unit tests remain fast and reliable while the shared provider is mocked?
When scaling the codebase, you notice the number of mock files is growing unmanageable. How would you redesign the testing approach for injected dependencies to reduce duplication and improve maintainability?
At the architecture level, how would you design a testing framework for a large NestJS monorepo so that unit tests for services with deep dependency trees stay isolated, and what trade‑offs does your approach have?
If the organization decides to migrate from Jest to a different test runner, what impact does that have on the way you mock injected providers, and how would you plan the migration to minimize risk?