Teste Driven Development ou TDD, o que é?

Hoje esbarrei com essa sigla, TDD, e eu não fazia a menor ideia do que significava. Então, como um excelente curioso que sou, decidi dedicar um tempo procurando na internet e realizando uma prova-conceito na minha máquina. Não entrarei em código nesse texto, afinal de contas, eu ainda preciso entender melhor como o TDD funciona, suas aplicações, vantagens e usabilidade, ficaremos apenas no conceito, de forma simples e direta.

TDD é o Desenvolvimento Orientado por Testes, ou seja, iremos criar os testes antes mesmo de começar a desenvolver a aplicação propriamente dita. Eu achei estranho, mas fui lendo e começou a fazer sentido, você verá.

A ideia é se basear em pequenos ciclos de repetições, onde para cada funcionalidade a ser desenvolvida, primeiramente se desenvolve um teste para testar a funcionalidade que ainda não foi desenvolvida. Doideira, né? Eu também achei. Mas continuei a ler e, ou eu fui ficando mais maluco do que já sou, ou realmente a ideia de você desenvolver uma funcionalidade para passar no teste, e não um teste para “passar na funcionalidade” começou a fazer muito sentido para mim.

O ciclo é o seguinte: Desenvolve um novo teste > desenvolve a funcionalidade para passar nesse teste > testa e valida que a funcionalidade passou pelo teste > refatoramos o código da nova funcionalidade > escrevemos o próximo teste.

 

O mantra desse rolê é “vermelho, verde, refatora”, em tradução livre.

É dito que, seguindo esses passos, é possível ter alguns ganhos com essa estratégia, como por exemplo:

• Feedback rápido sobre a nova funcionalidade e sobre as outras funcionalidades existentes.
• Código mais limpo, já que escrevemos códigos simples para o teste passar.
• Segurança no Refactoring, pois podemos ver o que estamos ou não afetando.
• Segurança na correção de bugs.
• Maior produtividade, já que o desenvolvedor encontra menos bugs e não desperdiça tempo com depuradores. (Ressalva: Eu não acho que o debug seja desperdício de tempo)
• Código da aplicação mais flexível, já que para escrever testes temos que separar em pequenos “pedaços” o nosso código, para que sejam testáveis, ou seja, nosso código estará menos acoplado.

Como eu disse, à medida que fui lendo, essa metodologia começou a me ganhar. Numa próxima, pretendo trazer exemplos práticos para ficar bem mais claro o funcionamento.

Caso você tenha ficado interessado e queira saber mais, recomendo a leitura desse artigo aqui.

Um abraço, até a próxima!