Resumo dos Destaques de Testes e Fuzzing

Todo ponto de destaque das 9 páginas desta seção, reunido em uma única página e agrupado pela página de origem.

Cultura de Testes em Go: Simples, Rápido, Orientado por Tabela

• Testes ficam ao lado do código de produção em arquivos *_test.go com zero framework adicional
• Casos orientados por tabela mantêm as entradas e expectativas visíveis em uma única slice
• Testes unitários rápidos permitem executar go test ./... a cada salvamento e em CI
• Exemplos em godoc e alvos de fuzzing estendem o mesmo pacote de testes
• O detector de corrida e a cobertura são sinalizadores da toolchain, não plugins de terceiros

Noções Básicas de Testes em Go

• Escreva testes em arquivos _test.go ao lado do código de produção
• Testes orientados por tabela adicionam casos como literais de struct, não funções
• Use t.Run para criar subtestes filtráveis com -run TestName/subtest
• t.Error continua; t.Fatal para o teste quando o código posterior precisa do estado anterior
• t.Helper corrige relatórios de erro para apontar para o teste chamador, não para o helper
• t.Parallel dentro de blocos t.Run executa subtestes concorrentes de forma eficiente

Testes Orientados por Tabela e Subtestes

• Uma slice documenta cada par de entrada/saída que os revisores consideram importante
• t.Run nomeia falhas e habilita filtros -run por caso
• t.Parallel dentro de subtestes acelera casos independentes
• Helpers de configuração usam t.Helper e defer para limpeza compartilhada
• Casos de erro pertencem à mesma tabela que os caminhos de sucesso

testify, httptest e Test Doubles

• httptest registra a saída do manipulador sem vincular uma porta real
• testify require para testes; assert coleta múltiplas falhas
• Interfaces pequenas mais fakes escritos manualmente superam geradores de mock pesados
• gomock e mockery são opcionais quando as interfaces são estáveis
• O layout orientado por tabela funciona com qualquer biblioteca de asserção

Exemplos como Documentação Executável

• Funções de exemplo são executadas sob go test como testes comuns
• Comentários de saída transformam exemplos em documentação verificada
• Nomes de exemplo após o tipo aparecem nas páginas de tipo do pkg.go.dev
• Saída não ordenada usa comentário de saída vazio para verificações apenas de compilação
• Exemplos devem permanecer mínimos e fáceis de copiar e colar

Benchmarks com testing.B e B.Loop

• Funções BenchmarkXxx medem ns/op e alocações por iteração
• B.Loop substitui loops manuais b.N com reinícios de timer corretos
• benchmem relata allocs/op ao lado da temporização
• benchstat compara execuções antes e depois de uma alteração
• Benchmarks complementam, mas não substituem, a criação de perfil com pprof

Fuzz Testing com testing.F

• Funções FuzzXxx exploram entradas além de tabelas escritas manualmente
• f.Add semeia o corpus com casos interessantes conhecidos
• Crashers são salvos em testdata/fuzz e reproduzidos em go test
• Fuzzing é excelente para parsers e decodificadores, não para fluxos de trabalho de negócios
• Jobs de fuzzing em CI precisam de orçamentos de tempo e corpora em cache

Cobertura, Detector de Corrida e Arquivos Golden

• Perfis de cobertura mostram quais linhas foram executadas, não se as asserções são significativas
• -race captura corridas de dados que os testes podem passar sob agendamento normal
• Arquivos Golden armazenam a saída esperada em testdata para testes de snapshot
• go tool cover mescla perfis e destaca relatórios HTML
• CI deve reproduzir o corpus de fuzzing e compilar com -race pacotes críticos

Melhores Práticas de Teste

• Testes orientados por tabela com subtestes nomeados nomeiam falhas por linha
• Use t.Helper() em asserções para que as falhas apontem para as linhas de teste
• Evite time.Sleep; use canais ou sync.WaitGroup em vez disso
• Feche resp.Body após chamadas de cliente para capturar vazamentos com -count=100
• Execute go test -count=1 ao depurar para capturar bugs de ordenação
• Prefira errors.Is e errors.As, pois erros encapsulados quebram ==