В автотесте проверяется истечение срока, но результат зависит от реального времени. Какой архитектурный механизм сделает такую проверку детерминированной?
Нужно изолировать получение времени за абстракцией часов и передавать её в тестируемый компонент как зависимость. В боевом окружении используется реализация, читающая системное время, а в тесте — управляемые часы с заранее заданным моментом и возможностью явно его продвинуть.
Прямое обращение к системным часам делает тест зависимым от внешнего состояния среды. Такие зависимости стали выделять в отдельные абстракции по мере роста автоматизации: это повысило воспроизводимость проверок и упростило тестирование сценариев, которые в реальности длятся часы или дни.
Подход является частным случаем инверсии зависимостей и использования тестовых точек подмены. Компонент отвечает за бизнес-логику, а источник текущего времени становится заменяемой инфраструктурной зависимостью.
Если тест использует реальные часы, он может зависеть от момента запуска, часового пояса, перехода на летнее время, точности системных таймеров и задержек CI. Проверка, которая ожидает истечения срока, будет медленной или станет нестабильной на границе временного условия.
Фиксированная пауза не решает проблему: она лишь увеличивает длительность теста и не гарантирует, что нужное состояние наступило. Подмена времени глобальным способом тоже опасна: она может повлиять на параллельно выполняющиеся тесты или на сторонние компоненты.
Тестируемый компонент не должен сам получать время из глобального системного источника. Вместо этого он обращается к интерфейсу часов, например к операции получения текущего момента; конкретная реализация передаётся при создании компонента.
В тесте управляемые часы устанавливаются в известный момент. Затем тест явно продвигает их за границу срока и проверяет изменение состояния. В результате тест не ждёт реальное время и каждый запуск получает одинаковый исходный контекст.
Важно различать календарное время и монотонное время. Календарное время нужно для дат, сроков и отображаемых отметок; для измерения длительности безопаснее использовать монотонный источник, который не меняется из-за синхронизации системных часов.
Подмена должна действовать на ограниченный объект или тестовый контекст, а не на весь процесс без необходимости. После теста состояние управляемых часов должно быть изолировано, иначе последующие проверки могут получить неожиданный момент времени.
У подхода есть ограничения. Подмена часов не заменяет проверку корректной работы операционной системы, планировщиков, баз данных и внешних сервисов с реальным временем; для этого нужны отдельные интеграционные проверки. Также необходимо учитывать единый формат временных зон и хранить моменты времени однозначно, обычно с явным смещением или в UTC.
Сервис выпускает ссылку, действительную десять минут. Тест с реальными часами ждал десять минут, а после ускорения через короткую задержку иногда проверял ссылку до фактического истечения срока. В CI это приводило к длительным запускам и редким сбоям на границе интервала.
Рассматривались три варианта. Увеличить задержку было просто, но это не устраняло зависимость от среды и ещё сильнее замедляло набор. Проверять только внутреннее значение срока было быстро, но такая проверка не подтверждала поведение публичного интерфейса. Глобально подменять системное время было эффективно для одного процесса, но создавало риск взаимного влияния параллельных тестов.
Выбрали внедряемые часы с управляемым временем. Тест создавал сервис с фиксированным моментом, проверял действительность ссылки, продвигал часы за десятиминутную границу и повторно проверял доступ. Время выполнения сценария сократилось до времени обычного вызова, а результат перестал зависеть от календарного момента запуска.
Фиксированная дата полезна только тогда, когда вся логика использует именно её. Если код внутри самостоятельно читает системные часы, параметр не контролирует фактический источник времени. Нужна единая точка получения текущего момента, которую можно заменить или внедрить.
Кроме того, важно не подменять время только в проверяемом объекте, если связанные компоненты получают другой момент самостоятельно. Иначе тест может сравнивать значения, рассчитанные на разных временных шкалах.
Такая проверка подтверждает бизнес-логику, но не обязательно подтверждает взаимодействие с реальным планировщиком, таймером или внешним хранилищем. Например, фоновая задача может не проснуться автоматически только потому, что тестовые часы были продвинуты.
Поэтому быстрые модульные тесты следует дополнять ограниченным числом интеграционных проверок реального запуска фоновых механизмов. Это разделяет проверку правила истечения срока и проверку инфраструктурного расписания.
Монотонные часы нужны, когда проверяется длительность или тайм-аут: например, сколько времени операция находилась в ожидании. Их значение не должно уменьшаться или скачкообразно изменяться из-за синхронизации системных часов.
Календарные часы нужны, когда бизнес-правило связано с конкретной датой или моментом, например с датой окончания подписки. Смешивание этих источников может привести к неверным выводам: календарное время подходит для отображения и сроков, но не всегда подходит для измерения прошедшей длительности.