Что такое Dependency Injection (DI)

Что проверяют

Понимаете ли вы, зачем разработчики так делают и что это меняет для тестирования.

Как отвечать

Dependency Injection это когда объект не создаёт свои зависимости сам, а получает их снаружи, обычно через конструктор. Класс зависит от интерфейса, а не от конкретной реализации.

Для тестирования это ключевая вещь. Именно благодаря DI вместо настоящего платёжного шлюза или внешнего сервиса можно подставить заглушку и проверить поведение без сети и без денег. Без неё зависимость зашита внутрь, и модульный тест написать нечем.

Что это даёт на практике: заглушки и моки в модульных тестах, подмена окружения на стенде, включение и выключение интеграций конфигурацией, а не сборкой.

Способы внедрения: конструктор (по умолчанию), свойство (для необязательных), метод (когда зависимость нужна в одном вызове). Контейнер (Spring, Hilt, NestJS) собирает граф автоматически, но сам принцип от библиотеки не зависит.

Где спотыкаются

Считают, что DI это библиотека. Передать зависимость параметром это уже DI.

Не могут связать DI с тестируемостью, хотя это её главный практический смысл.

Путают заглушку и мок: первая просто отдаёт готовый ответ, второй ещё и проверяет, что его вызвали.

Не знают, что жёстко зашитый синглтон внутри класса делает модульный тест невозможным.