• Ramon Ferreira Silva

Como seguir as Três Leis TDD

Atualizado: 23 de Ago de 2019




O que é TDD


Desenvolvimento Guia por Testes ( do inglês Test Driven Development), ou apenas TDD, é uma prática bem difundida no mercado, mas que poucos desenvolvedores ainda seguem. Essa metodologia foi originalmente criada por Kent Beck, mas rapidamente outros profissionais da área abraçaram a causa e viraram evangelizadores.

Em seu livro o Codificador Limpo, Robert C. Martin, descreve as três leis do desenvolvimento guiado por testes. As leis são simples, porém nós desenvolvedores temos uma certa resistência a fazê-lo.


As Três Leis do TDD


Primeira Lei do TDD


Você não pode escrever nenhum código até ter escrito um teste que detecte uma possível falha.

Quando começamos a escrever um novo software somos tomados por uma excitação e queremos logo, sair escrevendo o que vêm a cabeça. Mas antes, devemos parar um pouco e pensar no que realmente devemos escrever. Nesse ponto os testes nos ajudam, pois fica claro que devemos escrever algo que passe nos testes. Por isso os testes vêm primeiro.


Segunda Lei do TDD


Você não pode escrever mais testes de unidade do que o suficiente para detectar a falha – não compilar é não ter efeito.

Mais uma vez, somos levados por um sentimento de escrever tudo que vêm a cabeça, mas mais uma vez devemos pensar com clareza sobre o que deve ser escrito, testes também são código. Se escrevermos testes errados, faremos códigos errados, se escrevermos testes demais, acabaremos escrevendo código demais.


Terceira Lei do TDD


Você não pode escrever mais código do que o suficiente para passar nos testes.

Os testes devem vir sempre antes do código, quando escrevemos mais código do que o necessário, acabamos por escrever códigos que não será testados ou pior, escreveremos testes para passar no nosso código. Pense nisso.


Conclusão


Testes de software é mandatório, se você se considera um bom profissional então deve fazê-lo. Muitas vezes somos compelidos a pular esta etapa por causa de prazos apertado, ou mesmo por que achamos que o escopo é pequeno demais.

Coisas pequenas crescem. Prazos não adiantam se o que você entregar não estiver correto.


Não fazer testes não o torna mais rápido, entregar o que é preciso sem falhas, o torna mais rápido. Os testes ajudarão nessa hora. Além do mais, após a entrega, possivelmente você terá que dar manutenção nesse código, e novos prazos para novas funcionalidade surgirão. Você vai agradecer a si mesmo por ter escrito testes adequados.


As vezes temos a postura de que as falhas devem ser encontradas pelos analistas de testes, isso é anti-profissional, e você deve ter esta postura, nunca. Você tem a obrigação de entregar o seu código sem falhas para o analista de testes. Eles estão na equipe para garantir que nada foi esquecido ou passou despercebido.


#Refatoração #java #TDD #BoasPráticas #PHP #net #rails #grails #Qualidade #Testes

87 visualizações