Когда допустимо объединять несколько проверок в один тест-кейс?

Объединение нескольких проверок в один тест-кейс допустимо, но должно применяться осознанно, чтобы не нарушать основные принципы хорошего тестового дизайна.

✅ Когда это уместно (Best Practice):

• End-to-End (E2E) сценарии: Проверка полного пользовательского потока (например, "регистрация → логин → добавление товара в корзину → оформление заказа").
• Smoke-тесты: Быстрая проверка критически важной функциональности после сборки.
• Проверки одного состояния или объекта: Несколько атрибутов одного объекта, которые логично проверять вместе (например, все поля профиля пользователя после его загрузки).

Пример объединенного E2E-теста (Python, pytest):

def test_complete_user_registration_flow():
    """E2E-сценарий: регистрация нового пользователя и проверка профиля."""
    # 1. Регистрация
    reg_response = api.register(email="new@user.com", password="Qwerty123")
    assert reg_response.status_code == 201
    user_id = reg_response.json()["id"]

    # 2. Активация (имитация перехода по ссылке из письма)
    activate_response = api.activate_user(user_id)
    assert activate_response.status_code == 200

    # 3. Логин и получение токена
    login_response = api.login(email="new@user.com", password="Qwerty123")
    assert login_response.status_code == 200
    auth_token = login_response.json()["token"]

    # 4. Проверка данных профиля
    profile_response = api.get_profile(token=auth_token)
    assert profile_response.status_code == 200
    profile_data = profile_response.json()
    assert profile_data["email"] == "new@user.com"
    assert profile_data["isActive"] is True

⚠️ Риски и когда следует избегать:

• Нарушение принципа "Один тест — одна ответственность": При падении такого теста сложнее локализовать, какая именно часть функционала сломана.
• Сложность поддержки: Большие тесты становятся хрупкими и трудными для чтения.
• Для модульных и интеграционных тестов: Предпочтительна изоляция и независимость проверок.

Рекомендация: Объединяйте проверки, когда они представляют собой единый бизнес-сценарий. Для атомарных проверок (валидация поля, проверка одного метода API) всегда пишите отдельные тесты.