Graças a Deus pelos testes de regressão. Lá estava eu, no início desta semana, muito satisfeito com um código novo que havia escrito e (eu achava) depurado. Estou trabalhando no aprimoramento das funções POSIX do OpenVOS que convertem valores de tempo binários para a estrutura de tempo detalhada (“struct tm”, para vocês, especialistas em C). Em 1998, quando modifiquei originalmente essas rotinas para funcionar no ambiente POSIX, tomei um atalho e chamei as sub-rotinas do kernel VOS subjacentes. Essa abordagem era rápida e simples, mas significava que nossos tempos de execução POSIX não podiam lidar com datas entre 1970 e 1980, porque o VOS não lida com essas datas. Ultimamente, tenho portado vários pacotes novos e importantes de código aberto para o OpenVOS 17.0. Descobri que estávamos falhando em vários testes porque não conseguíamos lidar com esse intervalo de datas. Então, dediquei-me à tarefa de modificar o código para lidar com todas as datas tanto na Era VOS quanto na Era UNIX (1970 a 2048). Eu sabia que essa tarefa seria propensa a erros e estava determinado a encontrar uma maneira de eliminar todos os bugs do código. Uma das vantagens de trabalhar com datas é que o conjunto é finito. Além disso, como os computadores modernos são bastante rápidos, não é tão difícil assim fazer com que eles processem todas as combinações possíveis e vejam o que acontece. Eu queria ter certeza de testar a parte do código que lidava com 1970 e 1971, por motivos que não vou abordar aqui. Então, escrevi um teste que fazia a conversão duas vezes por dia, começando em 1º de janeiro de 1970 e se estendendo até o presente. Ele usou apenas uma fração de segundo de tempo de CPU. Como era de se esperar, encontrei um erro de limite no meu código. Corrigi o erro e o teste foi aprovado. Eu estava bastante satisfeito com esse processo, meus auditores aprovaram as alterações e achei que estava tudo resolvido. Então, um colega meu executou o conjunto de testes de regressão nas minhas alterações. Fazemos isso após cada alteração nos compiladores e seus ambientes de execução, apenas para ter certeza de que não quebramos nada acidentalmente. Infelizmente para mim, vários dos testes de regressão falharam. Quando descobri por que meus testes não haviam detectado isso, apesar da aparente rigor dos testes, percebi que os problemas só surgiriam em 2038. Embora eu tivesse adicionado a década de 1970 a 1980 às rotinas de tempo, eu havia omitido a década de 2038 a 2048. Como era de se esperar, quando voltei e testei todos os dias nesse intervalo, comprovei que meu teste teria detectado o problema, se eu tivesse pedido para ele fazer isso.
Qual é a lição aqui? Suponho que a mais óbvia seja que, se você puder testar todas as combinações, certifique-se de realmente testar todas elas. Talvez uma lição mais importante seja dedicar tempo para criar um conjunto de testes de regressão. Eles valem o tempo e o esforço. Eles podem reduzir o custo e o tempo necessários para identificar e corrigir problemas à medida que você aprimora seu código. Você não precisa evitar muitos problemas relatados pelos clientes para justificar o custo de criar um conjunto de testes de regressão. Estimo que o custo de corrigir um problema de software aumente em uma ordem de magnitude a cada fase adicional no processo. Como há pelo menos quatro fases em qualquer processo (projeto, código, teste, implantação), os custos aumentam rapidamente.