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

Мой подход к использованию мок объектов на проектах

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

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

1. Изоляция тестируемого модуля (Unit-тесты)
   • Для юнит-тестирования отдельных классов или методов без зависимости от внешних систем
   • Пример: тестирование логики обработки данных без реальной базы данных

// Пример мока для репозитория в unit-тесте
@Test
public void testUserService_withMockRepository() {
    // Создаем мок
    UserRepository mockRepo = mock(UserRepository.class);
    
    // Настраиваем поведение
    when(mockRepo.findUserById("123")).thenReturn(new User("123", "Test User"));
    
    // Тестируемый сервис с инъекцией мока
    UserService service = new UserService(mockRepo);
    
    // Выполняем тест
    User result = service.getUserProfile("123");
    
    // Проверяем
    assertEquals("Test User", result.getName());
    verify(mockRepo).findUserById("123"); // Верификация вызова
}

1. Тестирование интеграций с внешними системами
   • Когда внешние API медленные, платные или нестабильные
   • Для эмуляции различных ответов (успешных, ошибочных, таймаутов)

# Пример мока HTTP-клиента в Python
from unittest.mock import Mock, patch

def test_payment_processing():
    # Создаем мок ответа платежного шлюза
    mock_response = Mock()
    mock_response.status_code = 200
    mock_response.json.return_value = {"transaction_id": "txn_123", "status": "success"}
    
    # Патчим HTTP-клиент
    with patch('requests.post', return_value=mock_response) as mock_post:
        result = process_payment(amount=100, currency='USD')
        
        # Проверки
        assert result['success'] == True
        mock_post.assert_called_once()

1. Тестирование edge-cases и ошибок
   • Для симуляции редких или сложно воспроизводимых ситуаций
   • Пример: тестирование обработки сетевых ошибок, таймаутов

Когда мы избегаем моков

1. Интеграционные и end-to-end тесты — здесь мы предпочитаем использовать реальные сервисы или стабы (stubs) вместо моков, чтобы проверить реальное взаимодействие
2. Когда моки усложняют тесты — если для создания мока требуется больше кода, чем сам тест
3. При тестировании сложных бизнес-процессов — где важно проверить именно интеграцию компонентов

Наш стек технологий для мокинга

• Java-проекты: Mockito, EasyMock, PowerMock (для статичных методов)
• Python-проекты: unittest.mock, pytest-mock
• JavaScript/TypeScript: Jest, Sinon.js, ts-mockito
• Универсальные решения: WireMock для мокинга HTTP-сервисов, TestContainers для Docker-контейнеров

Best practices, которые мы соблюдаем

• Принцип "Right-sized mocking" — используем минимально необходимый уровень мокинга
• Четкое именование — mockUserService, stubPaymentGateway, fakeDatabase
• Верификация вызовов — проверяем не только результат, но и взаимодействие
• Избегаем over-mocking — не мокаем то, что можно легко использовать в реальности
• Документирование контрактов — явно описываем ожидаемое поведение моков

Пример многоуровневого подхода

// Разные уровни тестирования с разными подходами
public class MultiLayerTesting {
    // Уровень 1: Unit-тесты с полным мокингом
    @Test
    public void unitTest_withMocks() {
        // Полная изоляция с моками всех зависимостей
    }
    
    // Уровень 2: Интеграционные тесты с частичным мокингом
    @Test
    public void integrationTest_withWireMock() {
        // Реальная БД + моки внешних сервисов через WireMock
    }
    
    // Уровень 3: E2E тесты без моков
    @Test
    public void e2eTest_noMocks() {
        // Полное окружение, только dev-версии внешних сервисов
    }
}

Мета-рефлексия о моках

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

• Неадекватного поведения моков (когда мок не отражает реальное поведение системы)
• Излишней хрупкости тестов (когда изменения в коде ломают множество тестов с моками)
• "Тестирования моков вместо кода" (когда тесты проверяют правильность настройки моков, а не бизнес-логику)

Вывод: Моки — мощный инструмент, который позволяет писать быстрые, изолированные тесты, но требует зрелости команды и четкой стратегии применения. На наших проектах мы используем их там, где это дает максимальную пользу при минимальных рисках для качества тестирования.