Приведи пример когда срабатывает TimeoutException

TimeoutException: пример из мира интеграционного тестирования

TimeoutException — это исключение, которое возникает, когда операция не завершается в течение установленного временного интервала. В контексте QA и автоматизированного тестирования, мы часто сталкиваемся с ним при работе с асинхронными операциями, сетевыми запросами или взаимодействием с динамическими элементами интерфейса. Рассмотрим конкретный, типичный пример, основанный на реальной практике.

Контекст: тестирование регистрации пользователя через API с мок-сервером

Представьте, что вы тестируете функцию регистрации нового пользователя в веб-приложении. Ваш автоматизированный тест (E2E или интеграционный) отправляет POST-запрос на API-сервер. Сервер, в свою очередь, для подтверждения регистрации должен отправить SMS-код через сторонний сервис (например, SMS-шлюз). Чтобы сделать тесты изолированными и надежными, мы заменяем реальный SMS-шлюз мок-сервером (например, на WireMock или локальным stub).

Сценарий, приводящий к TimeoutException

1. Шаг 1: Тест инициирует регистрацию, отправляя данные на наш API.
2. Шаг 2: Наш сервер обрабатывает запрос и пытается сделать вызов на URL мок-сервера для "отправки SMS".
3. Шаг 3: Здесь возникает проблема: мок-сервер по какой-то причине "завис" (упал, перегружен, неправильно сконфигурирован или просто медленно отвечает из-за нагрузки).
4. Шаг 4: Наш основной сервер (или клиентская библиотека в тесте) настроен на ожидание ответа от этого внешнего вызова с таймаутом в 5 секунд.
5. Шаг 5: Проходит 5 секунд, ответ от мок-сервиса не получен. Блокирующий вызов (например, метод .get() из Future в Java или ожидание промиса в JS) превышает лимит и генерирует TimeoutException.

Пример кода (имитация клиента/теста на Java)

Вот как это может выглядеть в коде интеграционного теста или в логе сервера. Мы имитируем клиент, который ждет ответа от сервера.

import java.util.concurrent.*;

public class RegistrationServiceTest {
    // Сервис, который делает внешний HTTP-вызов к SMS-шлюзу
    private final ExecutorService executor = Executors.newSingleThreadExecutor();

    public String registerUser(String phone) throws TimeoutException {
        // Имитируем асинхронный вызов к внешнему SMS-сервису (нашему моку)
        Future<String> smsFuture = executor.submit(() -> {
            // Внутри этого Callable - HTTP-запрос к мок-серверу
            return mockSmsGatewayClient.sendConfirmationCode(phone); // Этот вызов может "зависнуть"
        });

        try {
            // КРИТИЧЕСКАЯ СТРОКА: Ожидаем результат не более 5 секунд
            return smsFuture.get(5, TimeUnit.SECONDS); // <- Здесь может вылететь TimeoutException
        } catch (TimeoutException e) {
            // 1. Таймаут сработал!
            smsFuture.cancel(true); // Пытаемся отменить задачу
            throw new TimeoutException("SMS gateway не ответил в течение 5 секунд. Мок-сервер недоступен?");
        } catch (InterruptedException | ExecutionException e) {
            throw new RuntimeException("Другая ошибка при вызове сервиса", e);
        }
    }
}

Почему это важно для QA-инженера?

• Диагностика проблем: TimeoutException в этом сценарии — не ошибка теста, а сигнал о потенциальной проблеме в инфраструктуре или тестовом окружении. Тест выполнил свою работу — выявил нестабильность.
• Настройка таймаутов: QA-инженер должен понимать, где и какие таймауты заданы в системе (на уровне HTTP-клиента, БД, Selenium WebDriver), чтобы отличать "медленный, но работающий" тест от реального зависания.
• Повышение устойчивости тестов: В ответ на такие исключения нужно проектировать тесты и систему:

    *   Использовать **separate timeout for debug** в CI.
    *   Реализовывать **retry logic** для неустойчивых интеграций.
    *   Убедиться, что моки и заглушки в тестовом окружении стабильны и быстры.

• Логирование: При возникновении TimeoutException в лог должна попадать максимальная контекстная информация: URL зависшего вызова, параметры запроса, текущая нагрузка, что помогает быстро локализовать корень проблемы.

Таким образом, TimeoutException в описанном сценарии — это четкий индикатор нарушения SLA (Service Level Agreement) по времени ответа между компонентами системы, который QA-специалист должен уметь корректно интерпретировать, документировать и использовать для улучшения надежности как продукта, так и тестовой инфраструктуры.