У меня есть ряд заданий cron, и я хотел бы протестировать их более своевременным и автоматизированным способом, чем следующие:
Я думаю, что запуск тестового сценария от имени пользователя root (конечно, в среде разработки) и изменение системных часов может быть полезным. Какая лучшая практика?
Лучше всего проводить все тестирование в среде разработки (о которой вы, кажется, уже знаете).
Для тестирования заданий cron я обычно не люблю возиться с системными часами (вы не можете просто переключать время туда, где хотите - вам нужно позволить часам проходить через все точки, чтобы увидеть, как задания выполняются и взаимодействуют с друг друга.
Вы также не можете просто ускорить часы (x100), чтобы сделать это быстрее: задания cron, которые много обрабатывают числа, не будут быстрее, и вы можете заставить их наступать на себя (или друг друга) в зависимости от того, что расписание похоже.
Мой стандарт для тестирования заданий cron следующий:
На практике вы можете иногда пропустить шаг 4 (если вы Знать что задание не влияет на другие задания, и вас не беспокоят проблемы с загрузкой ЦП / ОЗУ / диска).
Чтобы действительно выполните интеграционный тест для заданий cron, вы должны позволить пройти полный год (переход на летнее время), и можно даже привести аргумент в пользу необходимости более 4 лет (високосные годы, високосные секунды и т. д.), но я никого не знаю Является ли это. Просто имейте в виду, что иногда 2:30 бывает более одного раза (или не бывает вообще), и что не всегда бывает 29 февраля, и обычно у вас все в порядке.
* * * * * /path/to/your/job >> /tmp/job.log 2>&1
job.log
.