В чём разница между модульным, интеграционным и приёмочным тестированием?

Разница между модульным, интеграционным и приёмочным тестированием

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

Модульное тестирование (Unit Testing)

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

• Объект тестирования: Изолированный фрагмент кода.
• Основная цель: Убедиться, что конкретная функция или метод возвращает ожидаемый результат для заданного набора входных данных. Фокус на логике кода и обработке граничных условий.
• Кто выполняет: Разработчики (программисты), реже — инженеры по автоматизации тестирования.
• Когда выполняется: Наиболее часто — во время разработки (TDD — Test-Driven Development) или сразу после написания кода. Выполняется очень часто, иногда по несколько раз в день.
• Степень изоляции: Максимальная. Модуль тестируется в полной изоляции от других модулей, внешних зависимостей (база данных, файловая система, сетевые вызовы) и пользовательского интерфейса. Для этого активно используются заглушки (stubs), макеты (mocks) и фейки (fakes).

Пример модульного теста (на Python):

# Тестируемая функция (модуль)
def calculate_discount(price, discount_percent):
    if discount_percent < 0 or discount_percent > 100:
        raise ValueError("Скидка должна быть в диапазоне от 0 до 100")
    return price * (1 - discount_percent / 100)

# Модульный тест с использованием pytest
def test_calculate_discount_normal():
    assert calculate_discount(1000, 10) == 900

def test_calculate_discount_zero():
    assert calculate_discount(1000, 0) == 1000

def test_calculate_discount_invalid_negative():
    with pytest.raises(ValueError):
        calculate_discount(1000, -5)

Интеграционное тестирование (Integration Testing)

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

• Объект тестирования: Группа взаимодействующих модулей, сервисы, база данных, внешние API.
• Основная цель: Выявить дефекты на стыках интегрированных компонентов. Проверить корректность передачи данных, согласованность интерфейсов (API-контрактов), работу с реальными или тестовыми базами данных, кэшем, очередями сообщений.
• Кто выполняет: Инженеры по автоматизации тестирования или разработчики.
• Когда выполняется: После успешного прохождения модульных тестов и сборки компонентов в более крупные блоки. Может выполняться на этапе непрерывной интеграции (CI).
• Степень изоляции: Низкая или отсутствует. Тестируются реальные взаимодействия. Зависимости (например, тестовая БД) часто поднимаются в контейнерах (Docker) или используются выделенные тестовые среды.

Пример сценария интеграционного теста:

• Сценарий: Проверка функции "Создать заказ".
• Интеграция: Модуль UI/API -> Бизнес-логика (формирование заказа) -> Модуль работы с базой данных (сохранение заказа) -> Внешний платежный шлюз (симуляция).
• Дефекты, которые можно найти: Несоответствие формата данных между сервисами, ошибки транзакций в БД, таймауты при сетевом взаимодействии.

Приёмочное тестирование (Acceptance Testing)

Приёмочное тестирование — это высший уровень, который проводится для определения, удовлетворяет ли система бизнес-требованиям и готова ли к передаче заказчику или выпуску в продакшн.

• Объект тестирования: Готовая, полностью интегрированная система в среде, максимально приближенной к production.
• Основная цель: Подтвердить, что система решает задачи пользователя (заказчика) и соответствует всем оговоренным функциональным и нефункциональным требованиям (User Stories, Use Cases). Это формальная проверка на соответствие критериям приёмки (Acceptance Criteria).
• Кто выполняет: Конечные пользователи, продукт-менеджеры, бизнес-аналитики или QA-инженеры в роли пользователя. Часто выделяют UAT (User Acceptance Testing).
• Когда выполняется: На финальных стадиях цикла разработки (перед релизом), после успешного интеграционного тестирования.
• Степень изоляции: Отсутствует. Тестируется вся система "как есть".
• Особенность: Фокус смещен с "технической корректности" на ценность для бизнеса и удобство использования (UX).

Пример критерия приёмочного тестирования:

• User Story: Как зарегистрированный пользователь, я хочу сбросить свой пароль, чтобы получить доступ к аккаунту, если я его забыл.
• Acceptance Criteria (и сценарий приёмочного теста):

    1.  Пользователь нажимает "Забыли пароль?" на странице входа.
    2.  Вводит свой зарегистрированный email и нажимает "Отправить инструкции".
    3.  Получает письмо со ссылкой для сброса пароля на указанный email (проверка интеграции с почтовым сервисом).
    4.  Переходит по ссылке, вводит новый пароль, подтверждает его.
    5.  **ОЖИДАЕМЫЙ РЕЗУЛЬТАТ:** Система отображает сообщение об успешном изменении пароля, и пользователь может войти в систему с новым паролем.

Итоговая сравнительная таблица

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