Páginas

domingo, 23 de setembro de 2012

Testes de Unidade, porque não usamos?


Em 1997 quando Kent Beck apresentou ao mundo a primeira versão do JUnit não imaginava que 15 anos depois muitos programadores Java não sabem como criar um simples teste com o framework dele. O objetivo é procurar trazer ao debate o porquê de nossos desenvolvedores não conhecerem, ou não utilizarem os testes de unidade para garantir a qualidade do nosso código ao invés de repassarem a responsabilidade aos analistas de teste, testando assim a qualidade do código que estamos produzindo.

Os testes de unidade são tão antigos quando a programação orientada a objetos e mesmo assim nos tempos atuais a maioria dos desenvolvedores não utiliza essa poderosa ferramenta que pode nos auxiliar a desenvolver um produto com muito mais qualidade, em praticamente todas as linguagens existem frameworks baseado na plataforma XUnit para testes de unidade, sito os exemplos do JUnit para Java, PHPUnit para o PHP, QUnit para Jquery, NUnit para .Net e etc...
Ao conversar com desenvolvedores escutei diversas explicações ou justificativas da não utilização dos testes de unidade em suas empresas:

  • A falta de cultura para criação de testes;
  • Na graduação aprendemos a testar com Main ao invés de Teste Unitário;
  • Desenvolvedor não testa;
  • Não temos tempo para Testes;


1º A falta de cultura para criação de testes: como assim falta de cultura para criação dos testes. Os testes de unidade tem origem junto com o a orientação a objetos e mesmo assim não temos a “cultura” para criar nossos testes, essa é uma justificativa nos mínimo estranha para se dar pela não criação de testes. Isso é um problema do nosso ego, todo o desenvolvedor acha que não precisa disso, porque ele se garante sozinho, a velha cultura do Super Homem, o de fazer o certo da primeira vez, “vulgo” falta de HUMILDADE.

2º Na graduação aprendemos a testar com Main ao invés de Teste Unitário: no período mais critico, que é a nossa formação invés de testarmos nossos códigos com Testes Unitários testamos com o Main, chegar soar como brincadeira isso, escutei um dia de um professor “Usamos o Main porque é mais didático”. Didático? Isso quer dizer mais fácil para você ensinar. O profissional que esta sendo formado que se vire em aprender sobre Testes de Unidade, não é de responsabilidade sua né meu querido professor. Pois o dia em que começarem a ensinar os alunos a fazer um assertEquals ao invés de um System.out.println() de um “Hello Word”, vai ser o primeiro passo para acabar com a justificativa anterior.

3° Desenvolvedor não testa: pois é, já escutei muito essa justificativa também, qual é a função do desenvolvedor então? Não é entregar um produto com o máximo possível de qualidade (para Kent Beck esse possível esta dividido em dois níveis excelente e o insanamente excelente), e como eu consigo isso sem testar o que estou entregando, eu não tenho a resposta, e você tem?

4° Não temos tempo para Testes: eu li uma metáfora certa vez que é mais ou menos assim, “se você estiver em uma sala de cirurgia e passando muito mal, o médico chega e ira fazer todo aquele ritual de lavagem das mãos, você é o cliente, e mesmo que você solicite que ele não faça aquilo e venha logo lhe atender pois você não esta bem, ele não ira atende-lo(não é o cliente quem manda?), porque a lavagem das mãos é essencial para que o trabalho dele seja bem feito e por isso ele nunca ira atende-lo”. Os Testes de Unidade são essências para a qualidade do nosso trabalho e é nossa função mostrar isso a nossos clientes e gerentes.

Acho que os motivos para não testarmos nosso código são diversos e esta na hora de começarmos a ataca-los pois é inadmissível depois de tanto tempo ai estarmos discutindo um assunto tão antigo como esse, mas como vimos, isso vai precisar do envolvimento de todos nesse trabalho para podermos realizar essa mudança. 

Nenhum comentário:

Postar um comentário