Executando testes de mutação sem se afogar em mutantes sobreviventes

Objetivo

Usar o teste de mutação como uma verificação de rotina de que os testes detectam falhas, sem transformá-lo em gargalo do CI nem em um relatório cheio de sobreviventes que ninguém trata. Se a pontuação prevê ou não defeitos que escapam para produção é uma questão tratada em outra entrada, de hipótese; aqui está o procedimento operacional.

Pré-requisitos

Uma suíte de testes unitários determinística e independente da ordem de execução; uma ferramenta de mutação para a linguagem (PIT para a JVM, StrykerJS para JavaScript e TypeScript, mutmut para Python, cargo-mutants para Rust); cobertura de linhas já medida, pois código não coberto só gera mutantes "no coverage".

Passos

1. Rode a ferramenta em um módulo que contenha lógica, não na base de código inteira, e leia o relatório. A documentação do PIT lista os resultados possíveis por mutante: killed, survived, no coverage, timed out, além de estados non-viable e error. A página de métricas do Stryker define a pontuação de mutação como mutantes detectados divididos por mutantes válidos, em que os detectados incluem os mortos (kills) e os timeouts.
2. Abra cada sobrevivente no código. Ele se enquadra em uma de três categorias: uma asserção ausente (o teste executou a linha, mas não verificou nada que dependa dela), um caso ausente (um limite que nenhum teste alcança) ou um mutante equivalente, que não pode alterar o comportamento observável; a documentação do PIT ilustra isso com >= 1 versus > 1 quando o valor é sempre 2.
3. Corrija os dois primeiros tipos fortalecendo os testes. No caso dos equivalentes, exclua o mutador ou anote a linha, conforme a ferramenta permitir, em vez de escrever testes artificiais.
4. Limite o tempo de execução: restrinja a execução aos arquivos alterados ou use o modo incremental (o --incremental do StrykerJS reaproveita resultados de mutantes cujos testes que os cobrem não mudaram); defina um timeout por mutante; desative mutadores que só geram ruído para a base de código (o PIT, por padrão, ignora linhas com chamadas a frameworks de log comuns).
5. Coloque no CI a execução limitada ao diff e agende uma execução completa com o relatório publicado, sem bloquear o pipeline.
6. Acompanhe a pontuação por módulo e use-a como ratchet ("não menor que a da última execução"), em vez de uma meta global fixa.

Resultado esperado

Cada alteração produz, antes da revisão, uma lista curta de asserções ausentes concretas, e a pontuação dos módulos que importam sobe aos poucos, em vez de ser objeto de discussão.

Limites e base de verificação

O tempo de execução se multiplica com o número de mutantes, e testes instáveis (flaky) ou dependentes da ordem tornam os resultados sem sentido. As pontuações não são comparáveis entre ferramentas nem entre conjuntos de mutadores. Uma pontuação alta em código trivial diz pouco; o esforço deve ir para módulos com lógica de ramificação. Nenhuma medição é alegada.