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!