I have a series of cron jobs and I would like to test them in a more timely and automated way than the following:
- Test individual jobs in isolation by running them manually.
- Install job and update crontab.
- Wait for cron to execute jobs.
- Observe results.
I'm thinking that running a test script as root (in a development environment, of course) and fiddling with the system clock might be beneficial. What is best practice?
Best practice is to do all your testing in a development environment (which you already seem to know).
For testing cron jobs I generally don't like to muck around with the system clock (you can't just step the time to wherever you want - You need to let the clock run through all points to see how the jobs run and interact with each other.
You also can't just speed up the clock (x100) to make it faster: cron jobs that do a lot of number crunching won't be any faster, and you may have them stepping on themselves (or each other) depending on what the schedule looks like.
My standard for testing cron jobs is as follows:
Debug the hell out of it here so you don't get bombarded with cron email later.
In practice you can skip step 4 sometimes (if you KNOW that a job doesn't impact any other jobs and you're not worried about CPU/RAM/Disk load issues).
To really do an integration test on cron jobs you have to let a full year elapse (daylight saving time changes), and an argument can even be made for needing more than 4 years (leap years, leap seconds, etc.), but nobody I know does this. Just be aware that sometimes 2:30 happens more than once (or doesn't happen at all), and that there isn't always a February 29th and you're usually fine.
job.log
.