Какие плюсы и минусы интеграционных тестов?

Интеграционные тесты: Плюсы и минусы

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

Плюсы интеграционных тестов

1. Реальные сценарии

Тестируют то, как система работает в реальности, выявляя проблемы на границах компонентов.

def test_user_creation_to_email():
    user = create_user(db, name="John", email="john@example.com")
    assert user.id is not None
    assert email_queue.count() == 1  # Письмо отправилось

2. Ловят ошибки unit тестов

Проверяют проблемы на стыке компонентов: JSON парсинг, таймауты, схема БД.

def test_api_integration():
    response = client.get("/api/users/123")
    assert response.status_code == 200
    assert response.json()["name"] == "John"

3. Документируют сценарии

Хороший интеграционный тест показывает, как должна работать система.

def test_complete_order_workflow():
    order = order_service.create(user_id=123, items=[...])
    payment = payment_service.process(order.id)
    assert order.status == "paid"

4. Проверяют race conditions

Отлавливают проблемы с параллельным доступом к ресурсам.

def test_concurrent_balance_updates():
    with ThreadPoolExecutor(max_workers=10) as executor:
        futures = [executor.submit(balance.increment, 50) for _ in range(10)]
    assert balance.get() == 600  # Может быть меньше!

5. Проверяют производительность

Тестируют реальные сценарии под нагрузкой.

def test_bulk_creation_performance():
    start = time.time()
    for i in range(1000):
        user_service.create(db, name=f"User{i}")
    assert time.time() - start < 5.0

Минусы интеграционных тестов

1. Медленные

Требуют реальных ресурсов — БД, сетевые задержки.

# Unit: < 1ms | Интеграционный: 500-5000ms
response = client.post("/api/users")  # Реальная БД

Следствие:

• Тесты скучны в запуске
• Медленнее CI/CD
• Разработчики реже запускают локально

2. Сложнее писать и поддерживать

Много зависимостей, каждый тест требует подготовки окружения.

def test_signup(db, email_service, auth_service):
    # Нужно подготовить БД, сервис почты, токены авторизации
    pass

3. Нестабильные

Падают случайно из-за внешних факторов:

• БД недоступна
• Таймауты
• Грязные данные с предыдущего теста
• Email сервис недоступен

4. Трудно debug'ить

Много точек отказа — что произошло? Ошибка логики? БД? Сеть?

5. Затратные по ресурсам

Нужны реальные PostgreSQL, Redis, S3, Docker контейнеры.

6. Сложнее локально воспроизвести

Работает в CI, но падает дома — разные версии, окружение.

Тестовая пирамида

      E2E (10%)
   Интеграция (20%)
     Unit (70%)

Стратегия:

• 70% юнит (быстро, много)
• 20% интеграционные (средне)
• 10% E2E (медленно, критичные)

def test_add():
    assert add(2, 3) == 5

def test_user_creation():
    user = service.create(db, name="John")
    assert db.find(user.id) is not None

def test_full_signup():
    response = client.post("/signup", {"email": "john@example.com"})
    assert response.status_code == 201

Когда использовать

✅ Интеграционные тесты для:

• Критичные workflow
• API endpoints
• Взаимодействие БД + кэша
• Race conditions
• Performance-critical код

❌ НЕ используй для:

• Простая бизнес-логика
• Utilities функции
• Каждый edge case

Best Practices

@pytest.fixture
def db():
    db = create_test_db()
    yield db
    db.drop_all()

def test_1(db):
    create_user(db, "user1")

def test_payment(mock_stripe):
    # Мокируй внешние сервисы
    pass

Интеграционные тесты необходимы, но используй их дозировано — баланс критичен!