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

S>>В самых тяжёлых случаях — moq/ms fakes/NSubstitute etc.
I>Дык вот если не будет DI, то моки из вышеперечисленных либ по простому прокинуть в тестируемый класс не получится.

Тут полтопика путает DI с IoC, так что вы в хорошей компании

Сорри за подколку. Если серьёзно, то оформление инфраструктурного API в виде интерфейсов и DI — вещи ортогональные. К первому рано или поздно приходят во всех более-менее крупных проектах. Для второго за редкими исключениями нет никаких причин кроме как "прочитал, хочу попробовать". Тесты — это лишь отмазка и не более того. Если ваш код приходится менять именно ради тестов, то это у вас уже следствие вылезло. Первопричина в 100% случаев — бардак в проекте. Его и надо лечить.


I>Не проще и не дешевле. И писать тяжелей среднестатистическому деву(автоматизаторы вообще отдельная профессия), и дебажить(ну там к примеру рандомные тормоза http, которые локально не репродьясятся валят тесты на серваке), и ранаются они гораздо дольше. А если есть много интеграций с третьесторонними сервисами, то все становится.

Так тут тоже путаница с терминологией Давайте не путать интеграционные тесты (всё то же тестирование API, только на уровне крупных блоков, а не отдельных типов) и автотесты/ui-тестирование (aka blackbox testing — используем исключительно публичные интерфейсы продукта, UI — если ничего другого нет). Вы пишете про второе, я — про первое
Последнее — это делянка QA и разработчикам там делать особо нечего, только исправлять места, которые плохо поддаются тестированию.