Uma alternativa ao RunAsDate, com as partes que faltavam

Não é a quantidade de canais. É que o RunAsDate diz com honestidade, na própria documentação, que “não afetará aplicativos que obtêm a data e a hora atuais de outra fonte” - e depois deixa você descobrir se o seu é um deles.

O Chrono Mock trata essa mesma frase como algo a medir. Toda sessão termina com um veredito, os canais que o aplicativo realmente leu, com uma contagem para cada um, os canais perdidos e um aviso quando o aplicativo foi visto abrindo uma conexão de rede antes mesmo de perguntar a hora ao relógio.

Um aplicativo que parece deslocado no tempo mas não está é pior que um que nunca foi iniciado - ele produz um teste aprovado que não significa nada. Como funciona a auditoria →

O RunAsDate intercepta GetSystemTime, GetLocalTime, GetSystemTimeAsFileTime, NtQuerySystemTime e GetSystemTimePreciseAsFileTime. Para uma enorme quantidade de aplicativos isso é realmente suficiente, porque é ali que o relógio de parede é lido.

O resto da superfície é onde o código que depende de data costuma se esconder:

• o fuso horário - as duas funções que o informam, mais as seis que convertem entre fusos, que é como um relatório cai no dia errado
• o eixo do tempo decorrido - contagens de ticks e tempo de interrupção sem viés, que é o que uma contagem regressiva de teste normalmente mede
• as pausas, para que um atraso seja um atraso no relógio da sessão e não no real, e as esperas por objetos, que são contadas e mantêm a duração real
• temporizadores - esperáveis, de janela, de pool de threads e multimídia
• criação de processos, para que os filhos de um instalador rodem na mesma sessão e não no dia de hoje
• as conexões de rede, contadas como sinal de que a hora pode vir de um servidor

Dos 44, 30 vão para o relógio da sessão. Os outros 14 são só contados e continuam reais, então o relatório os lista sem afirmar que foram deslocados. O relógio de parede e o fuso horário são deslocados em toda sessão. O eixo do tempo decorrido e as esperas são observados quando você pede com --scale-duration, e o contador de alta resolução com --scale-qpc.

De verdade, e não raramente:

• Você precisa de uma data, em velocidade normal, agora mesmo. O RunAsDate é um download de menos de 60 KB, não tem janela para aprender e faz exatamente isso há muitos anos.
• Você está em um Windows mais antigo. O RunAsDate volta até o Windows 2000. Esta ferramenta mira o Windows 10 e o 11 e não foi testada em nada mais antigo.
• O tamanho importa. 47 KB de download contra ~2,4 MB para a linha de comando, ou ~70 MB com a janela, não é uma comparação apertada.
• Você não quer um veredito. Medir a cobertura significa ler o resultado. Se o teste é descartável, é um custo que você não pediu.
• O aplicativo já está rodando. O RunAsDate consegue se anexar a um processo em execução desde a versão 1.40. O Chrono Mock inicia o aplicativo ele mesmo, então um que não pode ser reiniciado fica fora do alcance.
• Você quer vários aplicativos com datas diferentes ao mesmo tempo. O RunAsDate dá a cada um a sua própria data. O Chrono Mock conduz uma sessão por vez.

Os dois também podem coexistir. Nada aqui impede você de manter o RunAsDate para o caso rápido.

As duas ferramentas aparecem em pesquisas sobre como estender períodos de teste. Esta não foi feita para isso, e nenhum exemplo, cenário ou página aqui jamais vai demonstrar isso. O Chrono Mock serve para testar software pelo qual você é responsável - a expiração da sua própria licença, a sua própria lógica de renovação, o seu próprio relatório de fim de mês.

É também o caso com menos chance de funcionar. A proteção de licença costuma ler a hora por caminhos escolhidos para serem difíceis de interceptar - a página de dados compartilhada em modo usuário, chamadas diretas ao sistema, um servidor - e um relógio que retrocede é uma condição que esse código é escrito para detectar. A auditoria vai dizer que não funcionou, o que é a resposta honesta, e não uma resposta útil.