Resumen de puntos destacados de pruebas y fuzzing

Cada viñeta destacada de las 9 páginas de esta sección, reunida en una sola página y agrupada por la página de la que proviene.

Cultura de pruebas en Go: Simple, rápida, basada en tablas

• Las pruebas viven junto al código de producción en archivos *_test.go sin ningún framework adicional
• Los casos basados en tablas mantienen las entradas y las expectativas visibles en una única slice
• Las pruebas unitarias rápidas permiten ejecutar go test ./... en cada guardado y en CI
• Los ejemplos en godoc y los objetivos de fuzzing extienden el mismo paquete de pruebas
• El detector de carreras y la cobertura son indicadores de la cadena de herramientas, no plugins de terceros

Conceptos básicos de pruebas en Go

• Escriba pruebas en archivos _test.go junto al código de producción
• Las pruebas basadas en tablas agregan casos como literales de struct, no como funciones
• Use t.Run para crear subpruebas filtrables con -run TestName/subtest
• t.Error continúa; t.Fatal detiene la prueba cuando el código posterior necesita un estado previo
• t.Helper corrige los informes de error para que apunten a la prueba que llama, no al ayudante
• t.Parallel dentro de los bloques t.Run ejecuta subpruebas concurrentes de manera eficiente

Pruebas basadas en tablas y subpruebas

• Una única slice documenta cada par de entrada/salida que preocupa a los revisores
• t.Run nombra los fallos y habilita los filtros -run por caso
• t.Parallel dentro de las subpruebas acelera los casos independientes
• Los ayudantes de configuración usan t.Helper y defer para la limpieza compartida
• Los casos de error pertenecen a la misma tabla que las rutas de éxito

testify, httptest y Test Doubles

• httptest registra la salida del manejador sin vincular un puerto real
• testify require detiene las pruebas; assert recopila múltiples fallos
• Las interfaces pequeñas más fakes escritos a mano superan a los generadores de mocks pesados
• gomock y mockery son opcionales cuando las interfaces son estables
• El diseño basado en tablas funciona con cualquier biblioteca de aserciones

Ejemplos como documentación ejecutable

• Las funciones de ejemplo se ejecutan bajo go test como pruebas ordinarias
• Los comentarios de salida convierten los ejemplos en documentación verificada
• Los nombres de ejemplo después del tipo aparecen en las páginas de tipo de pkg.go.dev
• La salida desordenada usa un comentario de salida vacío para verificaciones de solo compilación
• Los ejemplos deben ser mínimos y fáciles de copiar y pegar

Benchmarks con testing.B y B.Loop

• Las funciones BenchmarkXxx miden ns/op y las asignaciones por iteración
• B.Loop reemplaza los bucles b.N manuales con reinicios de temporizador correctos
• benchmem informa allocs/op junto con la temporización
• benchstat compara ejecuciones antes y después de un cambio
• Los benchmarks complementan pero no reemplazan la perfilación con pprof

Pruebas de fuzzing con testing.F

• Las funciones FuzzXxx exploran entradas más allá de las tablas escritas a mano
• f.Add siembra el corpus con casos interesantes conocidos
• Los crashers se guardan en testdata/fuzz y se reproducen en go test
• El fuzzing es excelente para analizadores y decodificadores, no para flujos de trabajo de negocios
• Los trabajos de fuzzing de CI necesitan presupuestos de tiempo y corpus cacheados

Cobertura, Detector de Carreras y Archivos Dorados

• Los perfiles de cobertura muestran qué líneas se ejecutaron, no si las aserciones son significativas
• -race detecta carreras de datos que las pruebas pueden pasar bajo la programación normal
• Los archivos dorados almacenan la salida esperada en testdata para pruebas de instantáneas
• go tool cover fusiona perfiles y resalta informes HTML
• CI debería reproducir el corpus de fuzzing y compilar con -race los paquetes críticos

Mejores prácticas de pruebas

• Las pruebas basadas en tablas con subpruebas nombradas nombran los fallos por fila
• Use t.Helper() en las aserciones para que los fallos apunten a las líneas de prueba
• Evite time.Sleep; use canales o sync.WaitGroup en su lugar
• Cierre resp.Body después de las llamadas al cliente para detectar fugas con -count=100
• Ejecute go test -count=1 al depurar para detectar errores de ordenación
• Prefiera errors.Is y errors.As ya que los errores envueltos rompen ==