Используешь ли на проекте стабы

Использование стабов в проектах QA Automation

Да, я активно использую стабы (stubs) на проектах QA Automation, поскольку они являются неотъемлемой частью стратегии изолированного тестирования (особенно в контексте unit-тестов и интеграционных тестов) и помогают создавать предсказуемые и стабильные тестовые сценарии. Стаб — это упрощённая, контролируемая реализация зависимости, которая возвращает заранее определённые, жёстко заданные данные в ответ на вызовы во время теста. В отличие от моков (mocks), которые ещё и верифицируют поведение (т.е. как именно взаимодействовали с ними), стабы в первую очередь подменяют реальные объекты, чтобы устранить нежелательные побочные эффекты, такие как обращения к сети, базам данных, внешним API или сложным внутренним модулям.

Ключевые сценарии применения стабов

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

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

    *   **Платёжные шлюзы:** Стаб может имитировать успешный платёж, отказ по недостатку средств или ошибку сети, не списывая реальные деньги.
    *   **Сторонние API (SMTP, SMS, геолокация):** Стаб возвращает предопределённый успешный ответ или конкретную ошибку, что позволяет проверить, как наше приложение обрабатывает различные кейсы.
    *   **Сложные или медленные внутренние сервисы:** Например, стаб сервиса рекомендаций может возвращать фиксированный список товаров, ускоряя выполнение тестов.

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

Практический пример использования стаба на Python (с unittest.mock)

Допустим, у нас есть класс PaymentProcessor, который зависит от внешнего PaymentGateway. Мы хотим протестировать логику обработки платежа, не делая реальных запросов.

# production_code.py
class PaymentGateway:
    def charge(self, amount, token):
        # Сложная логика реального запроса к внешнему API
        # Возвращает словарь с результатом
        pass

class PaymentProcessor:
    def __init__(self, gateway):
        self.gateway = gateway

    def process_payment(self, amount, token):
        if amount <= 0:
            raise ValueError("Amount must be positive")
        result = self.gateway.charge(amount, token)
        if result['status'] == 'success':
            return True
        else:
            raise PaymentError(result['message'])

# test_code.py
import unittest
from unittest.mock import Mock, patch
from production_code import PaymentProcessor, PaymentGateway, PaymentError

class TestPaymentProcessor(unittest.TestCase):

    def test_process_payment_success(self):
        # 1. СОЗДАНИЕ СТАБА: Создаём экземпляр Mock, который будет подменять реальный PaymentGateway.
        stub_gateway = Mock(spec=PaymentGateway)

        # 2. НАСТРОЙКА СТАБА: Задаём жёстко определённое возвращаемое значение для метода charge.
        # В данном случае это успешный ответ.
        expected_response = {'status': 'success', 'transaction_id': 'txn_12345'}
        stub_gateway.charge.return_value = expected_response

        # 3. ИНЪЕКЦИЯ СТАБА: Передаём стаб в тестируемый объект.
        processor = PaymentProcessor(stub_gateway)

        # 4. ВЫПОЛНЕНИЕ ТЕСТА: Вызываем метод, который использует стаб.
        result = processor.process_payment(100.0, 'tok_visa')

        # 5. ПРОВЕРКА УТВЕРЖДЕНИЙ: Убеждаемся, что логика отработала корректно.
        self.assertTrue(result)
        # Также можно проверить, что метод charge был вызван с ожидаемыми аргументами.
        stub_gateway.charge.assert_called_once_with(100.0, 'tok_visa')

    def test_process_payment_failure(self):
        stub_gateway = Mock(spec=PaymentGateway)
        # Настраиваем стаб на возврат ошибки от платёжного шлюза.
        stub_gateway.charge.return_value = {'status': 'failed', 'message': 'Insufficient funds'}

        processor = PaymentProcessor(stub_gateway)

        # Ожидаем, что наша логика корректно выбросит исключение при ошибке платежа.
        with self.assertRaises(PaymentError) as context:
            processor.process_payment(50.0, 'tok_mastercard')

        self.assertIn('Insufficient funds', str(context.exception))

Преимущества и инструменты

Преимущества:

• Скорость: Тесты, использующие стабы, выполняются на порядки быстрее, так как не требуют реальных сетевых/баз данных операций.
• Надёжность: Исключается влияние "плавающих" факторов внешнего мира (просадки сети, недоступность сервисов, изменение данных).
• Фокус: Позволяют тестировать именно целевую функциональность, а не её зависимости.
• Простота отладки: Поскольку данные предсказуемы, найти причину падения теста гораздо легче.

Популярные инструменты и библиотеки:

• Python: unittest.mock (встроенная библиотека), pytest-mock.
• JavaScript/TypeScript: Jest (встроенные моки/стабы), Sinon.js.
• Java: Mockito, EasyMock.

Важное замечание: Стабы — мощный инструмент, но ими не следует злоупотреблять. Чрезмерное их применение может привести к тому, что тесты будут проверять работу самих стабов, а не реальной системы. Поэтому важно комбинировать изолированные тесты со стабами и интеграционными/end-to-end тестами, которые проверяют взаимодействие с реальными зависимостями в контролируемых средах (например, на staging). Это обеспечивает баланс между скоростью, стабильностью и достоверностью тестового покрытия.