Fundamentos de Pruebas en Go

10 ejemplos para empezar con Pruebas y Fuzzing - 7 básicos y 3 intermedios.

Prerrequisitos

• Instala Go 1.26.x o posterior desde go.dev/dl.
• Crea un módulo: mkdir testing-demo && cd testing-demo && go mod init example.com/testing-demo.
• No se requiere un ejecutor de pruebas adicional; go test está integrado en la cadena de herramientas.

go version
go test ./...

Ejemplos Básicos

1. Tu primera función de Prueba

Una prueba es una función ordinaria llamada TestXxx que recibe *testing.T.

package mathutil
 
import "testing"
 
func Add(a, b int) int { return a + b }
 
func TestAdd(t *testing.T) {
	if got := Add(2, 3); got != 5 {
		t.Fatalf("Add(2,3) = %d, want 5", got)
	}
}

• t.Fatalf marca la prueba como fallida y detiene la función actual.
• Los archivos de prueba terminan en _test.go y viven junto al código de producción.
• Ejecuta con go test desde la raíz del módulo.

Relacionado: Cultura de Pruebas en Go: Simple, Rápida, Basada en Tablas - por qué las pruebas de Go se ven así

2. Ejecutar pruebas para un paquete

go test acepta patrones de paquetes como las compilaciones de producción.

go test ./mathutil
go test -v ./...

• -v imprime el nombre de cada prueba a medida que se ejecuta.
• ./... recorre todos los paquetes bajo el módulo.
• El código de salida es distinto de cero cuando falla alguna prueba, ideal para CI.

Relacionado: Cobertura, Detector de Carreras y Archivos Dorados - flags más allá del go test simple

3. Casos basados en tablas

Recopila entradas y expectativas en un slice, luego itera.

func TestAddTable(t *testing.T) {
	tests := []struct {
		a, b, want int
	}{
		{1, 2, 3},
		{0, 0, 0},
		{-1, 1, 0},
	}
	for _, tc := range tests {
		if got := Add(tc.a, tc.b); got != tc.want {
			t.Fatalf("Add(%d,%d) = %d, want %d", tc.a, tc.b, got, tc.want)
		}
	}
}

• Añadir un caso es un literal de struct, no una nueva función.
• Mantén los nombres de campo cortos pero significativos (want, input, err).
• Las tablas son el patrón predeterminado en todo el ecosistema de Go.

Relacionado: Pruebas Basadas en Tablas y Subpruebas - t.Run y configuración compartida

4. Subpruebas con t.Run

Las subpruebas nombran cada caso en la salida de fallo.

func TestAddSub(t *testing.T) {
	for _, tc := range []struct {
		name       string
		a, b, want int
	}{
		{"positives", 1, 2, 3},
		{"zeros", 0, 0, 0},
	} {
		t.Run(tc.name, func(t *testing.T) {
			if got := Add(tc.a, tc.b); got != tc.want {
				t.Fatalf("got %d want %d", got, tc.want)
			}
		})
	}
}

• Filtra un caso: go test -run TestAddSub/zeros.
• Las subpruebas pueden llamar a t.Parallel() para casos concurrentes.
• Siempre asigna a name una cadena distinta por fila.

Relacionado: Pruebas Basadas en Tablas y Subpruebas - tablas paralelas y funciones auxiliares de configuración

5. t.Helper para aserciones compartidas

Marca funciones auxiliares para que los fallos informen la línea del llamador.

func assertEqual(t *testing.T, got, want int) {
	t.Helper()
	if got != want {
		t.Fatalf("got %d want %d", got, want)
	}
}
 
func TestWithHelper(t *testing.T) {
	assertEqual(t, Add(1, 1), 2)
}

• Sin t.Helper(), los fallos apuntan dentro de la función auxiliar, no a la prueba.
• Las funciones auxiliares mantienen las tablas legibles sin duplicar if got != want.
• Las funciones auxiliares pueden vivir en export_test.go o en un subpaquete testing para su reutilización.

6. t.Error vs t.Fatal

Error registra el fallo y continúa; Fatal detiene la función de prueba actual.

func TestMultiCheck(t *testing.T) {
	if Add(1, 1) != 2 {
		t.Error("add failed")
	}
	if Add(2, 2) != 4 {
		t.Fatal("second check failed")
	}
	t.Log("only runs if Fatal did not fire")
}

• Usa Fatal cuando las siguientes aserciones asumen un estado previo.
• La salida de Log aparece con -v o en caso de fallo.
• Las subpruebas aíslan los fallos mejor que muchas llamadas a Error en una sola función.

7. Paquete de pruebas externo

package foo_test importa el módulo como lo hacen los consumidores.

// en add_ext_test.go
package mathutil_test
 
import (
	"testing"
 
	"example.com/testing-demo/mathutil"
)
 
func TestAddExported(t *testing.T) {
	if mathutil.Add(3, 4) != 7 {
		t.Fatal("unexpected sum")
	}
}

• Las pruebas externas solo acceden a identificadores exportados.
• Documentan la superficie de la API pública.
• Las pruebas internas (package mathutil) pueden acceder a funciones auxiliares no exportadas.

Relacionado: Ejemplos como Documentación Ejecutable - ejemplos de godoc en archivos de prueba

Ejemplos Intermedios

8. httptest para manejadores HTTP

net/http/httptest registra respuestas sin abrir un puerto real.

import (
	"fmt"
	"net/http"
	"net/http/httptest"
	"testing"
)
 
func TestHelloHandler(t *testing.T) {
	h := http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		fmt.Fprint(w, "ok")
	})
	req := httptest.NewRequest(http.MethodGet, "/", nil)
	rec := httptest.NewRecorder()
	h.ServeHTTP(rec, req)
	if rec.Code != http.StatusOK || rec.Body.String() != "ok" {
		t.Fatalf("got %d %q", rec.Code, rec.Body.String())
	}
}

• NewRecorder captura el estado, las cabeceras y el cuerpo.
• Sin red, las pruebas de manejadores son rápidas y deterministas.
• Empareja con routers como chi, gin o echo de la misma manera.

Relacionado: testify, httptest y Dobles de Prueba - aserciones y fakes de interfaz

9. Aserciones de testify (dependencia opcional)

testify acorta los fallos de comparación con diffs legibles.

go get github.com/stretchr/testify@latest

import (
	"testing"
 
	"github.com/stretchr/testify/assert"
	"github.com/stretchr/testify/require"
)
 
func TestWithTestify(t *testing.T) {
	require.Equal(t, 4, Add(2, 2))
	assert.NotEqual(t, 0, Add(1, 2))
}

• require detiene la prueba en caso de fallo como t.Fatal.
• assert continúa como t.Error.
• Los equipos a menudo permiten testify manteniendo el diseño basado en tablas.

Relacionado: testify, httptest y Dobles de Prueba - mocks y suites

10. Verificaciones de humo de Benchmark y Race

Los benchmarks y -race extienden el mismo comando go test.

import "testing"
 
func BenchmarkAdd(b *testing.B) {
	for b.Loop() {
		Add(1, 2)
	}
}

go test -bench=. -benchmem ./mathutil
go test -race ./...

• b.Loop() (Go 1.24+) reemplaza los bucles manuales b.N y reinicia los temporizadores correctamente.
• -race ralentiza las pruebas pero detecta carreras de datos en código de gorutinas.
• Ejecuta compilaciones de race en CI, no en cada pulsación de tecla.

Relacionado: Benchmarks con testing.B y B.Loop - comparando implementaciones | Pruebas Fuzz con testing.F - corpus de semillas

Versiones de Stack: Esta página fue escrita para Go 1.26.x (Green Tea GC por defecto, go fix modernizadores - verifica el parche en la compilación), chi (última - verifica en la compilación), gin (última - verifica en la compilación), echo (última - verifica en la compilación), google.golang.org/grpc (última - verifica en la compilación), sigs.k8s.io/controller-runtime (última - verifica en la compilación), kubebuilder (última - verifica en la compilación), tinygo (última - verifica objetivos de placa en la compilación), wazero (última - verifica en la compilación) y golangci-lint (última - verifica el conjunto de linters en la compilación).

383k393a3c3q3e393a3o1r3e3k3x383c3e3k1y1t1u3x1v1t1v1z1t20