A melhor prática é fazer todos os seus testes em um ambiente de desenvolvimento (que você já parece saber).
Para testar tarefas do cron eu geralmente não gosto de mexer com o relógio do sistema (você não pode apenas passar o tempo para onde quiser - Você precisa deixar o relógio passar por todos os pontos para ver como os trabalhos são executados e interagir uns com os outros.
Você também não pode apenas acelerar o relógio (x100) para torná-lo mais rápido: os trabalhos agendados que fazem muito processamento de números não serão mais rápidos, e você pode tê-los pisando em si mesmos (ou um ao outro) dependendo do que a agenda parece.
Meu padrão para testar tarefas agendadas é o seguinte:
- Teste o trabalho executando-o manualmente.
Depure o inferno fora daqui para que você não seja bombardeado com o e-mail cron mais tarde. - Instale o trabalho, programe-o para executar de 2 a 3 minutos a partir de agora.
- Observe os resultados em execução no cron (sem tty).
- Quebre algo em que o trabalho se baseia e programe-o para ser executado novamente em alguns minutos.
- Observe a reação ao rompimento (certifique-se de fazer o que quiser).
- Se o trabalho for executado em OK em (2) & (3) agendar para que seja executado no horário normal.
- Observe os resultados do trabalho em execução no horário normal.
- Se o trabalho for executado, promova a mudança para produção.
Na prática, você pode pular a etapa 4 algumas vezes (se CONHECER que uma tarefa não afeta nenhum outro trabalho e não está preocupado com problemas de carga da CPU / RAM / Disco).
Para realmente fazer um teste de integração em trabalhos agendados, você deve deixar um ano inteiro para decorrer (alterações no horário de verão) e um argumento pode ser feito para a necessidade de mais de 4 anos (anos bissextos) , pulo segundos, etc), mas ninguém que eu conheço faz isso. Esteja ciente de que às vezes 2:30 acontece mais de uma vez (ou não acontece de jeito nenhum), e que nem sempre há um dia 29 de fevereiro e você geralmente está bem.