Ответ 1

Рассмотрим такой метод, как этот PerformPayment(double amount, PaymentService service);

Единичным тестом будет тест, в котором вы создадите макет для аргумента service.

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

Ответ 2

Модульные тесты - это тесты того, что тестируемый код находится внутри фактического класса. Другие зависимости этого класса игнорируются или игнорируются, поскольку основное внимание уделяется проверке кода внутри класса.

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

Я приведу пример. У вас есть приложение Spring, и вы провели множество модульных тестов, чтобы гарантировать, что бизнес-логика работает правильно. Отлично. Но какие тесты вы должны гарантировать:

• Ваша служба приложений может запуститься
• Ваш объект базы данных отображается правильно
• У вас есть все необходимые аннотации, работающие, как и ожидалось
• Ваш фильтр работает правильно
• Ваш API принимает какие-то данные
• Ваша основная функция действительно работает в базовом сценарии
• Ваш запрос к базе данных работает как положено
• Etc...

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

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

Немного любопытно, что в Maven есть специальный плагин для интеграционных тестов: maven failsafe plugin, который выполняет тестовые классы, имя которых заканчивается на IT. Пример: UserIT.java.

Путаница в том, что означает Интеграционный тест

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

Это может быть только проблемой именования, но у нас нет тестов (что я понимаю как интеграционные тесты), которые сопутствуют необходимости пунктов, описанных выше. Напротив, мы переходим от определения модульных тестов (только тестовый класс) к "интеграционному" тесту (в целом реальные системы работают). Так что же в этом центре, если не интеграционные тесты?

Вы можете прочитать больше об этой путанице в этой статье Мартина Фаулера. Термин "интеграционные тесты" он разделяет на два значения: "широкие" и "узкие" интеграционные тесты:

narrow integration tests

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

broad integration tests

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

Ответ 3

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

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

Ответ 4

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

Ответ 5

Вот пара ограничений, которые удовлетворяет хороший unit тест. Для удовлетворения этих ограничений также требуется хороший проверяемый код.

1. Нет ввода/вывода - диск или сеть
2. Только одно утверждение (если несколько, они должны быть незначительными вариациями друг друга)
3. Не использует (накрывает) гораздо более производственный код, чем тот, который он утверждает

Эти ограничения обычно не применяются к интеграционным тестам.