Интеграция по сравнению с поблочным тестированием
Я разрабатываю с Grails. Так как платформа загрузит данные, и полностью спугнул пружинный контекст, я нахожу, что пишу много интеграционных тестов на сервисы. Позвольте мне перефразировать это: Я нахожу, что не пишу модульных тестов на услуги, только интеграционные тесты. Действительно ли это - плохая идея? Единственный недостаток я проследил, - то, что мои тесты берут немного дольше для выполнения.
Я действительно использую поблочное тестирование на контроллерах, как в контроллере я тестирую различные потоки приложения, типы результата, логику перенаправления, и т.д. Но большинство тестов, которые я пишу, является интеграционными тестами. Это кажется повреждением от традиции тесты J2EE, где главным образом модульные тесты записаны.
редактирование - чтобы быть ясным, я не пишу интеграционные тесты, потому что код является так сложным, только интеграционные тесты сделают. Я пишу интеграционные тесты, потому что легче протестировать все вместе, так как платформа дает Вам так. Я действительно дразню определенные вещи, как то, если сервис сотрудничает с acegi authenticationService, я дразню это. Я также дразню каждый раз, когда мы взаимодействуем с веб-сервисом, потому что Вы имеете к тому, для получения теста, который работает без специальной установки.
3 ответа
Я четко вижу тенденцию к увеличению количества функциональных тестов и меньшему количеству модульных тестов, особенно для компонентов с сильным подключением и низким уровнем логики. Если я реализую сложный алгоритм в определенном классе, я обычно пишу для него модульные тесты, но если сложность связана с интеграцией с другими компонентами (что очень часто бывает), модульные тесты не стоят хлопот.
Как правило, важной мерой является покрытие кода.
Проведение интеграционных тестов может быть выгодным, если глобальный интерфейс более стабилен (менее подвержен изменениям).
Вы можете использовать фиктивный фреймворк, чтобы изолировать различные части ваших сервисов для индивидуального тестирования. Вместо того, чтобы полагаться на массивный контекст Spring, напрямую создайте экземпляр своего класса обслуживания и заполните зависимости, не имеющие прямого отношения к тесту, с помощью имитаций. Вам может потребоваться небольшой рефакторинг, чтобы отделить ваши зависимости, но обычно это будет к лучшему. Это может привести к написанию все большего количества небольших тестов вместо того, чтобы полагаться на несколько крупных интеграционных тестов.
Я нахожусь в похожей ситуации, когда многие установленные тесты на самом деле являются интеграционными, и изменить это в будущем может быть сложно, но возможно.