BT

Esqueça o seu Debugger, Use o "Saff Squeeze"

por Mike Bria , traduzido por Felipe Rodrigues em 27 Nov 2008 |

Kent Beck, um dos pais do XP, TDD, e do próprio JUnit, conta uma história sobre rastrear defeitos através de uma nova funcionalidade do JUnit, JunitMax, com testes unitários ao invés de um debugger. Ele explica um método apresentado a ele pelo atual líder do desenvolvimento do JUnit, David Saff, onde um teste unitário de alto nível é recursivamente embutido até que um teste extremamente conciso passa a existir na raiz do defeito.

Beck apresenta o método que ele apelidou de "Saff Squeeze" (Apertão do Saff), desenhando uma metáfora para um fato do Futebol Americano conhecido como "The Sandwich", onde o jogador que está com a bola é atingido simultaneamente por dois advesários, um atingindo-o "alto" (perto dos ombros) e outro atingindo-o "baixo" (em sua cintura ou pernas). Ele explica que o "Saff Squeeze" é similar a isso em relação ao fato de que um aborda a situação através de um teste unitário de alto nível (o "alto") por recursivamente substituir-lo com mais e mais testes específicos ("baixos") até que um teste que identifica diretamente o problema no código, passe a existir (ex.: até que o defeito possa ser rastreado).

A descrição resumida de Beck sobre o método:

O Saff Squeeze, como eu o chamo, funciona pegando-se um teste que esteja falhando e progressivamente acrescentando partes mais específicas nele, até que você não consiga mais acrescentar nada sem sair do foco do problema. Aqui está o ciclo:
  1. Adicione um método ao teste.
  2. Coloque uma assertion que falhe antes das assertions que já existem.
  3. Retire as partes do teste que não se tornaram irrelevantes durante o processo.
  4. Repita este processo.

No artigo Beck conduz você pelo processo mostrandoo código de teste nos diferentes passos, finalmente mostrando um teste completo que aponta o defeito atual.

Ele compara sua abordagem à abordagem mais tradicional de passar pelo código com um debugger, concluindo o segunte:

Uma das principais diferenças entre os dois processos é que após o debugg eu sabia onde o defeito estava, mas após o processo de squeeze (apertar) eu tenho um teste unitário mínimo para o defeito. Esse teste conciso é um subproduto muito útil do processo.

Beck esclarece que ele não vê isso como uma adição ou mudança no ciclo de desenvolvimento do TDD para código novos, mas sim como uma ferramenta a ser utilizada na resolução de defeitos:

Isso funcionaria como uma abordagem para identificar e corrigir defeitos:
  1. Reproduzir o defeito com um teste de sistema.
  2. Apertar.
  3. Fazer com que os testes passem.
  4. Analisar e eliminar a causa raiz do defeito.

Leia o artigo para ver como isso funciona com um exemplo real, mais sobre a opinião de Beck em relação a aplicabilidade desta técnica e dar uma olhada nas capacidades de inline do eclipse.

Como você vê esta técnica o ajudando a se livrar do debugger? Você acha que há riscos nessa abordagem? Você tem alguma história sobre como você tem feito algo similar, ou utilizado uma abordagem diferente? Participe da discussão aqui.

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão
Comentários da comunidade

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

Dê sua opinião

Conteúdo educacional

Feedback geral
Bugs
Publicidade
Editorial
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2013 C4Media Inc.
Política de privacidade
BT