Что представляет собой интеграционный тест

Question

У меня есть свои юнит-тесты. Каждый метод тестирования проверяет логический блок функциональности в моей системе. В моем модульном тесте внешние зависимости (db, file и т. Д.) Рассматриваются с использованием Mocks и Fakes.

Теперь я не уверен на 100%, как мне подойти к интеграционному тесту. Должен ли я повторить модульные тесты и заменить их фактическими ресурсами (БД, файлы и т. Д.) Или я должен тестировать вещи более низкого уровня, такие как:

1) Может пинговать базу данных
2) Может извлечь одну запись
3) Файл существует
и т.д ...

Мне кажется, что на этом этапе мне следует избегать логики бизнеса, так как большая часть этого должна была быть сделана в Юните, верно?

Спасибо

РЕДАКТИРОВАТЬ: Я немного ленив в составлении своего вопроса, что я также хотел знать, если мне нужно было проверить бизнес-логику на этапе интеграции, то как мне настроить свои наборы тестов, чтобы минимизировать повторение тестового кода. Взять, к примеру:

[TestMethod] //Unit Tests
public void CanGetData()
{
IRepository rep = new MockRepository();
var result = rep.GetData();
Assert.IsTrue(result != null)
}

[TestMethod] //Integration Test
public void CanGetData()
{
IRepository rep = new Repository(); //real repository
var result = rep.GetData();
Assert.IsTrue(result != null)
}

Какая структура теста у вас работает? Используете ли вы модульную тестовую сборку непосредственно в своем проекте интеграции и внедряете в нужные ресурсы?

Answer 1

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

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

Фактические ресурсы вашей системы (БД, файлы и т. Д.) Должны быть введены в ваш набор тестов в какой-то момент, хотя не в ваших тестах unit . Большинство людей считают интеграционные тесты подходящим местом для включения ваших ресурсов. Обратите внимание, что включение ресурсов среды в ваш набор тестов может быть довольно сложным делом. Кроме того, это определенно замедлит ваши интеграционные тесты.

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

Answer 2

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

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

Answer 3

YMMV очень с определениями здесь. ИМХО термин «модульное тестирование» пострадал от языкового дрейфа . (См. Мой пост в блоге об этом для получения дополнительной информации).

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

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

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

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

Надеюсь, это поможет.

Answer 4

Модульные тесты проверяют, работает ли отдельный компонент. «компонент», как в «мельчайшая вещь, которую вы можете построить и что-то делает». Они проверяют внутреннюю работу компонента.

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

Обычно линия между ними немного плавная. Вы поместите «can class X сохранится сам» в модульном тесте (несмотря на то, что это действительно интеграционный тест).

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

Обратите внимание, что оба теста могут (и должны) быть автоматизированы.

Answer 5

Чтобы ответить на ваш отредактированный вопрос, (вы можете перефразировать или разбить его на отдельный вопрос целиком ...) вы определенно хотите разделить вопросы и определенно хочет использовать внедрение зависимостей . Изолировать зависимости и вводить их, используя конфигурацию; это позволяет вам менять объекты в конфигурации, а не в коде. Таким образом вы полностью исключите инициализацию объектов из своего тестового кода. (Вы также используете конфигурацию для промежуточных и производственных сред ...)

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