Управление временем в тестах

«Учебная сессия создана в 10:00 UTC и действительна, пока now меньше 10:15. В 10:14:59 доступ есть, в 10:15:00 и 10:15:01 — нет». Попросите тест без реальной паузы. Три значения проверяют именно выбранное правило, а не расплывчатое “примерно через пятнадцать минут”. Если контракт другой, сначала измените ожидаемую границу, затем тестовую реализацию.

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

Укажите часовую зону и правило для отсутствующего или повторяющегося времени при сезонном переходе. Для «каждый день в 09:00» календарная дата важнее постоянного числа секунд между запусками. Попросите конкретные даты, подтверждённые правилами зоны, и ожидаемое поведение. Для простого TTL обычно удобнее абсолютная временная шкала; не смешивайте её с человеческим расписанием без явного решения.

Глобальные часы, таймеры и настройки зоны остаются изменёнными после ошибки, если очистка не гарантирована. Попросите фикстуру с восстановлением и тест соседнего сценария, использующего обычное время. Учтите параллельный запуск. Енотик подготовит схему, но не подтвердит поведение вашего runner без прогона; назовите Jest, pytest или другой инструмент и версии, чтобы пример использовал поддерживаемый механизм управления временем.