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:
- Test the job by running it manually.
Debug the hell out of it here so you don't get bombarded with cron email later.
- Install the job, schedule it to run 2-3 minutes from now.
- Observe the results running from cron (with no tty).
- Break something the job relies on and schedule it to run again in a few minutes.
- Observe the reaction to breakage (make sure it does what you want).
- If the job runs OK in (2) & (3) schedule it to run at its normal time.
- Observe the results of the job running at its normal time.
- If the job runs OK promote the change to production.
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.