Assim como acontece quando aprendemos orientação a objetos, metodologias ágeis e até mesmo tecnologias bem específicas, precisamos antes de tudo conhecermos alguns princípios. E em TDD isso não deveria ser diferente. Acredito, e muito no aprender fazendo, desde que neste contexto esteja incluído um estudo conceitual do caso.

A resistência para colocar em prática TDD em equipes que não estão hábeis com essa prática não é pequena. Mesmo todos reconhecendo o valor e o retorno obtido pela sua prática, o pontapé inicial pode se tornar complicado. É onde ocorre o maior número de desistência no uso da prática.

Para nos auxiliar no desenvolvimento dirigido por testes, devemos obedecer as suas três leis:

• Primeira lei: você não deve escrever qualquer implementação antes que você tenha escrito um teste que falhe;


• Segunda lei: você não deve escrever mais que um teste unitário para demonstrar uma falha;


• Terceira lei: você não deve escrever mais do que o necessário para passar por um teste que está falhando;

Seguindo essas premissas básicas, descritas originalmente pelo famoso Tio Bob, e realmente tratá-las como leis dentro da equipe, teremos então código testável e os benefícios de TDD serão facilmente visualizados pela equipe. E a motivação para trazer essa prática para o processo de desenvolvimento interno é conseqüência.