Parallel test execution: distribuindo testes com base em mudanças

1. Introdução ao problema: por que paralelizar testes com base em mudanças?

1.1. O gargalo do pipeline sequencial: tempo de execução vs. frequência de deploys

Em pipelines tradicionais, a execução de testes ocorre de forma sequencial: um por um, até que todos passem. Em projetos de médio e grande porte, uma suíte completa pode levar de 30 minutos a várias horas. Esse tempo inviabiliza deploys frequentes — o famoso "commit-to-deploy" em minutos. A pressão por feedback rápido coloca a paralelização como necessidade, não como luxo.

1.2. Limitações de estratégias ingênuas: divisão round-robin e aleatoriedade

Estratégias simples como round-robin (distribuir testes em ordem cíclica entre workers) ou aleatoriedade pura falham em dois pontos críticos: (a) não consideram o tempo de execução de cada teste, gerando workers ociosos ou sobrecarregados; (b) não levam em conta quais testes são realmente relevantes para as mudanças feitas. O resultado é desperdício de recursos computacionais e tempo de espera desnecessário.

1.3. O papel do Git: detectando quais arquivos mudaram para decidir o que testar

O Git oferece a base para uma estratégia mais inteligente: ao invés de executar todos os testes, podemos identificar exatamente quais arquivos foram modificados em um Pull Request (PR) ou branch, e mapear esses arquivos para os testes que os cobrem. Dessa forma, apenas os testes afetados são executados — e o restante é ignorado ou delegado a execuções noturnas.

2. Mapeando mudanças do Git para conjuntos de testes

2.1. Comandos essenciais: git diff, git log, git merge-base

Para descobrir o que mudou entre duas branches, usamos:

git diff --name-only origin/main...HEAD

Esse comando lista todos os arquivos modificados entre a branch atual e a main. Para obter a base de comparação correta, git merge-base é útil:

git merge-base origin/main HEAD

Combinando com git log, podemos obter o hash do commit base e garantir que a diff seja precisa mesmo após rebases.

2.2. Construindo uma matriz de dependências: arquivo-fonte → testes afetados

A matriz de dependências é um mapeamento explícito entre cada arquivo de código e os testes que o cobrem. Pode ser gerada estaticamente (via análise de imports) ou dinamicamente (via ferramentas de cobertura). Um exemplo simples em JSON:

{
  "src/services/payment.js": ["test/services/payment.test.js"],
  "src/utils/format.js": ["test/utils/format.test.js", "test/integration/api.test.js"]
}

2.3. Exemplo prático: extraindo lista de arquivos modificados em um PR

#!/bin/bash
# extrai_arquivos_modificados.sh
BASE=$(git merge-base origin/main HEAD)
MODIFIED=$(git diff --name-only "$BASE"...HEAD)
echo "$MODIFIED"

Saída típica:

src/services/payment.js
src/utils/format.js
README.md

Com essa lista, consultamos a matriz de dependências para obter os testes relevantes.

3. Estratégias de particionamento inteligente de testes

3.1. Particionamento baseado em histórico de execução (balancing dinâmico)

Cada teste tem um tempo médio de execução registrado em execuções anteriores. Ao distribuir os testes entre workers, o algoritmo aloca os testes mais longos primeiro e preenche com os mais curtos, equilibrando a carga total por worker.

3.2. Particionamento por tempo estimado (weighted distribution)

Atribui-se um peso (tempo estimado) a cada teste. A soma dos pesos em cada worker deve ser aproximadamente igual. Exemplo com três workers e quatro testes:

Teste A: 10s
Teste B: 20s
Teste C: 15s
Teste D: 5s

Worker 1: A (10s) + D (5s) = 15s
Worker 2: B (20s) = 20s
Worker 3: C (15s) = 15s

3.3. Particionamento por afinidade de módulo (testes do mesmo componente no mesmo worker)

Testes que compartilham setup (banco de dados, mocks) são agrupados no mesmo worker para evitar duplicação de recursos. Isso reduz o tempo de inicialização e evita contenção.

4. Integração com ferramentas de CI/CD

4.1. Gerando a lista de testes a executar via script Git + ferramenta de teste

Com a lista de arquivos modificados e a matriz de dependências, geramos um arquivo de configuração:

# gerar_testes.sh
MODIFIED=$(git diff --name-only origin/main...HEAD)
for file in $MODIFIED; do
  grep "$file" dependencias.json | jq -r '.[]' >> testes_a_executar.txt
done
sort -u testes_a_executar.txt -o testes_a_executar.txt

4.2. Passando parâmetros para workers paralelos: --shard vs. lista customizada

Ferramentas como Jest suportam --shard:

npx jest --shard=1/3

Já o pytest pode receber uma lista explícita:

pytest $(cat testes_a_executar.txt) -n 4

4.3. Exemplo de pipeline YAML: GitHub Actions com matriz dinâmica

jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        shard: [1, 2, 3, 4]
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - name: Extrair testes afetados
        run: |
          ./gerar_testes.sh
          split -n l/4 testes_a_executar.txt shard_${{ matrix.shard }}_
      - name: Executar testes
        run: npx jest $(cat shard_${{ matrix.shard }}_*)

5. Tratamento de dependências e testes não mapeados

5.1. Testes de integração e E2E: como lidar quando a mudança é transversal

Testes de integração que dependem de múltiplos módulos devem ser executados sempre que qualquer um dos módulos envolvidos mudar. A matriz de dependências precisa incluir essas relações transitivas.

5.2. Testes obrigatórios mínimos (sanity checks) mesmo sem mudanças aparentes

Mesmo que nenhum arquivo de código mude (ex.: mudança apenas em README), um conjunto mínimo de testes de fumaça deve ser executado para garantir que o ambiente de CI está íntegro.

5.3. Fallback para execução completa quando a análise de impacto é inconclusiva

Se a matriz de dependências não cobrir um arquivo modificado, ou se o número de testes afetados for muito grande, o fallback seguro é executar a suíte completa.

6. Otimizações avançadas com Git

6.1. Cache de resultados de git diff entre execuções para evitar recomputação

O resultado do git diff pode ser armazenado em cache (ex.: arquivo .git_diff_cache) e reutilizado se o HEAD não mudou. Isso reduz o tempo de preparação do pipeline.

6.2. Uso de git blame para associar mudanças a times/autores e priorizar testes

Com git blame, podemos identificar quais times são responsáveis por cada arquivo modificado e priorizar a execução dos testes desses times primeiro, dando feedback mais rápido para os autores das mudanças.

6.3. Monitoramento de falsos negativos: quando o Git não captura mudanças em metadados

Mudanças em permissões de arquivos, submodules ou arquivos binários podem não ser detectadas por git diff --name-only se a opção --diff-filter não for configurada corretamente. Use:

git diff --name-only --diff-filter=ACMRT origin/main...HEAD

7. Métricas e monitoramento da estratégia

7.1. Comparando tempo de pipeline antes e depois da paralelização inteligente

Métricas como "tempo médio de pipeline" e "p95 de tempo de execução" devem ser monitoradas. Ferramentas como Datadog ou Grafana podem ingerir esses dados a partir de logs de CI.

7.2. Rastreamento de cobertura: quantos testes foram realmente executados vs. ignorados

Um dashboard simples pode mostrar:

Total de testes na suíte: 5.000
Testes executados no PR: 320 (6,4%)
Testes ignorados: 4.680 (93,6%)

7.3. Alertas para degradação: aumento repentino de tempo de execução ou falhas não detectadas

Se o tempo de pipeline aumentar em mais de 20% em relação à média dos últimos 7 dias, um alerta deve ser disparado. Da mesma forma, se testes que deveriam ter sido executados (com base na matriz) forem ignorados, um alarme de "falso negativo" deve ser acionado.

8. Conclusão e próximos passos

8.1. Recapitulação dos ganhos

A paralelização inteligente com base em mudanças no Git reduz o tempo de pipeline em 60-80% em projetos com suítes grandes, acelera o feedback para desenvolvedores e economiza recursos de CI (menos workers, menos tempo de execução).

8.2. Limitações conhecidas

A principal limitação é a manutenção da matriz de dependências. Se ela não for atualizada conforme o código evolui, testes podem ser ignorados incorretamente. Soluções automatizadas (análise estática de código) são recomendadas.

8.3. Integração com temas vizinhos

Esta estratégia se combina bem com shallow clones (para acelerar o checkout), cache de dependências (para evitar reinstalações desnecessárias) e preview environments (para testar em ambientes efêmeros antes do merge).

Referências