Muitos sabem o que é TDD e que ele pode mudar a sua vida, mas muitas pessoas se fazem a pergunta:
Será que as pessoas realmente fazem TDD? Ou é só coisa de artigo?
É bem estranho pensar que seu chefe vai deixar você trabalhar em testes e não em código. Existe a mentalidade que melhorar as coisas para os desenvolvedores não traz valor ao cliente.
Vamos aos básicos primeiro.
TDD, o que é?
TDD é um técnica de programação onde você codifica o teste antes da funcionalidade. Isso envolve que o teste sempre começa falhando, você codifica apenas o necessário para o teste passar (isso de qualquer jeito, não precisa ser da melhor forma), depois refatora o código e o teste tem que funcionar novamente.
Esse comportamento é representado com os estados:
vermelho -> teste falha
verde -> teste passa com o mínimo de código possível
azul -> código é refatorado
verde -> teste passa
Qual o poder mágico que o TDD tem?
TESTES
TDD não é magico. A magia está nos testes!
O TDD te força a fazer testes pro seu código inteiro. Se você modificar seu código sem testes, como você sabe que ainda está tudo bem?
Como você sabe que não quebrou o código que seu colega fez? Quem ja trabalhou com código legado entende muito bem essa dor, essa incerteza de fazer uma modificação e estragar alguma coisa.
Isso é uma ótima vantagem para times com uma pessoa com menos experiencia, onde ela sabe que fez algo de errado por que o teste quebrou, o que deve evitar o código ir pra produção.
Testar manualmente é uma opção, mas vai ocupar cada vez mais tempo. Os testes automatizados são a melhor forma de garantir que você não estragou nada.
Muitas pessoas fazem testes, nem tantas fazem TDD
Muitas pessoas vão falar com seus chefes e lideres de time sobre fazer TDD, isso é muito legal, mas a maior parte das vezes vai ser levado como utopia e não será implementado.
O argumento mais comum é:
TDD é muito custoso, deixa o time mais lento, esse código nem é uma funcionalidade. No final vai ser tempo perdido.
Existem algumas coisas certas nesses argumentos:
- Seu time pode ficar mais lento.
- Esse código não tem contato direto com o cliente.
Mas não é tempo perdido.
É criar uma melhor experiencia de desenvolvimento, trazer mais qualidade para o produto e ajudar os desenvolvedores do time a serem melhores.
Experiência no desenvolvimento traz valor!
Quem nunca pegou um projeto, pra resolver uma coisa bem pequena e simples e demorou o triplo do esperado para concluir a tarefa? Ou então construiu uma funcionalidade e a colocou em produção para perceber que tinha uma regra de negócio errada?
Trabalhar com código é difícil, ainda mais se ele é de outra pessoa e ainda por cima está incompreensível. Se o código estivesse melhor, você ia demorar tanto pra fazer modificações nele?
A sua experiencia no desenvolvimento, como programador, é importante. Sempre pensam que os testes "atrasam" o desenvolvimento, mas nunca olham para quanto um código ruim pode fazer uma tarefa de dois dias demorar um mês.
Com modificações sendo feitas de forma mais rápida, mais valor é entregue em menos tempo!
Qualidade
Garantir a qualidade não é um trabalho exclusivo do QA. A qualidade tem que estar em todos os processos do desenvolvimento, desde a analise da tarefa e suas regras de negócio, o desenvolvimento e o processo de validação do que foi desenvolvido.
Fazer testes unitários automatizados é a ferramenta usada pelos desenvolvedores para garantir a qualidade durante o desenvolvimento, no presente e no futuro.
Esses testes estão na base da pirâmide, sendo eles os menos custosos de executar e criar. Se você está tendo problemas de qualidade dentro do seu time/projeto, TDD é um dos melhores passos a se dar.
Dica bonus
Uma coisa que pode ajudar muito também é uma conversa mais próxima de desenvolvedores e analistas de negocio.
Finalizando aqui
Você vai encontrar dificuldades de implementar o TDD, seja por falta de costume ou por que o time não esta aberto pra isso. Comece aos poucos, tente um pouco de TDD de cada vez, assim você fica mais rápido e vai entender melhor suas vantagens.
Esse é um tema que a leitura não te trará conhecimento suficiente e que a pratica é a parte mais importante.
Top comments (2)
Nossa, muito bom seu artigo. TDD é vida hahaha.
É uma prática tão simples que é difícil de "pegar", eu comparo com hábitos pois é difícil de construir e fazer isso se tornar parte da nossa rotina. Mas assim como padrões de código e de projeto a gente se acostuma a utilizar depois que vê os benefícios.
Uma coisa interessante de destacar também é que existem muitos artigos em engenharia de software voltados pra essa prática, e que confirmam que o uso de TDD melhora a qualidade do produto. Ta aí uma skill que nós Devs deveríamos falar bem mais rsrs. Pra quem caiu aqui e tiver interesse, alguns links:
Helping students appreciate test-driven development (TDD)
About the Return of Investment on Test-Driven Development
Impact of Using Test-Driven Development: A Case Study
Gostei do artigo, Beatriz ;)
Obrigado por compartilhar, não conhecia o conceito :)