Здравствуйте, Sinix, Вы писали:

S>В самых тяжёлых случаях — moq/ms fakes/NSubstitute etc. Во всех остальных проще и дешевле использовать интеграционные тесты. Те же юнит-тесты, только вся инфраструктура уже заведена и доступна к использованию.

Может у тебя специфика такая. У меня, как правило, ситуация обратная. Юнит-тесты писать проще и дешевле, чем интеграционные. И исполняются они на порядки быстрее. А бывало и так, что хороший интеграционный тест в принципе невозможен. И самое интересное вылезает в процессе пуско-наладки.

S>Оно хоть и немного гемморойней на начальном этапе, но зато в итоге не будет такого, что тесты зелёные, а вот работать — упс.

В идеале хорошо и то и то иметь зеленым.

S>Я ж выше писал Большие проекты с необходимостью поддерживать плагины от сторонних разработчиков. Вот там DI творит чудеса. Самый простой пример — расширения студии. Сравни число расширений для кода, который подрубается через MEF (редактор по сути) и то, для чего нормальное API только в процессе (lang services, debugging api etc).

ИМХО, DI-контейнеры — это все-таки весьма частный случай DI, а не его родная ниша. Простейший DI (в виде передачи функции или объекта в другую) существовал задолго до того, как начали массово лепить контейнеры везде, где только можно (и чаще всего не нужно). Только никто его так не называл.