Este post é uma tradução de um post que li no blog do UncleBob.
Como eu já disse antes, não há nada particularmente errado com a atual mania por certificação. Se você quer ser certificado pelo custo de um curso de 2 dias, dê tudo para se certificar. Se você quer certificar pessoas por assistirem seu curso de 2 dias, dê tudo para dar o curso e entregar os certificados. É tudo muito bom. Faça dinheiro. Seja frutífero e faça multiplicar.
No último post eu dei uma breve introdução ao TDD. Muito breve, por sinal. Que só serviu mesmo para entendermos que é, acima de tudo, uma prática de design. Além de dar uma breve olhada em como fazer um teste.
Neste post, minha intenção é dar um pouco mais de sentido à prática do TDD fazendo alguns testes em cima de uma cesta de compras. Com isto, pretendo deixar um pouco mais claro a idéia de “Especificação Executável”.
TDD já não é exatamente uma modinha faz um bom tempo. Não se trata mais de 3 letrinhas pra colocar na sopa do currículo. Se trata de uma prática aprovada pela comunidade e seu uso já é bastante expressivo no mercado. De fato, o TDD já não precisa mais convencer quase ninguém a respeito da sua eficiência quando bem utilizado, e o problema está somente aí: fazer bom uso dele.
E para saber fazer bom uso dele é necessário entendermos uma coisa simples: TDD é de Test-Driven Design. Mas o que muita gente faz é focar no T de Test e esquecer do D de Design. Não se iludam: o T é o aspecto menos importante da sigla. O que realmente importa para nós aqui é o segundo D do TDD.
