Para se ter uma idéia rápida de como é TDD na prática, criarei um joguinho bem simples, e de conhecimento geral, que deve servir como exemplo: o Jogo da Velha. (Se você não teve infância ou sofre de perda grave de memória, consulte as regras aqui. :)
Para verificar se a implementação do jogo estará correta, escreverei código que a teste. Mas daí vem algumas questões:
- Como terei certeza de que o código que escreverei poderá ser testado de forma adequada ?
- Como saber que não vou ter que modificar meu código depois só pra torná-lo "testável" ?
- O design do código será apropriado o suficiente para me dar toda a informação que precisarei verificar ?
Se escrevo código que implementa uma funcionalidade antes de escrever código que a testa, corro o risco de que seu design não seja adequado para que seja testado. Portanto, a melhor maneira de escrever código "testável" é definindo seu teste primeiro. Assim você garante que a implentação deve seguir o design que você propôs.
"Hum... então TDD é mais do que escrever testes primeiro, tem a ver sobre design também...", você pode estar pensando. Sim, com certeza; TDD é mais sobre design do que propriamente a ordem em que os testes são feitos.
Em geral, você guia o design pelos testes. Essa abordagem, ligada a noções de conceitos como acoplamento e coesão, levam a um código altamente flexível e testável. Normalmente, o que queremos quando desenvolvemos software de qualidade.
Nenhum comentário:
Postar um comentário