1. Integration-driven. Изначально делаем тест интеграционным, используя реальные реализации зависимостей. При необходимости что-нибудь застабить/замокать подменяем необходимые зависимости на (внимание!) стабы/моки соответственно.
2. Unit-driven. Изначально делаем юнит-тест, а значит стабим/мокаем все зависимости. При необходимости заменяем некоторые зависимости реальными реализациями
3. Mixed. Основую логику тестируем unit-тестами, но пишем один-два интеграционных теста на основные сценарии.
Пост навеян вопросом на StackOverflow. Мне особенно симпатичен ответ ThomasArdal (который за mixed-вариант): хоть TDD и способствует использованию второго подхода, ничто не мешает в конце написать интеграционный тест. К сожалению, я пока в основном использую первый подход (медленный, но надежный), но потихоньку буду переходить к третьему.
А что по этому поводу думают мои дорогие читатели?
6 комментариев:
Такой еще вопрос был: http://stackoverflow.com/questions/5609508/asp-net-mvc3-and-entity-framework-code-first-architecture
Угу, тоже познавательно
Вопрос кажется капитанским, нет? :)
Не переходя к конкретике и реальным граничным случаям, против пункта 3 не попрешь :) Можно спорить только о процентном количесиве интеграционных против юнит тестов.
Ну почему же? На этот счет есть очень много мнений. И если 3-й вариант и кажется самым логичным, то уж точно не всем :)
кондитерские изделия и десерты готовим дома http://vkysno-doma.blogspot.com/
Отправить комментарий