Uma técnica ágil pouco usada e proporcionalmente conhecida, o TDD(Test Driven Development) ou Desenvolvimento orientado a testes, pode ser enxergado como um vilão aos olhos de algumas empresas, mas para outras esta técnica veio como um heroi. Descubra lendo esse artigo o porquê dessa guerra de opiniões e também um pouco de sua história.
Irmã da Extreme Programming, o TDD nasceu em 2003 também criada pelo engenheiro de softwares Kent Beck, com alguns conceitos muito semelhantes entre as duas, o Test Driven Development, na língua nativa de seu criador, veio com a finalidade de encorajar o design de código mais simples e inspirar confiança tanto à equipe envolvida no desenvolvimento do software quanto ao cliente pela sua confiabilidade. O ciclo curto de repetição foi o que acabou rotulando esta técnica, primeiramente escrevendo-se um teste unitário automatizado que define uma melhoria ou nova funcionalidade, e posteriormente produzindo o código que irá satisfazer este teste.
Os testes possuem afirmações que podem ser verdadeiras ou falsas, ou seja, o programa irá funcionar ou não segundo as regras definidas por este teste. Se a mesma se confirmar como verdadeira, o programa se dá por completo, ou uma nova etapa pode ser incluída com um novo teste. Mas se falhar, o programa deve ser modificado para que atinja o sucesso esperado para o funcionamento.
Entendido a técnica, deve-se levantar a questão do porquê da desavença de opiniões quanto a utilização do TDD. Algumas empresas não pregam a importância dos testes para seus desenvolvedores, ou até mesmo elas próprias pensam ser uma perca de tempo ficar os escrevendo invés de já “meter a cara no fonte”, ocorrendo então a queda na produtividade por causa da automatização dos testes. Vale apontar também a desaprovação do TDD quando usado por pessoas inexperientes, principalmente em interfaces para usuário ou quando não sabem ao certo o que testar, acabam por escrever testes errados, e ao se deparar com bugs, culpam a técnica de ser falha, quando na verdade não passa de um dos perigos ao se praticar de forma superficial e imatura o Test Driven Development.
Usada de modo correto, certamente os profissionais irão notar a diferença ao dar manutenção a um código, pois esta técnica foca em fazer passar somente determinado teste, não deixando margens para aparecer linhas de códigos inúteis ou métodos muito grandes. Provavelmente haverá alguma resistência quando implementado em sistemas já prontos, isto é normal, pois esta foi feita e fortemente recomendada para utilizar desde o começo do projeto, tentar aplicá-la a um já existente seria desaconselhável, visto que grande parte dos fontes teriam que ser reformulados para atender corretamente a técnica.
Concluíndo, o TDD (Test Driven Development) pode ser facilmente confundido como uma metodologia, mas na verdade é uma técnica de desenvolvimento que auxilia na utilização de metodologias ágeis. É aprovada quando usada seriamente, e entendida como algo que irá auxiliar na simplicidade e confiabilidade dos programas. As diferentes opiniões são frutos dos diferentes modos e pensamentos na hora da utilização desta técnica. Experimente o Test Driven Development e tenha sua própria opinião.
Autor Rodrigo Rossato Danna
Artigo do Seminário de Engenharia de Software 2011-2
Revisão Thiarlei Macedo | Fonte Micreiros.com