O que é ping pong ping pong e como ele funciona na prática
A técnica de ping pong ping pong é basicamente um exercício de par programação onde dois desenvolvedores alternam entre escrever testes que falham e código que os faz passar. Um pilota, escreve um teste que não passa, depois o outro roda e vê a falha. Em seguida, o segundo pilota escreve a implementação mínima para passar no teste. Aí viram. É isso. Não é mágica, é um método que alguns times usam quando precisam manter o ritmo de TDD sem travar. O problema é que muita gente leva isso muito a sério e acaba criando mais atrito do que valor. Já vi equipes perderem duas horas num teste que podia ser resolvido com uma única função de cinco linhas. O ciclo de ping pong ping pong funciona quando o problema é pequeno o suficiente pra caber em um único red-green-refactor. Quando o escopo cresce, a coisa desanda rápido.
Como rodar ping pong ping pong do jeitinho certo
Comece definindo qual linguagem e framework vocês vão usar. Isso não parece importante, mas muda tudo. Se forem usar Python com pytest, por exemplo, preparem o ambiente de testes antes. Instalação do pytest, configuração do arquivo de fixture, isso já gasta uns dez minutos. Fazer isso no meio do exercício é perda de tempo. O primeiro piloto escreve um teste que descreve um comportamento que ainda não existe. Nada grandioso. Um teste simples que verifica se uma função retorna o valor esperado. Deixa o teste falhar. Passa a vez. O segundo piloto roda o teste, vê a falha, e escreve a menor implementação possível pra fazer passar. Não tenta resolver o problema todo. Só o que o teste pede.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Depois do teste passar, viram e o novo piloto escreve o próximo teste. O ciclo se repete. A chave aqui é manter cada iteração pequena. Se o teste exige mais do que uma ou duas linhas de implementação, o teste tá errado, não a técnica. Eu já tuve um problema com isso quando tentei aplicar ping pong ping pong num projeto de parsing de CSV onde a dependência entre etapas era maior do que eu esperava. O primeiro piloto escreveu um teste pra validar uma linha, o segundo piloto implementou, passou o teste. Aí o próximo teste precisava de uma funcionalidade que dependia de três passos anteriores. O teste falhava não por erro de lógica, mas porque o estado do sistema não estava pronto. A solução foi quebri aquele teste em três testes menores e fui construindo camadas. demorou mais no início, mas depois ficou muito mais rápido avançar.
O que todo mundo erra na hora de fazer ping pong ping pong
O erro mais comum é escrever testes ambiciosos demais no começo. O primeiro piloto acha que precisa testar tudo de uma vez e acaba criando um caso de teste com five assertions que só falha quando você junta três condições diferentes. Isso quebra o ciclo porque o segundo piloto não sabe por onde começar a implementação. A regra prática é: um teste, uma afirmação clara. Se você precisar de mais de uma linha no assert, reveja o teste. Outro erro é não rodar os testes entre cada virada de piloto. Parece bobo, mas acontece bastante. O piloto atualiza o código, passa a vez sem verificar se o teste anterior ainda passa, e o próximo pilota começa num estado quebrado. Cinco minutos de teste rodando antes de cada troca resolvem isso.
Também tem o problema de tentar usar ping pong ping pong em codebase que não foi projetado para ser testável. Se a arquitetura do projeto não permite injeção de dependência ou separação de preocupações, o teste vai depender de coisas externas como banco de dados, arquivos ou APIs. Aí o ciclo de red-green-refactor vira um pesadelo de mocks e fixtures. Nesses casos, o mais racional é refatorar a arquitetura primeiro ou abandonar a técnica até que o código esteja numa condição mais saudável. Não adianta forçar ping pong ping pong num sistema acoplado demais. O ping pong ping pong é útil quando o time já tem disciplina de TDD e trabalha em funções ou módulos com responsabilidade bem definida. Fora disso, ele vira só mais uma cerimônia que consome tempo sem entregar vantagem real. O ideal é usar como prática de treinamento ou em projetos pequenos onde o ciclo completo de teste-implementação cabe em poucos minutos. Para sistemas grandes, existem abordagens mais adequadas que não dependem dessa alternância rígida entre pilotos.
