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

I>Есть целая методология TDD, которая именно юнит тестирование(и как следствие DI) ставит во главу угла, она популярная, модная, молодежная и все такое.
Она отлично работает для инфраструктуры, почти для любого масштаба, неплохо работает для мелочёвки и абсолютно не работает даже для средних проектов. Чтоб было понятно, что такое средний проект: представь себе типовой биз-кейз в виде 20-страничного документа 12 шрифтом, в котором 90% текста — не вода, а логика, причём высокоуровневая, без расписывания до отдельных инструкций. Представь объём кода для этого документа и умножь этот код на 5 — получишь самый минимум для тестов. И теперь контрольный в голову — таких кейсов несколько десятков на каждого разработчика. TDD сам по себе в таких условиях не катит.

Поэтому только вытаскивание всего что можно в инфраструктуру (которую как раз покрывать юнит-тестами), только ассерты по всему коду и только интеграционные тесты для бизнес-логики (для проверки результата и для того, чтобы заставить сработать ассерты.

I>Я к примеру несколько проектов сделал с поголовным DI и тысячами юнит тестов.
Не, тысяча юнит-тестов — это вообще ни о чём. Это типовой объём тестов за пару месяцев для команды из двух-трёх человек. Если мы конечно про инфраструктурную часть говорим.

I>Но вот как понять, насколько оно себя оправдывает — неясно.
Так у вас сам код, получается, особой ценности не имеет. В смысле, его можно переписать, не заморачиваясь с совместимостью. Это немножко обесценивает тесты, да.
А вот когда упавший тест показывает, что мы поломали поведение и это поймано на самом раннем этапе, ещё до коммита кода — вот это приятно.



I> — БД. Она должна быть, в ней должны быть подготовлены корректные данные для каждого теста. Их надо корректно инсертать и чистить. Это все время. При паре тысяче тестов время выполнения может лихко затянуться на полчаса, что очень нехорошо.
Ну так это обязательно, особенно если запросы нетривиальные, какие ещё варианты-то?

Отлично работает комбинация CI-сервер + SSD + MS SQL Dev edition. Минуты, но никак не полчаса. Иначе уже есть повод профилировать и убирать узкие места. Ну и тысяча интеграционных тестов — это уже много. По соотношению к простым юнит-тестам их обычно хорошо если 1 к 20.


I> Кроме того зачастую очень легко устроить race conditions при параллельном запуске тестов — передерутся из-за данных в базе, что в свою очередь может вынудить запускать их последовательно, что опять таки бьет по времени исполнения.
Ну да. Исхитриться можно с разбиением по группам, но какая альтернатива-то?


I> — Конфигурация. Если тестировать большую подсистему, то для прогона типичного сценария надо исполнить танец нанайских мальчиков инициализации системы. Зачастую это больно и тяжело.
Не, эт тяжело только на первых порах, затем решается тем или иным способом. Для больших проектов для интеграционных тестов инфраструктуру вообще запускают локальной службой, чтоб не ждать, пока оно заведётся. Это конечно ещё сложнее и требует отдельного этапа при сборке чтоб закинуть туда свежие assemblies, но иногда по-другому никак. Впрочем, сейчас в моде быстрое развёртывание / запуск, внедренцы очень просят. Поэтому потихоньку переползаем со всех костылей на стандартное API, но чтоб оно не тормозило.


I>А если внутри используются переменные типа HttpContext.Current или же DateTime.Now, то вечер перестает быть томным — проинициализировать их корректно больно, неприятно и не всегда возможно.
В бизнес-логике??? Да ну нафиг, расстреливать за такое. Оно ж потом, если потребуется поправить (например, пользователь просит печать форм заранее, за пару дней до фактической даты) — кучу кода придётся просматривать и править.