Testes que Valem Salário

Você escreveu uma função que calcula frete. Testou com um total qualquer, viu o número sair, seguiu para a próxima tarefa. Duas semanas depois alguém muda a comparação de >= para > e o cliente no limite passa a pagar frete indevido. O teste que existia não percebeu nada, porque ele exercitava um total longe da fronteira. O problema não foi a mudança — mudanças vão acontecer. O problema foi o teste não contar a história da regra.

Table-driven tests existem para fazer essa história ficar visível. Em vez de espalhar if got != want em cinco funções quase iguais, você reúne entradas, resultados esperados e o motivo de cada caso em um único slice de structs. O laço percorre a tabela e executa a mesma asserção para cada linha. O que sobra para revisar é a lista de casos: ela precisa responder, sozinha, quais comportamentos o contrato protege.

O risco de uma tabela fraca é o mesmo de uma função sem teste: ela executa, fica verde e dá uma falsa sensação de segurança. Uma tabela só vale quando escolhe entradas capazes de distinguir o contrato correto de uma mutação plausível. Se você só copia variações do mesmo caminho feliz, qualquer defeito pequeno passa batido. Por isso o critério de uma boa linha não é quantidade, é poder de discriminação: qual mudança essa entrada detectaria?

Este mini aplica uma inversão que muda o jogo. Em vez de implementar a função de produção, você implementa o teste. O avaliador recebe sua suíte e a executa contra duas implementações do mesmo contrato: uma conhecida como correta (good) e outra com um defeito deliberado (broken). A aprovação exige duas evidências — nenhuma acusação falsa contra good e ao menos uma acusação verdadeira contra broken. Um teste vazio passa no primeiro critério e falha no segundo; um teste que sempre falha faz o oposto. Sobrará apenas a suíte que realmente discrimina.

A assinatura usa TestingT, uma interface mínima com Helper, Errorf e Run. O corpo continua parecendo um teste Go de verdade: nome começando em Test, tabela de casos, subtestes e mensagens com got e want. A interface existe apenas porque o avaliador concatena seu teste com o harness e roda go run, em vez de orquestrar um subprocesso de go test. Em um repositório normal, você troca TestingT por *testing.T e arquiva a função em um _test.go.

A bancada abaixo resume o mecanismo em quatro passos. O primeiro frame estabelece a tabela. O segundo mostra a implementação boa aprovando cada comparação. O terceiro injeta a mutação e mostra a mesma tabela acusando o caso decisivo. O quarto reúne as duas evidências: passa-na-boa e falha-na-quebrada. Cores não decoram; elas informam o resultado de cada comparação.