Aumente a cobertura de testes em paralelo com uma squad

Quando usar uma squad de cobertura de testes?

Use quando você tem dívida de testes espalhada por vários módulos que não dependem uns dos outros. É o mesmo tipo de tarefa repetido, e é exatamente isso que várias cópias de um membro fazem bem em paralelo.

• Antes de uma refatoração arriscada, para travar o comportamento atual.
• Depois de uma feature que saiu sem testes, módulo por módulo.
• Não serve para código cujo comportamento esperado não está claro. Os testes iam congelar bugs; defina o comportamento antes.

Como montar a squad?

Abra Squads → Nova squad e escolha Líder divide o trabalho. Deixe um membro só, coloque Quantos = 4 e reescreva a função. Todas as cópias têm o mesmo agente, modelo, esforço e função; o líder decide qual módulo cada uma pega.

Qual objetivo colar?

Dê uma meta de cobertura, o comando que mede e as regras de um bom teste. Sem regras, os agentes correm atrás do número.

Aumentar a cobertura de linhas de src/billing para 80%.

Como medir
- pnpm test --coverage src/billing mostra a cobertura por arquivo.

Regras
- Testar comportamento pelas funções públicas. Nada de teste só de snapshot.
- Sem relógio real nem rede: usar fake timers e o mock do Stripe que já existe.
- Não alterar código de produção. Se algo parecer código morto, me pergunte.

Pronto quando
- src/billing estiver em 80% ou mais e a suíte completa passar.
- O relatório listar a cobertura por módulo, antes e depois.

Nas Instruções do líder, acrescente: "Meça primeiro. Dê para cada cópia um módulo abaixo de 60%. Junte todos os branches no seu worktree e rode a suíte completa antes de reportar."

Quais limites definir?

Coloque 3 rodadas e 4 membros ao mesmo tempo, igual ao número de cópias. Escrever testes raramente pede ciclos longos: uma rodada para escrever, uma para refazer o que travou, uma de folga.

Pague a dívida de testes numa execução só. Coloque Quantos = 4 e inicie.

Baixar o Tallos →

Como a execução acontece?

Uma execução de exemplo. Nomes de módulos, número de testes e percentuais de cobertura são ilustrativos, não um resultado para esperar no seu código.

1. 1

   O líder mede

   Encontra quatro módulos de billing abaixo de 60%: invoices, tax, refunds, plans. Um módulo por cópia.

2. 2

   Quatro cópias escrevem testes em paralelo

   No exemplo: invoices ganha 31 testes (58% → 86%), tax ganha 22 (47% → 81%).

3. 3

   Uma cópia trava

   A cópia de refunds esbarra num relógio instável e falha. A tela da squad conta em Falharam.

4. 4

   Rodada 2: refazer

   O líder inicia uma cópia nova em refunds, com instrução de usar fake timers. Passa.

5. 5

   Uma pergunta para você

   plans.ts tem código morto. Apagar ou testar? Você responde: apagar.

6. 6

   Juntar e reportar

   O líder junta todos os branches no próprio worktree, roda a suíte completa e entrega o relatório com tallos squad report.

Neste exemplo os contadores terminam em 2 rodadas, 5 iniciadas, 4 concluídas e 1 que falhou: a cópia travada mais a substituta explicam o início a mais.

O que o líder pode te perguntar?

Squads de cobertura perguntam quando um teste exige uma decisão sobre o código testado. Você escolhe uma opção ou escreve a sua resposta.

• "plans.ts tem código morto. Apagar ou testar?"
• "Esta função devolve resultados diferentes em dois caminhos. Qual está certo?"
• "Dois módulos compartilham um arquivo de fixtures. Quem pode alterá-lo?"

O que você recebe no final?

• Relatório final: cobertura por módulo antes e depois, o que ficou de fora e por quê. No exemplo: 97 testes novos em quatro módulos, /billing em 83%, relógio instável resolvido com fake timers, código morto de plans.ts removido.
• Resultados por worktree: o branch combinado do líder marcado como Recomendado, mais o worktree de cada cópia, se você quiser olhar um módulo isolado.
• Aceitar ou Descartar: Aceitar transforma a linha recomendada em Abrir para criar PR. Descartar também pode apagar os worktrees dos membros.

Um diff grande de testes é fácil de passar o olho e difícil de revisar. Confira as asserções, não só a contagem; veja como revisar código gerado por IA.

Quais variações funcionam bem?

• Adicione um revisor de testes. Um segundo membro com a função "Revisa os testes novos em busca de asserções que fazem sentido. Recusa teste que só sobe o número."
• Misture agentes. Dois membros com a mesma função em agentes diferentes, Quantos = 2 cada.
• Não deixe cair. Salve a squad e rode toda semana, como a squad de manutenção agendada.
• Testes para uma feature nova. Rode antes a squad de entregar uma feature e depois esta nos módulos novos.

Quais são os erros mais comuns?

• Correr atrás do número. Sem regras, vêm testes sem asserção de verdade. Escreva as regras no objetivo.
• Módulos que se sobrepõem. Duas cópias editando o mesmo arquivo de fixtures viram conflito na hora de juntar. Defina um dono.
• Membros ao mesmo tempo abaixo de Quantos. As cópias entram na fila em vez de rodar juntas.
• Relógio real e rede nos testes. Deixam os testes instáveis e queimam rodadas em tentativas.

Comece por sua primeira squad, veja como as squads funcionam ou entenda por que este é um caso clássico de rodar agentes de IA em paralelo.