Информация об изменениях

Сообщение Re[5]: Паттерны внедрения зависимостей от 05.04.2016 10:53

Изменено 05.04.2016 10:54 Sinix

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

S>>На практике вся разница в том, что мы не воссоздаём всё окружение для каждого теста в отдельности. Вместо этого поднимается инстанс сервиса с включенными отладочными ассертами и дальше он топится пачкой проверок, записанных в виде стандартных юнит-тестов. Как опция, сами тесты подгружаются в инстанс сервиса и используют внутреннее API сервиса, т.е. тот самый servicelocator.


I>У меня для таких вещей есть специальный конструктор в конфигураторе IOC, куда я могу передавать тестовые сервисы. Тогда поднимается вся инфраструктура, но с выбранными мною сервисами (моками например).


Мы о разных вещах тут говорим

Во-первых, моки не спасут в ситуации, когда у тебя с десяток сервисов и нужно убедиться, что вся эта кухня работает _вместе_. Что обычно и интересует клиента

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

Ну и в-третьих, IOC-фреймворк начинает только мешать, если тестируемый код начинает создавать объекты, которые тоже надо заполнить из IOC-контейнера (и на них цепочка только начинается). В конечном итоге необходимость протаскивать контейнер по всей цепочке превращает за
в ещё одну импровизацию на тему serviceLocatior.
Re[5]: Паттерны внедрения зависимостей
Здравствуйте, ionoy, Вы писали:

S>>На практике вся разница в том, что мы не воссоздаём всё окружение для каждого теста в отдельности. Вместо этого поднимается инстанс сервиса с включенными отладочными ассертами и дальше он топится пачкой проверок, записанных в виде стандартных юнит-тестов. Как опция, сами тесты подгружаются в инстанс сервиса и используют внутреннее API сервиса, т.е. тот самый servicelocator.


I>У меня для таких вещей есть специальный конструктор в конфигураторе IOC, куда я могу передавать тестовые сервисы. Тогда поднимается вся инфраструктура, но с выбранными мною сервисами (моками например).


Мы о разных вещах тут говорим, если я тебя правильно понял

Во-первых, моки не спасут в ситуации, когда у тебя с десяток сервисов и нужно убедиться, что вся эта кухня работает _вместе_. Что обычно и интересует клиента

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

Ну и в-третьих, IOC-фреймворк начинает только мешать, если тестируемый код начинает создавать объекты, которые тоже надо заполнить из IOC-контейнера (и на них цепочка только начинается). В конечном итоге необходимость протаскивать контейнер по всей цепочке превращает IOC в ещё одну импровизацию на тему serviceLocatior.