TDD para newbies: O que é e como tirar proveito!

Se você é novo na área de programação provavelmente já deve ter ouvido falar em TDD, não é mesmo? Mas o que está por trás dessa sigla misteriosa? É isso que veremos agora! 😉

TDD é a sigla de Test-Driven Development, que em bom português quer dizer “Desenvolvimento Guiado a Testes”. Provavelmente a própria tradução te faz ter uma ideia do 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á teremos um teste esperando por ela!

Isso por vezes pode soar estranho mas aos poucos você vai percebendo que isso faz muito 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.

É fácil perceber que apesar de ser uma ótima máquina, 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.

Veja então que é totalmente plausível que tenhamos um teste mesmo antes de codificar a aplicação.

Voltando ao nosso exemplo, percebemos que na primeira opção mostrada na loja o requisitos não foram cumpridos e consequentemente a opção foi rejeitada, mas você solicitou que o vendedor atualizasse a configuração e ele o fez, tornando a configuração aceitável aos seus requisitos.

É exatamente isso que ocorre. 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 chamamos de GREEN.
  3. REFACTOR: Esse terceiro passo não é obrigatório, mas, por vezes, podemos melhorar o código (no nosso exemplo solicitamos que o vendedor alterasse o HD pra SSD), daí vem o o nome REFACTOR. Esse passo pode ou não voltar a quebrar o teste, daí 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.

Seguindo adiante, uma outra pegunta que podemos que sempre me fazem é…

Porque eu devo testar software?

É 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 está funcionando como o esperado.
  • Segurança e facilidade na manutenção: Esse é outro aspecto que você ganha quando começa a praticar o TDD. Quando você precisar fazer qualquer manutenção em seu software, os testes te garantirão que tudo continua funcionando e essa certeza é algo impagável quando estamos desenvolvendo.
  • Melhor design de software: Essa talvez seja uma das vantagens que você percebe logo que começa a praticar o TDD pois lembro-me que isso foi uma das primeiras coisas que percebi. É 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 é esse pois 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.

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… Mas como eu posso começar? Bom, se você trabalha com Ruby on Rails, você está com sorte pois temos um curso específico de TDD com Ruby on Rails que vai te ajudar a passar pelo caminho das pedras. 😉

É isso, pessoal! Espero que esse seja seu primeiro passo rumo à prática TDD.

Um super abraço e até a próxima!