Refatoração e TDD (Feitos um para o outro)

Refatoração e TDD (Feitos um para o outro)

Algumas pessoas contestam que a fortíssima dependência da refatoração em relação aos testes não existe, dizendo que esta foi formalmente definida antes que o conceito de TDD fosse formalizado.

Realmente, a refatoração é mais antiga que a TDD. O primeiro trabalho detalhado e formal sobre refatoração, foi a tese de doutorado de William Opdyke, publicada em 1993. Já a TDD só alcança um patamar mais formal em meados de 2000, o que torna a refatoração formal e correta antes mesmo da TDD existir.

A grande falha no argumento acima é que TDD é uma forma disciplina de desenvolver software claro que funciona, baseada fundamentalmente em testes automatizados. Porém os testes sempre existiram, não surgiram com a computação e muito menos com a TDD.

Aplicar refatoração de forma disciplinada, em pequenos passos, seguindo corretamente os bons catálogos, garante altos ganhos e ínfimas possibilidades de erros.

Porém essas ínfimas possibilidades de erros, que são menores que as do desenvolvimento / manuteção sem refatoração, existem e não devem ser ignoradas. Por isso a dependência em relação aos testes automatizados e conseqüentemente, caso deseje-se algo mais robusto, em relação a TDD.

A conclusão é que, do ponto da aplicação da refatoração, um projeto que usa TDD é lindo, uma verdadeira maravilha. E o melhor é que a recíproca também é verdadeira. Parece que foram feitos um para o outro, pois formam um casal praticamente perfeito. Tanto refatoração quanto a TDD gostam de código claro(limpo, fácil de entender, manter) e que funciona. TDD luta de todas a formas pra garantir que o código funcionará sempre e a refatoração usa todas as suas forças por um código cada vez mais claro, limpo, bonito. E todos ficam felizes para sempre. 🙂

=========

O processo de Refatoração depende substancialmente da existência de testes de unidade e aceitação. Sem estes testes, fica muito difícil ter a segurança de que a refatoração foi feita corretamente, ou seja, não modificou o comportamento (funcionalidade) do código, nem inseriu qualquer tipo de erro num código que anteriormente estava funcionalmente correto.

A Refatoração e a TDD são conceitos intimamente relacionados, ou seja, são dependentes e não funcionam corretamente um sem o outro.

TDD pode ser utilizado sem refatoração, mas neste caso torna-se muito difícil fazer algo de qualidade(correto). Isto acontece porque com TDD codifica-se primeiro algo muito simples, só para passar nos testes que já foram escritos. Depois disso melhora-se o código até que este fique com a qualidade mínima desejada, e a melhor maneira de melhorar algo que está funcionando é via refatoração.

Refatoração pode ser utilizado sem TDD, mas neste caso há uma grande possibilidade de ocorrerem problemas, principalmente se deixarmos para escrever os testes depois. Pois é muito comum esquecermos de escrever algum dos testes ou escrevermos testes desnecessários. Ou seja, refatorar sem testes que monitoram as modificações, alertando quando e onde, caso sejam inseridos problemas no código que já estava funcionando, é no mínimo arriscado.

\o ‘s,
ViniciusAC.

Anúncios

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s