Testing with testify & mockery

El paquete testing de Go es suficiente para la corrección, pero testify mejora los mensajes de error y mockery genera implementaciones simuladas a partir de interfaces.

Juntos, aceleran las pruebas basadas en tablas, las comprobaciones de manejadores HTTP y los dobles de capa de servicio sin abandonar las interfaces idiomáticas de Go.

Receta

Tarjeta de receta de referencia rápida - lista para copiar y pegar.

import (
    "testing"
    "github.com/stretchr/testify/require"
)
 
func TestSum(t *testing.T) {
    require.Equal(t, 5, sum(2, 3))
}

# mockery v2+ (instala el binario por separado)
mockery --name=UserRepository --dir=./internal/user --output=./internal/user/mocks

Cuándo usar esto:

• Pruebas con muchas comprobaciones de igualdad donde el ruido de t.Fatalf oculta la primera diferencia
• Suites de estilo de integración que comparten servidores httptest y bases de datos
• Servicios definidos contra interfaces que necesitan mocks generados en CI
• Equipos que estandarizan el estilo de aserción en docenas de paquetes

Ejemplo de trabajo

package user_test
 
import (
    "context"
    "errors"
    "testing"
 
    "github.com/stretchr/testify/assert"
    "github.com/stretchr/testify/mock"
    "github.com/stretchr/testify/require"
 
    "example.com/libdemo/internal/user"
)
 
type mockRepo struct{ mock.Mock }
 
func (m *mockRepo) FindByID(ctx context.Context, id string) (user.User, error) {
    args := m.Called(ctx, id)
    return args.Get(0).(user.User), args.Error(1)
}
 
func TestService_GetUser(t *testing.T) {
    repo := new(mockRepo)
    repo.On("FindByID", mock.Anything, "u1").Return(user.User{ID: "u1"}, nil)
 
    svc := user.NewService(repo)
    got, err := svc.GetUser(context.Background(), "u1")
    require.NoError(t, err)
    assert.Equal(t, "u1", got.ID)
    repo.AssertExpectations(t)
}
 
func TestService_GetUser_NotFound(t *testing.T) {
    repo := new(mockRepo)
    repo.On("FindByID", mock.Anything, "missing").Return(user.User{}, errors.New("not found"))
 
    svc := user.NewService(repo)
    _, err := svc.GetUser(context.Background(), "missing")
    require.Error(t, err)
}

Lo que esto demuestra:

• require para precondiciones fatales, assert para comprobaciones adicionales en la misma prueba
• Mock escrito a mano usando mock.Mock de testify (mockery genera esta forma)
• AssertExpectations verifica que todas las llamadas esperadas ocurrieron
• La expansión basada en tablas es natural: añade casos a una rebanada y bucla

Inmersión Profunda

Cómo funciona

• testify/assert registra fallos y continúa; require detiene la prueba inmediatamente.
• testify/suite incrusta suite.Suite para ganchos de configuración/desmontaje en métodos llamados TestX.
• mockery lee las definiciones de interfaz y emite structs simulados tipados con ayudantes On/Return.
• Go prefiere interfaces pequeñas en el consumidor; mockery apunta a esas interfaces, no a structs concretos.

require vs assert

Flujo de trabajo de mockery

1. Define type UserRepository interface { ... } en el paquete de producción.
2. Ejecuta mockery en CI o go generate con una directiva //go:generate.
3. Confirma los mocks generados o regenéralos en CI antes de la prueba (política del equipo).
4. Prefiere fakes (mapas en memoria) cuando el comportamiento es simple; mocks cuando se verifican contratos de llamada.

Notas de Go

//go:generate mockery --name=UserRepository --output=./mocks --outpkg=mocks

• Mantén los mocks en subpaquetes mocks para evitar ciclos de importación.
• Pasa context.Context a través de los mocks de la misma manera que lo hace el código de producción.
• No simules tipos de la biblioteca estándar; envuelve los clientes externos detrás de tu interfaz en su lugar.

Trampas

• Simular tipos concretos en exceso - mockery necesita interfaces; simular structs acopla las pruebas a la implementación. Solución: extrae interfaces estrechas en el punto de llamada.
• Afirmar cadenas de error - frágil cuando los mensajes cambian. Solución: usa errors.Is / errors.As con ErrorIs de testify.
• Estado global de la suite - los campos compartidos mutan entre pruebas paralelas. Solución: ejecuta suites sin t.Parallel() o aísla el estado por prueba.
• Mocks generados obsoletos - los cambios de interfaz rompen la compilación en CI. Solución: go generate ./... en CI o pre-commit.
• Abuso de mock.Anything - oculta argumentos incorrectos. Solución: usa mock.MatchedBy para comparadores parciales cuando sea necesario.
• testify en bibliotecas - publicar paquetes no debe forzar testify a los consumidores. Solución: mantén las aserciones solo en archivos _test.go.

Alternativas

Preguntas frecuentes

Relacionado

• testify, httptest & Test Doubles - httptest y fakes
• Conceptos básicos de bibliotecas esenciales - aserción rápida de testify
• Conceptos básicos de pruebas de Go - patrones basados en tablas
• Definición e implementación de interfaces - diseño de interfaces para mocks
• Capas de Handler, Service, Repository - dónde se adjuntan los dobles

Versiones de Stack: Esta página fue escrita para Go 1.26.x (predeterminado GC de Green Tea, go fix modernizers - 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 los objetivos de la 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). NzA2MjAyfDA5NG9pZ2N8b2kuc2VkaXVnZWRvYw==