Jackson Pires
Se você já tem um pouco de tempo de estrada dentro da área de desenvolvimento e programação, provavelmente já deve ter ouvido falar em TDD, não é mesmo? Mas o que está por trás dessa sigla misteriosa? Bom, é isso que veremos agora!
O que é TDD?
TDD é a sigla para Test-Driven Development, que em bom português quer dizer “Desenvolvimento Guiado a Testes”. A própria tradução já entrega o que está por trás dessa técnica. Em se tratando de “Desenvolvimento Guiado a Testes”, a premissa trazida por esse conceito é que codifiquemos o teste antes mesmo de codificar a aplicação, ou seja, sendo curto e grosso: a aplicação nem existe e já há um teste esperando por ela.
Isso faz sentido?
Isso por vezes pode soar estranho, mas aos poucos você vai percebendo que isso faz total sentido. Explico.
Imagine que você vai ao comércio com a simples “missão” de comprar um novo notebook. Como um bom usuário conhecedor de tecnologia, você já tem em mente as configurações mínimas que deseja. Por exemplo:
“Processador Core i5, 8GB de memória RAM e SSD de 256GB”
Ao entrar na loja, o vendedor te apresenta um computador com processador Core i5, 8GB de memória e HD de 1TB.
Com essa oferta em mente, é fácil perceber que se trata de uma excelente configuração, mas ela não se enquadra em seus requisitos mínimos, visto que você quer um computador que possua SSD ao invés de HD. Sendo assim, você solicita que o vendedor substitua o HD por um SSD de no mínimo 256GB e assim ele o faz. Com essa pequena alteração você terá um computador com os requisitos mínimos que você estabeleceu.
Fazendo uma analogia, nosso requisito de compra (Core i5, 8GB e SSD 256GB) seria nosso teste já estabelecido, visto que esse vai ser nosso parâmetro de comparação com as opções que serão apresentadas. Diante desse contexto, perceba então que é totalmente aceitável que tenhamos um teste mesmo antes de codificar a aplicação.
Voltando ao nosso exemplo, percebemos que na primeira opção mostrada pelo vendedor, os requisitos não foram cumpridos e consequentemente a opção foi rejeitada. A partir disso, você solicitou que o vendedor atualizasse a configuração e ele o fez, dessa forma, tornando a configuração aceitável aos seus requisitos. É exatamente isso que ocorre no processo de TDD!
Red, Green, Refactor!
O processo de TDD tem um conhecido ciclo chamado de RED, GREEN, REFACTOR, que faz alusão a três passos muito comuns. São eles:
1 – RED:
O teste já existe, mas o algoritmo da aplicação ainda não. Então quando rodarmos o teste o mesmo vai falhar (por isso chamamo de RED), pois ainda não existe a aplicação.
2 – GREEN:
Após criarmos o algoritmo da aplicação, rodamos novamente os testes e dessa vez ele deve passar, por isso, GREEN.
3 – REFACTOR:
Esse terceiro passo não é obrigatório, mas, por vezes, podemos melhorar o código nessa etapa. Anteriormente, por exemplo, foi solicitado que o vendedor alterasse o HD pra SSD, ou seja, houve uma mudança. Daí vem o o nome REFACTOR. Esse passo pode ou não voltar a quebrar o teste. Caso sim, o ciclo se inicia novamente.
Enfim, trocando em miúdos, temos: “escreva o teste e ele vai falhar” — RED, “escreva o algoritmo que faz o teste passar” — GREEN, “refatore o código com melhorias e se o teste falhar, volte a refatorar o código” — REFACTOR.
Simples, não?
É claro que isso é só a ponta do iceberg e existem muitos outros conceitos que envolvem o famoso TDD, mas entendendo os 3 passos acima você já estará no caminho certo para o completo entendimento dessa metodologia.
Bom, entendido o principal conceito por trás do que é TDD, preciso também dar a resposta para uma das perguntas que mais me fazem.
“Porque devo testar softwares?”
É claro que a resposta para esse pergunta pode ser bem extensa, mas separei alguns itens que acredito valer comentar:
Garantir a qualidade do software:
Isso mesmo. Quando você testa sua aplicação, inevitavelmente a mesma passará a “ganhar qualidade”, visto que os teses garantirão que seu software esteja funcionando como o esperado.
Segurança e facilidade na manutenção:
Esse é outro aspecto que você ganha quando começa a praticar TDD. Quando você precisar fazer qualquer manutenção em seu software, os testes te garantirão que tudo continuará funcionando e essa certeza é algo impagável quando estamos desenvolvendo. Se você ainda não vê vantagem nisso, espere você começar a trabalhar em aplicações mais robustas…
Melhor design de software:
Essa talvez seja uma das principais vantagens que você percebe logo que começa a praticar o TDD. Bom, pelo menos no meu caso foi assim. Em outras palavras, é incrível como sua forma de pensar muda quando fazemos primeiramente o teste. Nesse aspecto você percebe que de fato o TDD te guia praticamente sugerindo classes e padrões na hora de você implementar a aplicação.
Documentação técnica:
Se tem um aspecto que também gosto bastante é relacionado a documentação técnica que é gerada. Ao começar a escrever os testes você estará fazendo algo que vai ajudar bastante, não só você, mas também qualquer outro desenvolvedor que venha a trabalhar no projeto visto que os próprios testes vão servir de documentação técnica para os desenvolvedores.
Pronto para aprender TDD?
Enfim, acredito que já deu para perceber que vantagens existem aos montes e que o quanto antes você começar a praticar o TDD, melhor será o resultado das suas aplicações. Talvez você esteja se perguntando…
“Como eu posso começar?”
Bom, se você trabalha com Ruby on Rails ou, pelo menos, sabe programar o básico com a linguagem, recomendo o meu curso sobre TDD com Ruby On Rails. Esse curso com certeza vai te ajudar a passar pelo caminho das pedras.
É isso, pessoal! Espero que esse seja seu primeiro passo rumo à prática do desenvolvimento guiado a Testes (TDD). Um super abraço e até a próxima!
