Noções Básicas de Testes em Go

10 exemplos para você começar com Testes e Fuzzing - 7 básicos e 3 intermediários.

Pré-requisitos

• Instale o Go 1.26.x ou posterior em go.dev/dl.
• Crie um módulo: mkdir testing-demo && cd testing-demo && go mod init example.com/testing-demo.
• Nenhum executor de teste adicional é necessário; go test está integrado à toolchain.

go version
go test ./...

Exemplos Básicos

1. Sua primeira função de Teste

Um teste é uma função comum chamada TestXxx que recebe *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 o teste como falho e para a função atual.
• Arquivos de teste terminam em _test.go e ficam ao lado do código de produção.
• Execute com go test a partir da raiz do módulo.

Relacionado: Cultura de Testes em Go: Simples, Rápido, Orientado por Tabela - por que os testes em Go se parecem com isso

2. Execute testes para um pacote

go test aceita padrões de pacotes como compilações de produção.

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

• -v imprime o nome de cada teste à medida que ele é executado.
• ./... percorre todos os pacotes sob o módulo.
• O código de saída é diferente de zero quando qualquer teste falha - ideal para CI.

Relacionado: Cobertura, Detector de Corrida e Arquivos Golden - flags além do go test simples

3. Casos orientados por tabela

Colete entradas e expectativas em um slice, depois itere.

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)
		}
	}
}

• Adicionar um caso é um único literal de struct, não uma nova função.
• Mantenha os nomes dos campos curtos, mas significativos (want, input, err).
• Tabelas são o padrão padrão em todo o ecossistema Go.

Relacionado: Testes Orientados por Tabela e Subtestes - t.Run e configuração compartilhada

4. Subtestes com t.Run

Subtestes nomeiam cada caso na saída de falha.

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)
			}
		})
	}
}

• Filtre um caso: go test -run TestAddSub/zeros.
• Subtestes podem chamar t.Parallel() para casos concorrentes.
• Sempre dê a name uma string distinta por linha.

Relacionado: Testes Orientados por Tabela e Subtestes - tabelas paralelas e helpers de configuração

5. t.Helper para asserções compartilhadas

Marque funções helper para que as falhas relatem a linha do chamador.

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)
}

• Sem t.Helper(), as falhas apontam para dentro do helper, não para o teste.
• Helpers mantêm as tabelas legíveis sem duplicar if got != want.
• Helpers podem viver em export_test.go ou em um subpacote testing para reutilização.

6. t.Error vs t.Fatal

Error registra a falha e continua; Fatal para a função de teste atual.

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")
}

• Use Fatal quando as asserções posteriores assumem o estado anterior.
• A saída de Log aparece com -v ou em caso de falha.
• Subtestes isolam falhas melhor do que muitas chamadas Error em uma única função.

7. Pacote de teste externo

package foo_test importa o módulo como os consumidores fazem.

// em 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")
	}
}

• Testes externos só acessam identificadores exportados.
• Eles documentam a superfície da API pública.
• Testes internos (package mathutil) podem acessar helpers não exportados.

Relacionado: Exemplos como Documentação Executável - exemplos do godoc em arquivos de teste

Exemplos Intermediários

8. httptest para manipuladores HTTP

net/http/httptest registra respostas sem abrir uma porta 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 status, cabeçalhos e corpo.
• Nenhuma rede significa testes de manipulador rápidos e determinísticos.
• Emparelhe com roteadores como chi, gin ou echo da mesma forma.

Relacionado: testify, httptest e Test Doubles - asserções e fakes de interface

9. Asserções testify (dependência opcional)

testify encurta falhas de comparação com diffs legíveis.

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 para o teste em caso de falha como t.Fatal.
• assert continua como t.Error.
• Equipes frequentemente permitem testify, mantendo o layout orientado por tabela.

Relacionado: testify, httptest e Test Doubles - mocks e suites

10. Verificações de fumaça de Benchmark e race

Benchmarks e -race estendem o mesmo 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+) substitui loops manuais b.N e redefine os temporizadores corretamente.
• -race retarda os testes, mas captura corridas de dados em código de goroutine.
• Execute compilações de corrida em CI, não a cada pressionamento de tecla.

Relacionado: Benchmarks com testing.B & B.Loop - comparando implementações | Fuzz Testing com testing.F - corpora de sementes

Versões de Stack: Esta página foi escrita para Go 1.26.x (padrão Green Tea GC, go fix modernizers - verifique o patch na compilação), chi (latest - verifique na compilação), gin (latest - verifique na compilação), echo (latest - verifique na compilação), google.golang.org/grpc (latest - verifique na compilação), sigs.k8s.io/controller-runtime (latest - verifique na compilação), kubebuilder (latest - verifique na compilação), tinygo (latest - verifique os alvos de placa na compilação), wazero (latest - verifique na compilação) e golangci-lint (latest - verifique o conjunto de linters na compilação).

383k393a3c3q3e393a3o1r3e3k3x383c3e3k1y1t1u3x1v1t1v1z1t20