DEV Community

Cover image for As pessoas realmente fazem TDD?
Beatriz Herculano
Beatriz Herculano

Posted on

As pessoas realmente fazem TDD?

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)

Collapse
 
ronalddpinho profile image
Ronaldd Pinho

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 ;)

Collapse
 
ricardocas profile image
Ricardo Costa Alves dos Santos

Obrigado por compartilhar, não conhecia o conceito :)