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