Каковы преимущества и недостатки автоматизированных модульных тестов по сравнению с автоматизированными интеграционными тестами?

Question

Недавно мы добавили автоматизированные тесты в наши существующие Java-приложения.

Что у нас есть

Большинство этих тестов являются интеграционными тестами, которые могут охватывать стек вызовов, таких как: -

1. HTTP-сообщение в сервлете
2. Сервлет проверяет запрос и вызывает бизнес-уровень
3. Бизнес-уровень делает кучу вещей через hibernate и т. Д. И обновляет некоторые таблицы базы данных
4. Сервлет генерирует некоторый XML, запускает его через XSLT для получения HTML-ответа.

Затем мы проверяем, что сервлет ответил правильным XML и что в базе данных есть правильные строки (наш экземпляр Oracle разработки). Эти строки затем удаляются.

У нас также есть несколько небольших модульных тестов, которые проверяют вызовы одного метода.

Все эти тесты выполняются как часть наших ночных (или adhoc) сборок.

Вопрос

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

С какими проблемами мы можем столкнуться при таком подходе?

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

Answer 1

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

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

Answer 2

Вас может заинтересовать этот вопрос и связанные с ним ответы тоже. Вы можете найти мое дополнение к ответам, которые уже были даны здесь (это правильный английский?)