Тестирование задач без ожидания

Тестирование cron начинается с разделения, а не с инструментов. Задача — это структура с методом Run и зависимостями в полях; механизм из урока про задачи-структуры даёт для этого всё: интерфейс Job, конструктор с зависимостями, pointer-приёмник. Планировщик — инфраструктура, которая в момент тика вызывает Run. Раз структура живёт сама по себе, тест создаёт её с фейковыми зависимостями, вызывает Run и проверяет результат — те же правила, что и в уроке про тестирование для обычных функций. Планировщик в этом тесте не участвует: доверять тому, что cron вызовет зарегистрированную задачу, — разумно, библиотека покрыта собственными тестами. Ваша ответственность — то, что происходит внутри тика, и строки расписаний, которые вы передаёте в регистрацию из конфига. Побочный бонус разделения: тесты задач без планировщика независимы друг от друга и помечаются t.Parallel, тогда как один общий живой экземпляр Cron вынуждал бы согласовывать их между собой.

Вторая часть контракта — строки расписаний, которые приходят из конфига и уходят в AddJob. Невалидная строка возвращает ошибку, а не панику, и задача из урока про конфиг обязана её обработать при старте; тесты задач go закрепляют этот контракт табличным набором: валидные строки парсятся, битые — нет. Табличные тесты из урока про тестирование здесь работают один в один: на каждый вариант — ожидание ошибки или её отсутствия. Отдельный класс — календарные ожидания: парсер возвращает объект Schedule с методом Next, и от него можно спросить следующий запуск от фиксированного момента. Так проверяется, что CRON_TZ-префикс из урока про часовые пояса учтён, а спецификация «в девять утра» действительно означает девять утра в нужной зоне, а не в зоне процесса.

Третий уровень — календарная математика, и здесь время подменяется фиксированным моментом. В тестах не вызывают time.Now на ожидаемое значение: момент задают конструктором time.Date с явной зоной, как советует и урок про пакет time. От фиксированного момента вычисляется Next расписания, и результат сравнивается с ожидаемым — проверяется дата, час и зона. Зона в тесте задаётся явно, потому что результат зависит от time.Local процесса, на котором тест исполняется: CI в UTC и ноутбук в Москве дадут разные строки для одного и того же выражения без префикса. Тот же приём лечит задачи, внутри которых вызывается time.Now: момент времени выносится в поле now func() time.Time, тест подставляет заглушку, и ночная логика проверяется днём. Момент следующего запуска зарегистрированной задачи виден и через Entry из урока про инспекцию, но для тестов хватит чистого Schedule.Next. Отдельная деталь: у выражения @every следующий момент считается от момента регистрации, поэтому его Next имеет смысл проверять, только если привязка к старту важна для логики — иначе достаточно валидности строки.

Спорная привычка, которую стоит оспорить: завести в тесте настоящий cron.NewWithSeconds, поставить @every 100ms, подождать полсекунды и посчитать тики. Такой тест кажется более честным, потому что проверяет связку целиком, но он проверяет в основном библиотеку, а не ваш код: тики у robfig/cron уже покрыты её собственными тестами, а ваши строки расписаний закрыты табличным тестом. Что остаётся — flakiness от таймингов и медленный пакет. Верное применение этой идеи — один smoke-тест на весь пакет задач: планировщик поднимается с укороченным расписанием, задач-пустышек набирается счётчик, тест подтверждает, что регистрация из конфига до тиков доведена. Такой тест допускает запас по времени и помечается как медленный. Логика задач при этом тестируется прямыми вызовами, календарь — через Next; интеграционная проверка — страховка, а не основа.