Когда не использовать интеграционные тесты

Question

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

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

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

Answer 1

Когда вы не планируете подключать ваше приложение к чему-либо «реальному»; никаких реальных контейнеров, баз данных, ресурсов или реальных услуг. Вот что должен проверить интеграционный тест; что все работает правильно вместе.

Answer 2

Простое и короткое правило: тестируйте в интеграционном тесте, что ломает из-за интеграции , и тестируйте остальное в модульных тестах в изоляции .

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

Answer 3

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