О чем тебе говорят слова "модульное", "интеграционное", "приемочное" и "системное"

Мой подход к классификации тестирования по уровням

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

Детальная расшифровка каждого уровня

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

• Цель: Проверка корректности работы минимальной неделимой части приложения — функции, метода или класса. Изоляция от зависимостей (баз данных, внешних сервисов, других модулей) здесь ключева.
• Кто выполняет: Разработчики, реже — инженеры по автоматизации тестирования.
• Ключевые технологии: Фреймворки типа JUnit (Java), pytest (Python), NUnit (.NET). Для изоляции используются Mock-объекты, стабы и шпионы (например, с помощью Mockito или unittest.mock).
• Пример на Python (pytest):

  # Тестируемая функция (модуль)
  def calculate_discount(price, discount_percent):
      if discount_percent < 0 or discount_percent > 100:
          raise ValueError("Скидка должна быть от 0 до 100%")
      return price * (1 - discount_percent / 100)
  
  # Модульный тест
  def test_calculate_discount():
      # Проверка основного функционала
      assert calculate_discount(1000, 10) == 900
      # Проверка граничного значения
      assert calculate_discount(1000, 0) == 1000
      # Проверка обработки ошибки
      with pytest.raises(ValueError):
          calculate_discount(1000, -5)
  

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

• Цель: Проверка взаимодействия и корректной передачи данных между несколькими модулями, компонентами или внешними системами (например, API, база данных, микросервисы).
• Кто выполняет: Автоматизаторы тестирования и разработчики.
• Ключевой фокус: Интерфейсы, контракты API, поток данных, обработка ошибок при общении между сервисами.
• Пример сценария: Проверить, что сервис UserService корректно сохраняет данные в базе через UserRepository, а затем успешно получает их обратно, включая негативные сценарии (например, попытка сохранения дублирующейся записи).

3. Системное тестирование (System Testing)

• Цель: Полная и всесторонняя проверка собранного приложения как цельного продукта в среде, максимально приближенной к боевой. Тестируются нефункциональные требования: производительность, надежность, безопасность, совместимость, удобство использования.
• Кто выполняет: Команда тестирования (QA Engineers).
• Ключевые виды: Это широкое понятие, включающее:

    *   **Функциональное системное тестирование** (сквозные пользовательские сценарии, `E2E`).
    *   **Нагрузочное/стресс-тестирование** (с помощью **JMeter**, **k6**, **Gatling**).
    *   **Тестирование безопасности** (сканирование уязвимостей).
    *   **Тестирование на совместимость** с разными браузерами, ОС, устройствами.

• Пример: Провести сквозной тест-кейс "Оформление заказа от выбора товара до получения подтверждения на email", имитируя действия реального пользователя в браузере.

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

• Цель: Окончательная проверка того, что система удовлетворяет бизнес-требованиям и готова к выпуску. Это "зеленый свет" от заказчика или продукт-менеджера.
• Кто выполняет: Заказчик, бизнес-аналитик, продукт-менеджер или QA-инженер от их лица. Часто проводится как User Acceptance Testing (UAT).
• Формат: Выполнение заранее согласованных критериев приемки (Acceptance Criteria), часто сформулированных в стиле BDD (Behavior-Driven Development).
• Пример на Gherkin (язык для BDD):

  # Это критерий приемки для функции логина
  Функция: Аутентификация пользователя
      Чтобы получить доступ к личному кабинету
      Как зарегистрированный пользователь
      Я должен иметь возможность войти в систему
  
      Сценарий: Успешный вход с валидными данными
          Дано я нахожусь на странице входа
          Когда я ввожу свой корректный email и пароль
          И нажимаю кнопку "Войти"
          Тогда я должен быть перенаправлен на главную страницу
          И увидеть приветственное сообщение "Добро пожаловать, [Имя]"
  

Синтез: Как это работает вместе на практике

Рассмотрим разработку функционала "Добавление товара в корзину" в интернет-магазине:

1. Модульные тесты: Разработчик пишет тесты для каждого метода класса CartService (добавить товар, рассчитать итого) и для класса Product, изолируя их от базы данных.
2. Интеграционные тесты: Автоматизатор проверяет, что CartService корректно общается с ProductRepository для получения актуальной цены и с DatabaseService для сохранения состояния корзины.
3. Системные тесты (E2E): QA-инженер выполняет сквозной сценарий в браузере через Selenium или Cypress: открыть сайт -> найти товар -> нажать "В корзину" -> убедиться, что счетчик корзины обновился. Параллельно проводятся проверки производительности при добавлении 1000 товаров одновременно.
4. Приемочное тестирование: Продукт-менеджер перед релизом проверяет, что весь пользовательский путь (от поиска товара до оформления заказа) работает именно так, как было задумано в спецификации, и дает согласие на выпуск в продакшн.

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