Интеграция против модульного тестирования

Question

Я развиваюсь с Grails.Поскольку среда будет загружать данные и полностью очищать контекст Spring, я обнаружил, что пишу множество интеграционных тестов для сервисов.Позвольте мне перефразировать это: я не пишу модульные тесты для сервисов, только интеграционные тесты.Это плохая идея?Единственным недостатком, который я вижу, является то, что мои тесты занимают немного больше времени.

Я использую модульное тестирование на контроллерах, так как в контроллере я тестирую различные потоки приложений, типы результатов, логику перенаправления и т. Д. Но большинство тестов, которые я пишу, являются интеграционными тестами.Это кажется отходом от традиционных тестов J2EE, где в основном написаны юнит-тесты.

edit- чтобы быть понятным, я не пишу интеграционные тесты, потому что код настолько сложен, что подойдут только интеграционные тесты.Я пишу интеграционные тесты, потому что все вместе проще тестировать, так как фреймворк дает вам так много.Я действительно высмеиваю определенные вещи, например, если сервис сотрудничает с сервисом acegi authentication, я высмеиваю это.Я также высмеиваю всякий раз, когда мы взаимодействуем с веб-сервисом, потому что вам нужно, чтобы получить тест, который запускается без специальной настройки.

Answer 1

Я отчетливо вижу тенденцию к увеличению функциональных тестов и уменьшению количества модульных тестов, в частности, для компонентов с большим количеством соединений и низким уровнем логики.Если я реализую сложный алгоритм в определенном классе, я обычно пишу для него модульные тесты, но если сложность связана с интеграцией с другими компонентами (что очень часто бывает), модульные тесты не стоят хлопот.

Answer 2

Как правило, важной мерой является покрытие кода.

Может быть полезно проводить интеграционные тесты, если глобальный интерфейс более стабилен (меньше подвержен изменениям).

Answer 3

Вы должны проверить как можно скорее, потому что вы хотите, чтобы ошибки появлялись как можно скорее, в идеале, пока наш код все еще находится под вашим собственным контролем. Чем позже будет обнаружена ошибка, тем выше будет стоимость исправления.

Если вы демонстрируете нетривиальную логику, вам следует проверить логику основных путей принятия решений с помощью модульных тестов, а также выявить эту логику и взаимодействие с внешними зависимостями в интеграционных тестах.

Если вы одинокий разработчик или работаете в небольшой команде, иногда трудно увидеть различие между модульными и интеграционными тестами. Если вы находитесь в среде, где несколько команд работают над одним продуктом, предполагается, что логика в вашем коде уже проверена (модульное тестирование), и теперь вы хотите увидеть, как модули работают друг с другом (интеграционный тест) ,

Не следует загружать слишком много данных в интеграционном тесте, потому что вы откладываете тестирование на более поздний этап в своем проекте или среде разработки, и рано или поздно вы обнаружите, что обнаруживаете ошибки, как только Код покинул ваш стол. Это будет означать задержку всего и, возможно, выпуска продукта, пока вы исправляете то, что могли и должны были обнаружить ранее.

Answer 4

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

Я нахожусь в подобной ситуации, когда многие установленные тесты действительно являются интеграционными тестами, и это может быть трудным, но не невозможным,чтобы изменить это в будущем.