Técnicas

Não testar x TDD

Olá pessoal, esse post foi sugerido por um amigo meu, Leonardo Cidral, ele indicou esse assunto, e é um tema bem interessante e que está cada vez mais em evidência no desenvolvimentos de softwares, então vamos lá.

Testar aplicações deve ser um item primordial do desenvolvimento de sistemas, faz parte do seu profissionalismo. Você não terá um sistema estável, fácil de modificar, com baixo custo de manutenção se você não realiza testes. Isso mais cedo ou mais tarde, acarretará grandes problemas.

Existem 2 tipos de desenvolvedores  que não realizam testes:

  •  Chuck Norris
  •  Desenvolvedor amador

Você é Chuck Norris? Provavelmente não, então já sabe qual sua classificação.

Desenvolvedor que não testa, é como um cirurgião que não lava as mãos!(Robert C. Martin “Uncle Bob”). 

Mas o que é TDD?

A sigla significa Test Driven Development – Desenvolvimento Dirigido por Testes. È uma técnica que visa escrever os testes antes mesmo de escrever o código fonte! Estranho? No começo pode parecer que sim, mas com o tempo você verá os benefícios que ele trará no seu dia a dia.

Essa prática foi popularizada por Kent Beck na eXtreme Programming (XP), ela parte da ideia que será escrito um código apenas para o teste falho passar. Não haverá linhas de códigos desnecessárias no seu sistema, cada parte do seu código será testada antes de entrar em produção.  

Como funciona?

TDD = Test First Desing (TFD) + Refactoring

A primeira coisa a se fazer é escrever um pequeno teste antes mesmo de o código existir.  O primeiro teste escrito irá falhar, claro, ainda não há código para testar, em seguida você escreve o código e testa novamente, se passar, o próximo passo é a refatoração. A partir daí esse é o ciclo que será seguido. É importante que você avance os testes seguindo os baby steps, ou seja, avance em passos bem curtos, para ter um bom controle do seu código, com o passar do tempo, você começa a adquirir segurança nessa técnica, pode ir um pouco além, mas é sempre prudente e recomendado que não avancemos muito na hora de escrever um teste.

Fluxo TDD

Um desing limpo e agradável.

Imagine a seguinte situação, você vai até a cozinha prepara o alimento, se alimenta e sai, você não lavou a louça. No dia seguinte repete a situação, e no outro também e assim vai fazendo…. Essa rotina de preparar se alimentar e sair, é a mais rápida nesse momento, você consegue ganhar tempo com isso, porém algum tempo depois você terá uma cozinha imunda, você não tem nem coragem de entrar nela, a sua vontade nesse momento seria eliminá-la do resto da sua casa e reconstruir uma nova, nem as baratas conseguem sobreviver mais lá.

Essa analogia, é exatamente o que ocorre com os códigos  criados de qualquer jeito, chega um momento que os programadores têm medo de fazer qualquer alteração, aquele fonte agora tem vida própria, é praticamente um hardware, é impossível alterar ele sem causar outros problemas. Durante  o seu desenvolvimento, as funcionalidades eram adicionadas sem o mínimo de cuidado, não havia refatoração nesse código, não havia o mínimo de boas práticas, havia muito CTRL+C e CTRL+V. Não podemos negar que há também outros fatores que contribuem para isso.

O TDD garante um desing limpo, ágil, produtivo no momento atual e no futuro também. Todo o seu código fonte é escrito na medida em que atende a especificação, nada além disso será necessário, em seguida você executa o teste e se ele passar, pronto, só refatorar . Quem está no comando agora são as especificações de testes que foram criadas, elas são quem guiarão o seu fonte para atingir o resultado.

Quando você usa TDD, seu resultado será um código bem testado, refatorado, limpo, onde  sua manutenção será extremamente rápida e produtiva hoje e no futuro, e não haverá funcionalidades surpresa para o usuário, o código está livre de bugs, o programador tem segurança no seu código, grandes alterações não afetarão o funcionamento do sistema.Precisamos deixar claro que o TDD não é de uso obrigatório, mas testes SÃO OBRIGATÓRIOS

Um ponto que merece ser destacado é que o TDD se utiliza dos testes para dirigir o desenvolvimento, mas o foco real é o design da aplicação, e não os testes, ou seja, no momento que você escreve um teste e o código ainda não existe, então não há testes nesse momento, o que há é uma especificação para atender um determinado requisito, no instante seguinte, você escreve o código, realiza o teste e ele passa, agora você tem um teste nas mãos, mas antes disso aquela especificação não testava nada, apenas especificava algo. 

No exato momento em que escrevo esse post (02:25 da manhã), vejo na tv uma reportagem sobre o sistema da Prodesp que está causando uma enorme dor de cabeça para unidades do DETRAN em São Paulo, o sistema trava, e não mais retorna, alunos são dispensados das aulas, outros aguardam um tempão para tentar fazer suas aulas, os funcionários estão no limite da paciência. A Prodesp se manifestou por telefone, informando que tem conhecimento do problema, e está trabalhando para corrigir. Alegam que o problema tem como causa, o grande número de instrutores que acessam o sistema simultaneamente.

Será que existe algum teste que poderia prever essa situação? Claro que sim! Será que tiveram o cuidado de fazer? Acho que a reportagem já respondeu!

Atenção! TESTES SÃO OBRIGATÓRIOS!

Referências:

 http://www.agiledata.org/essays/tdd.html

http://unplugged.giggio.net/unplugged/post/TDD-nao-existe.aspx

Abraços!

Padrão