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

S>Сорри за подколку. Если серьёзно, то оформление инфраструктурного API в виде интерфейсов и DI — вещи ортогональные. К первому рано или поздно приходят во всех более-менее крупных проектах. Для второго за редкими исключениями нет никаких причин кроме как "прочитал, хочу попробовать". Тесты — это лишь отмазка и не более того. Если ваш код приходится менять именно ради тестов, то это у вас уже следствие вылезло. Первопричина в 100% случаев — бардак в проекте. Его и надо лечить.
Есть целая методология TDD, которая именно юнит тестирование(и как следствие DI) ставит во главу угла, она популярная, модная, молодежная и все такое. Я к примеру несколько проектов сделал с поголовным DI и тысячами юнит тестов. Тяжеловестности добавляет(процентов 20 времени в среднем на задачу), но в общем и целом — полет нормальный.
Вот чего я не нашел пока — это каких бы то ни было метрик полезности этого хозяйства. Юнит тесты ранаются, все зелененькое. Может когда у кого из девов локально чота ломается и фиксается. В случае рефакторинга эти самые тесты пачками выкидываются и пачками же переписываются. Но вот как понять, насколько оно себя оправдывает — неясно.

S>Так тут тоже путаница с терминологией Давайте не путать интеграционные тесты (всё то же тестирование API, только на уровне крупных блоков, а не отдельных типов) и автотесты/ui-тестирование (aka blackbox testing — используем исключительно публичные интерфейсы продукта, UI — если ничего другого нет). Вы пишете про второе, я — про первое
Я не путаю, автотесты — это подвид интеграционных тестов
Но ок, давай про крупноблочные тесты.
Тут есть 2 засады:
— БД. Она должна быть, в ней должны быть подготовлены корректные данные для каждого теста. Их надо корректно инсертать и чистить. Это все время. При паре тысяче тестов время выполнения может лихко затянуться на полчаса, что очень нехорошо. Кроме того зачастую очень легко устроить race conditions при параллельном запуске тестов — передерутся из-за данных в базе, что в свою очередь может вынудить запускать их последовательно, что опять таки бьет по времени исполнения.
— Конфигурация. Если тестировать большую подсистему, то для прогона типичного сценария надо исполнить танец нанайских мальчиков инициализации системы. Зачастую это больно и тяжело. А если внутри используются переменные типа HttpContext.Current или же DateTime.Now, то вечер перестает быть томным — проинициализировать их корректно больно, неприятно и не всегда возможно.