tdd na prática

muito se fala sobre tdd (test driven development). qualquer um que já tentou fazer na prática sabe que embora a teoria seja simples e baseada nos passos: red, green, refactor (vermelho, verde, refatoração), quando se começa a praticá-lo muitas dúvidas surgem.

por exemplo, a medida que se evoluiu a prática de tdd afirmou-se que o “teste tem que se tornar mais específico para que o código se torne mais genérico.”
muitos vão dizer que não: tdd é fácil e resolve todos os seus problemas. para eles basta seguir os passos acima e tudo se resolve. para mim estes fazem parte do grupo que mencionei aqui. este post é para os que acreditam que dúvidas existem e que cometemos erros quando começamos a fazer tdd.

entre as dúvidas ou erros comuns (e eu os enfrentei :)) estão: como saber até onde ir com os testes unitários, como fazer que os testes sejam específicos a medida que evolui o código para se tornar genérico. como escolher os testes corretos.

o primeiro ponto para ter em mente é que a prática é que aperfeiçoa. então quanto mais praticar, e errar, mais se aprende.

porém, aprender com quem tem mais experiência também ajuda bastante. eu tenho um amigo com bastante experiência em tdd que eu sempre recorro em busca de ajuda. e recentemente um post do “uncle bob” me chamou atenção. ele faz uma transcrição de uma conversa entre dois devs sendo um praticando tdd e o outro ajudando. ele foca principalmente na questão do teste ser específico para que o código se torne genérico. mas dá para tirar lições interessantes sobre diversos aspectos de tdd.

o ponto é: tdd é muito legal, porém não é tão simples como parece fazer corretamente. mas a prática é a melhor maneira de se aperfeiçoar.