O Que É Test Sharding?
O test sharding corta uma grande suíte de testes em fatias e roda cada fatia em um runner separado em paralelo, de modo que uma suíte de 30 minutos termina em poucos.
Uma suíte de testes em crescimento acaba dominando o tempo do pipeline. O sharding distribui os testes por N runners para que cada um execute apenas 1/N do trabalho. O shard mais lento define o total, então balancear os shards importa tanto quanto dividi-los.
Como o sharding funciona
Você informa ao runner a contagem total de shards e qual shard ele é - por exemplo --shard=2/4. Cada runner executa apenas os testes atribuídos a ele, e um passo final combina os resultados.
Um pequeno exemplo
Uma matrix sobre shard: [1, 2, 3, 4] lança quatro jobs, cada um rodando playwright test --shard=${{ matrix.shard }}/4. Uma suíte de 32 minutos dividida em quatro termina em cerca de 8, mais um curto passo de fan-in para fazer o merge dos reports.
Balanceando shards
Dividir pela contagem de arquivos é desigual - um arquivo lento pode travar um shard. Ferramentas melhores dividem pelo tempo histórico para que cada shard leve aproximadamente o mesmo wall-clock, minimizando o shard mais lento.
Sharding vs jobs paralelos
O paralelismo roda jobs diferentes ao mesmo tempo; o sharding paraleliza um job particionando seu trabalho. O sharding geralmente combina com uma matrix que enumera os índices de shard.
Combinando resultados
Cada shard emite seu próprio report. Um passo de fan-in baixa todos eles e faz o merge em um único report de cobertura e de testes, para que os revisores vejam um resultado combinado em vez de quatro parciais.
Principais conclusões
- O sharding divide uma suíte em fatias que rodam em paralelo em runners separados.
- Balanceie pelo tempo histórico, não pela contagem de arquivos, para reduzir o shard mais lento.
- Ele combina naturalmente com uma matrix sobre os índices de shard e um merge fan-in.