Como você testa softwares sensíveis ao tempo?

Por tempo sensível, quero dizer, por exemplo, um script que é executado apenas uma vez por mês ou um script que é executado continuamente, mas fornece uma determinada saída apenas uma vez por mês. Obviamente, você pode fazer o teste de unidade para muitos casos, mas há exceções (no meu entendimento).

Um exemplo recente que encontrei foi a configuração de um trabalho cron para execução no segundo ao último dia de cada mês. Isso exigia o uso de um script de shell com a guia cron para obter o dia do mês correto para o cron, algo como:

1 0 [shell command] * * [my script]

Eu não estava familiarizado com o script e não estava familiarizado com os scripts de shell em geral e, portanto, não tinha uma maneira boa de testá-lo, além de esperar o final do mês chegar e ver se o script era executado corretamente (na verdade, minha solução foi encontrar um trabalhador que sabia muito mais sobre scripts cron e shell).

Portanto, estou curioso para saber se existem soluções úteis para testar scripts sensíveis ao tempo.

Além do teste de unidade, existem outras duas estratégias para configurar testes automatizados para lidar com um problema específico do SO:

• Virtualização : você configura várias imagens do sistema operacional (por exemplo, usando o VMWare ) com as configurações exatas necessárias, configura uma maneira de puxar automaticamente o binário para teste (geralmente montando um diretório especial no espaço da VM) e, em seguida, executa o teste.

Ou:

• Instrumentação : adicione manualmente ifcondições especiais ao seu programa que farão com que o programa se comporte de maneira diferente. No Unix, isso seria feito verificando se uma determinada variável de ambiente está definida, como FOOBAR_TEST_TIME_WITH_T=500. Seus testes automatizados usarão diferentes configurações das variáveis ​​de ambiente e diferentes variáveis ​​de ambiente para executar o que você precisa.

Você também pode vincular-se a diferentes bibliotecas, se suas interações puderem ser expressas no nível da biblioteca, que podem ser consideradas uma virtualização (se a "biblioteca" é o kernel do SO) ou uma técnica de instrumentação. Ambos os termos podem ser usados, embora o termo virtualização usado hoje quase sempre signifique algo como o VMWare. Uma biblioteca especificamente para retornar valores fixos ou executar novamente interações específicas seria uma abordagem simulada ou stub .

Também existem ferramentas de instrumentação automática, que podem reescrever seus binários para obter outros efeitos desejados, como o sistema de arquivos estar cheio.

No geral, seu objetivo é encontrar bugs. Para verificar casos estranhos, como o sistema de arquivos está cheio, é mais fácil e eficaz instrumentar manualmente seu programa, seguindo a rota de virtualização ou configuração manual da máquina raramente, se é que alguma vez.

O mais eficaz - Altere a data da máquina em que você está testando. Defina-o um pouco antes, quando precisar ser executado, e verifique quando ele inicia e se está funcionando corretamente. No entanto, isso nem sempre é possível se houver várias máquinas envolvidas ou se forem necessários recursos sobre os quais sua empresa não tem controle. Entretanto, certifique-se de fazer isso por vários meses e altere o ano algumas vezes para testar fevereiro.

Não conheço o seu script, mas tento usar algum tipo de parâmetro para definir a data. No seu caso, se nenhuma data for especificada, o padrão é final do mês. No seu código, pegue o parâmetro date e execute se hoje for dois dias antes. Você não apenas poderá testá-lo (passar em uma data daqui a dois dias), mas também executar no dia seguinte, caso algo o impeça de funcionar em circunstâncias normais (falha de energia, servidor inoperante etc.).

Desde que você mencionou o crontab, presumo que você esteja executando em um ambiente nix. Nesse caso, acho que valeria a pena conferir a libfaketime:
http://www.code-wizards.com/projects/libfaketime/

Através da magia do LD_PRELOAD, podemos carregar versões personalizadas das funções da biblioteca, desde que correspondam à interface. O que a libfaketime faz é carregar versões das chamadas do sistema de horário que permitem personalizar seu comportamento por meio de variáveis ​​de ambiente. Você pode forçar o time () para retornar um valor codificado ou um deslocamento do horário atual, tudo sem afetar mais ninguém na caixa.

Não há muita necessidade de testar o cron, pois ele já foi testado ("teste de produção") por muitas gerações. Obviamente, se você estiver trabalhando com um script de shell, poderá definir a data / hora em uma máquina virtual.

A maneira preferida de lidar com isso é "zombando do relógio", usando um truque de programação ou outro para simular o tempo. Nos scripts de shell, você pode usar a sintaxe $ {: -} para usar uma data definida em uma variável de ambiente e retornar à hora real, se não for forçada.

Em outros idiomas, usamos bibliotecas simuladas ou construímos uma abstração 24 horas por dia.

O relógio simulado é bom porque você pode automatizá-lo em vez de precisar configurar manualmente seu teste. Esse é um benefício muito grande quando se trata de modificar o script / código posteriormente e você pode facilmente saber se ele ainda funciona ou não.