Testes Paralelos Baseados em Tabelas em Go

Acelere os testes Go com execução paralela

Conteúdo da página

Os testes orientados por tabela são a abordagem idioma de Go para testar múltiplos cenários de forma eficiente. Quando combinados com a execução paralela usando t.Parallel(), você pode reduzir drasticamente o tempo de execução da suíte de testes, especialmente para operações limitadas por E/S (I/O).

No entanto, os testes paralelos introduzem desafios únicos relacionados a condições de corrida e isolamento de testes que exigem atenção cuidadosa.

Testes Paralelos Orientados por Tabela em Go - condições de corrida golang

Compreendendo a Execução Paralela de Testes

O pacote de teste do Go oferece suporte nativo para execução paralela de testes através do método t.Parallel(). Quando um teste chama t.Parallel(), ele sinaliza ao executor de testes que este teste pode ser executado com segurança de forma concorrente com outros testes paralelos. Isso é particularmente poderoso quando combinado com testes orientados por tabela, onde você tem muitos casos de teste independentes que podem ser executados simultaneamente.

O paralelismo padrão é controlado por GOMAXPROCS, que normalmente é igual ao número de núcleos de CPU da sua máquina. Você pode ajustar isso com a bandeira -parallel: go test -parallel 4 limita os testes concorrentes a 4, independentemente da contagem de CPU. Isso é útil para controlar o uso de recursos ou quando os testes têm requisitos de concorrência específicos.

Para desenvolvedores novos em testes de Go, entender os fundamentos é crucial. Nosso guia sobre melhores práticas de testes unitários em Go cobre testes orientados por tabela, subtestes e os fundamentos do pacote de teste que formam a base para a execução paralela.

Padrão Básico de Teste Paralelo Orientado por Tabela

Aqui está o padrão correto para testes paralelos orientados por tabela:

func TestCalculate(t *testing.T) {
    tests := []struct {
        name     string
        a, b     int
        op       string
        expected int
        wantErr  bool
    }{
        {"soma", 2, 3, "+", 5, false},
        {"subtração", 5, 3, "-", 2, false},
        {"multiplicação", 4, 3, "*", 12, false},
        {"divisão", 10, 2, "/", 5, false},
        {"divisão por zero", 10, 0, "/", 0, true},
    }

    for _, tt := range tests {
        tt := tt // Capturar variável de loop
        t.Run(tt.name, func(t *testing.T) {
            t.Parallel() // Habilitar execução paralela
            result, err := Calculate(tt.a, tt.b, tt.op)
            
            if (err != nil) != tt.wantErr {
                t.Errorf("Calculate() error = %v, wantErr %v", err, tt.wantErr)
                return
            }
            
            if result != tt.expected {
                t.Errorf("Calculate(%d, %d, %q) = %d; want %d", 
                    tt.a, tt.b, tt.op, result, tt.expected)
            }
        })
    }
}

A linha crítica é tt := tt antes de t.Run(). Isso captura o valor atual da variável de loop, garantindo que cada subteste paralelo opere em sua própria cópia dos dados do caso de teste.

O Problema de Captura de Variáveis de Loop

Este é um dos erros mais comuns ao usar t.Parallel() com testes orientados por tabela. Em Go, a variável de loop tt é compartilhada entre todas as iterações. Quando os subtestes são executados em paralelo, eles podem todos fazer referência à mesma variável tt, que é sobrescrita à medida que o loop continua. Isso leva a condições de corrida e falhas de teste imprevisíveis.

Incorreto (condição de corrida):

for _, tt := range tests {
    t.Run(tt.name, func(t *testing.T) {
        t.Parallel()
        // Todos os subtestes podem ver o mesmo valor de tt!
        result := Calculate(tt.a, tt.b, tt.op)
    })
}

Correto (variável capturada):

for _, tt := range tests {
    tt := tt // Capturar a variável de loop
    t.Run(tt.name, func(t *testing.T) {
        t.Parallel()
        // Cada subteste tem sua própria cópia de tt
        result := Calculate(tt.a, tt.b, tt.op)
    })
}

A atribuição tt := tt cria uma nova variável escopada à iteração do loop, garantindo que cada goroutine tenha sua própria cópia dos dados do caso de teste.

Garantindo a Independência dos Testes

Para que os testes paralelos funcionem corretamente, cada teste deve ser completamente independente. Eles não devem:

  • Compartilhar estado global ou variáveis
  • Modificar recursos compartilhados sem sincronização
  • Depender da ordem de execução
  • Acessar os mesmos arquivos, bancos de dados ou recursos de rede sem coordenação

Exemplo de testes paralelos independentes:

func TestValidateEmail(t *testing.T) {
    tests := []struct {
        name    string
        email   string
        wantErr bool
    }{
        {"e-mail válido", "user@example.com", false},
        {"formato inválido", "not-an-email", true},
        {"domínio ausente", "user@", true},
    }

    for _, tt := range tests {
        tt := tt
        t.Run(tt.name, func(t *testing.T) {
            t.Parallel()
            err := ValidateEmail(tt.email)
            if (err != nil) != tt.wantErr {
                t.Errorf("ValidateEmail(%q) error = %v, wantErr %v", 
                    tt.email, err, tt.wantErr)
            }
        })
    }
}

Cada caso de teste opera em seus próprios dados de entrada sem estado compartilhado, tornando-o seguro para execução paralela.

Detectando Condições de Corrida

Go fornece um detector de corrida poderoso para capturar corridas de dados em testes paralelos. Sempre execute seus testes paralelos com a bandeira -race durante o desenvolvimento:

go test -race ./...

O detector de corrida reportará qualquer acesso concorrente à memória compartilhada sem sincronização adequada. Isso é essencial para capturar bugs sutis que podem aparecer apenas sob condições de tempo específicas.

Exemplo de condição de corrida:

var counter int // Estado compartilhado - PERIGOSO!

func TestIncrement(t *testing.T) {
    tests := []struct {
        name string
        want int
    }{
        {"test1", 1},
        {"test2", 2},
    }

    for _, tt := range tests {
        tt := tt
        t.Run(tt.name, func(t *testing.T) {
            t.Parallel()
            counter++ // CONDIÇÃO DE CORRIDA!
            if counter != tt.want {
                t.Errorf("counter = %d, want %d", counter, tt.want)
            }
        })
    }
}

Executar isso com -race detectará a modificação concorrente de counter. A correção é tornar cada teste independente usando variáveis locais em vez de estado compartilhado.

Benefícios de Desempenho

A execução paralela pode reduzir significativamente o tempo de execução da suíte de testes. O ganho de velocidade depende de:

  • Número de núcleos de CPU: Mais núcleos permitem que mais testes sejam executados simultaneamente
  • Características dos testes: Testes limitados por E/S se beneficiam mais do que testes limitados por CPU
  • Contagem de testes: Suítes de testes maiores veem economias de tempo absolutas maiores

Medindo o desempenho:

# Execução sequencial
go test -parallel 1 ./...

# Execução paralela (padrão)
go test ./...

# Paralelismo personalizado
go test -parallel 8 ./...

Para suítes de testes com muitas operações de E/S (consultas de banco de dados, solicitações HTTP, operações de arquivo), você pode frequentemente alcançar um aumento de 2 a 4x em sistemas multicore modernos. Testes limitados por CPU podem ver menos benefícios devido à disputa por recursos de CPU.

Controlando o Paralelismo

Você tem várias opções para controlar a execução paralela de testes:

1. Limitar o número máximo de testes paralelos:

go test -parallel 4 ./...

2. Definir GOMAXPROCS:

GOMAXPROCS=2 go test ./...

3. Execução paralela seletiva:

Marque apenas testes específicos com t.Parallel(). Testes sem esta chamada são executados sequencialmente, o que é útil quando alguns testes devem ser executados em ordem ou compartilhar recursos.

4. Execução paralela condicional:

func TestExpensive(t *testing.T) {
    if testing.Short() {
        t.Skip("pulando teste caro no modo curto")
    }
    t.Parallel()
    // Lógica do teste caro
}

Padrões Comuns e Melhores Práticas

Padrão 1: Configuração Antes da Execução Paralela

Se você precisa de uma configuração compartilhada para todos os casos de teste, faça isso antes do loop:

func TestWithSetup(t *testing.T) {
    // Código de configuração é executado uma vez, antes da execução paralela
    db := setupTestDatabase(t)
    defer db.Close()

    tests := []struct {
        name string
        id   int
    }{
        {"user1", 1},
        {"user2", 2},
    }

    for _, tt := range tests {
        tt := tt
        t.Run(tt.name, func(t *testing.T) {
            t.Parallel()
            // Cada teste usa db independentemente
            user := db.GetUser(tt.id)
            // Lógica do teste...
        })
    }
}

Padrão 2: Configuração por Teste

Para testes que precisam de configuração isolada, faça isso dentro de cada subteste:

func TestWithPerTestSetup(t *testing.T) {
    tests := []struct {
        name string
        data string
    }{
        {"test1", "data1"},
        {"test2", "data2"},
    }

    for _, tt := range tests {
        tt := tt
        t.Run(tt.name, func(t *testing.T) {
            t.Parallel()
            // Cada teste recebe sua própria configuração
            tempFile := createTempFile(t, tt.data)
            defer os.Remove(tempFile)
            // Lógica do teste...
        })
    }
}

Padrão 3: Misto Sequencial e Paralelo

Você pode misturar testes sequenciais e paralelos no mesmo arquivo:

func TestSequential(t *testing.T) {
    // Sem t.Parallel() - executa sequencialmente
    // Bom para testes que devem ser executados em ordem
}

func TestParallel(t *testing.T) {
    tests := []struct{ name string }{{"test1"}, {"test2"}}
    for _, tt := range tests {
        tt := tt
        t.Run(tt.name, func(t *testing.T) {
            t.Parallel() // Estes são executados em paralelo
        })
    }
}

Quando NÃO Usar Execução Paralela

A execução paralela nem sempre é apropriada. Evite-a quando:

  1. Testes compartilham estado: Variáveis globais, singletons ou recursos compartilhados
  2. Testes modificam arquivos compartilhados: Arquivos temporários, bancos de dados de teste ou arquivos de configuração
  3. Testes dependem da ordem de execução: Alguns testes devem ser executados antes de outros
  4. Testes já são rápidos: A sobrecarga da paralelização pode exceder os benefícios
  5. Restrições de recursos: Testes consomem memória ou CPU demais quando paralelizados

Para testes relacionados a banco de dados, considere usar rollback de transações ou bancos de dados de teste separados por teste. Nosso guia sobre padrões de banco de dados multi-inquilino em Go cobre estratégias de isolamento que funcionam bem com testes paralelos.

Avançado: Testando Código Concorrente

Ao testar código concorrente em si (não apenas executando testes em paralelo), você precisa de técnicas adicionais:

func TestConcurrentOperation(t *testing.T) {
    tests := []struct {
        name      string
        goroutines int
    }{
        {"2 goroutines", 2},
        {"10 goroutines", 10},
        {"100 goroutines", 100},
    }

    for _, tt := range tests {
        tt := tt
        t.Run(tt.name, func(t *testing.T) {
            t.Parallel()
            
            var wg sync.WaitGroup
            results := make(chan int, tt.goroutines)
            
            for i := 0; i < tt.goroutines; i++ {
                wg.Add(1)
                go func() {
                    defer wg.Done()
                    results <- performOperation()
                }()
            }
            
            wg.Wait()
            close(results)
            
            // Verificar resultados
            count := 0
            for range results {
                count++
            }
            if count != tt.goroutines {
                t.Errorf("expected %d results, got %d", tt.goroutines, count)
            }
        })
    }
}

Sempre execute esses testes com -race para detectar condições de corrida no código sob teste.

Integração com CI/CD

Testes paralelos integram-se perfeitamente com pipelines de CI/CD. A maioria dos sistemas de CI fornece múltiplos núcleos de CPU, tornando a execução paralela altamente benéfica:

# Exemplo GitHub Actions
- name: Executar testes
  run: |
    go test -race -coverprofile=coverage.out -parallel 4 ./...
    go tool cover -html=coverage.out -o coverage.html

A bandeira -race é especialmente importante no CI para capturar bugs de concorrência que podem não aparecer no desenvolvimento local.

Depurando Falhas em Testes Paralelos

Quando testes paralelos falham intermitentemente, a depuração pode ser desafiadora:

  1. Executar com -race: Identificar corridas de dados
  2. Reduzir paralelismo: go test -parallel 1 para ver se as falhas desaparecem
  3. Executar testes específicos: go test -run TestName para isolar o problema
  4. Adicionar logs: Use t.Log() para rastrear a ordem de execução
  5. Verificar estado compartilhado: Procure por variáveis globais, singletons ou recursos compartilhados

Se os testes passam sequencialmente mas falham em paralelo, provavelmente você tem uma condição de corrida ou problema de estado compartilhado.

Exemplo do Mundo Real: Testando Handlers HTTP

Aqui está um exemplo prático de teste de handlers HTTP em paralelo:

func TestHTTPHandlers(t *testing.T) {
    router := setupRouter()
    
    tests := []struct {
        name       string
        method     string
        path       string
        statusCode int
    }{
        {"GET users", "GET", "/users", 200},
        {"GET user by ID", "GET", "/users/1", 200},
        {"POST user", "POST", "/users", 201},
        {"DELETE user", "DELETE", "/users/1", 204},
    }

    for _, tt := range tests {
        tt := tt
        t.Run(tt.name, func(t *testing.T) {
            t.Parallel()
            
            req := httptest.NewRequest(tt.method, tt.path, nil)
            w := httptest.NewRecorder()
            
            router.ServeHTTP(w, req)
            
            if w.Code != tt.statusCode {
                t.Errorf("expected status %d, got %d", tt.statusCode, w.Code)
            }
        })
    }
}

Cada teste usa httptest.NewRecorder(), que cria um gravador de resposta isolado, tornando esses testes seguros para execução paralela.

Conclusão

A execução paralela de testes orientados por tabela é uma técnica poderosa para reduzir o tempo de execução da suíte de testes em Go. A chave para o sucesso é entender o requisito de captura de variáveis de loop, garantir a independência dos testes e usar o detector de corrida para capturar problemas de concorrência cedo.

Lembre-se:

  • Sempre capture variáveis de loop: tt := tt antes de t.Parallel()
  • Garanta que os testes sejam independentes, sem estado compartilhado
  • Execute testes com -race durante o desenvolvimento
  • Controle o paralelismo com a bandeira -parallel quando necessário
  • Evite execução paralela para testes que compartilham recursos

Seguindo essas práticas, você pode aproveitar com segurança a execução paralela para acelerar suas suítes de testes, mantendo a confiabilidade. Para mais padrões de teste em Go, veja nosso guia abrangente de testes unitários em Go, que cobre testes orientados por tabela, mocking e outras técnicas essenciais de teste.

Ao construir aplicativos Go maiores, essas práticas de teste se aplicam em diferentes domínios. Por exemplo, ao construir aplicativos CLI com Cobra & Viper, você usará padrões de teste paralelos semelhantes para testar handlers de comandos e parsing de configuração.

Recursos Externos

Assinar

Receba novos artigos sobre sistemas, infraestrutura e engenharia de IA.