Mudanças que alteram testes e código juntos são revertidas com menos frequência do que mudanças apenas de código de tamanho semelhante

Hipótese

Os repositórios registram os próprios arrependimentos: a documentação do git-revert descreve o comando como a criação de novos commits que desfazem o efeito de commits anteriores, e os commits corretivos costumam mencionar na mensagem a mudança que corrigem. A hipótese é que, entre mudanças de tamanho semelhante na mesma área de uma base de código, as que adicionam ou modificam arquivos de teste junto com o código de produção são revertidas ou corrigidas dentro de um intervalo curto com menos frequência do que as que alteram apenas código de produção. O mecanismo proposto não é que os testes detectem todos os bugs, mas que escrever ou ajustar um teste obriga o autor a explicitar o que a mudança deve fazer e a executá-la uma vez nessa forma, o que elimina uma classe de erros (branch errado, valor padrão errado, ponto de chamada esquecido) antes da revisão.

Previsão

Em um repositório com uma suíte de testes funcional, a proporção de mudanças seguidas, dentro de um intervalo definido (por exemplo, 14 dias), por um revert dessa mudança ou por um commit cuja mensagem a mencione como correção é menor nas mudanças que incluem modificações em arquivos de teste do que nas mudanças apenas de código, depois de parear por linhas alteradas, arquivos afetados e diretório. Espera-se que a diferença seja menor em mudanças triviais (renomeações, edições de comentários) e maior em mudanças de lógica com ramificações. Mudanças que alteram apenas arquivos de teste ficam fora dos dois grupos.

Teste proposto

1. Selecionar repositórios com uma suíte de testes executada em CI e pelo menos um ano de histórico; definir os arquivos de teste por padrão de caminho em cada repositório.
2. Para cada mudança que não seja merge, registrar o tamanho, os arquivos, o diretório, se houve modificação em arquivos de teste e o autor.
3. Identificar as mudanças "lamentadas": um git revert posterior da mudança ou um commit dentro do intervalo cuja mensagem cite o identificador da mudança com termos típicos de correção; registrar a regra de detecção utilizada.
4. Parear mudanças apenas de código e mudanças de código com testes por tamanho e diretório; comparar as taxas de arrependimento com um intervalo de confiança e repetir a análise por repositório, em vez de agregar os dados.
5. Informar a proporção de mudanças que alteraram algum teste, já que um repositório em que quase todas as mudanças o fazem não oferece contraste.

Estado

Nenhum resultado é afirmado. Reverts são um sinal limitado: muitas mudanças ruins são corrigidas com commits posteriores sem qualquer referência, e alguns reverts não têm relação com defeitos (uma funcionalidade retirada por motivos de produto). O pareamento por tamanho é indispensável, porque mudanças maiores tanto têm mais probabilidade de incluir testes quanto de ser revertidas, o que poderia gerar um resultado espúrio em qualquer direção.