Testes unitários em JME

Testes unitários em JME

Uma das estratégias que empresas utilizam na busca pela garantia e manutenção de um padrão de qualidade em seus produtos é o desenvolvimento de testes.

No mundo do desenvolvimento de software vem ocorrendo um fenômeno parecido. Desde o momento em que as exigências com relação à qualidade e à robustez do software aumentam, torna-se necessária a realização de testes nas aplicações com o objetivo de entregar produtos mais confiáveis. Muitas são as formas de se testar uma aplicação, por exemplo, submeter o trabalho a:

·testes de carga que procuram analisar o comportamento da aplicação no momento em que há um aumento de acessos;

·testes unitários, que têm por foco a análise das unidades que constituem os sistemas.

O foco deste artigo encontra-se nos testes unitários, mais precisamente, na modalidade de testes que podem ser realizados no momento da codificação para dispositivos portáteis. Discutiremos aqui a utilização de dois frameworks, um chamado j2meunit, para a tarefa da realização de testes unitários em aplicações JME. Qualquer semelhança com o famoso framework de testes JUnit não é mera coincidência, afinal ele serviu de inspiração para o j2meunit. Entretanto, como existem limitações na API para dispositivos móveis, fatalmente haverá diferenças no manuseio destes dois frameworks. Ainda assim, aqueles com alguma experiência em JUnit não terão dificuldades em lidar com j2meunit.

O outro framework analisado será o JMUnit, que embora também seja para a aplicação de testes unitários, já não possui tantas semelhanças com o JUnit. Ainda assim é bastante prático, possuindo uma quantidade de opções de utilização um pouco maior, disponibilizando inclusive a possibilidade do uso de métodos de teste parametrizados.

Neste artigo serão exibidos exemplos da utilização dessas duas ferramentas após uma breve explicação de suas funcionalidades.

Metodologia de testes

Antes de entrarmos no foco desse artigo, frameworks de testes para o desenvolvimento de aplicações que rodam em dispositivos móveis, considero bastante interessante fazer um breve comentário a cerca de uma metodologia de implementação de testes no processo de desenvolvimento.

Existem várias formas de se integrar testes a um processo de desenvolvimento. A mais comum e talvez a mais intuitiva delas é a de efetuar os testes após ter sido feito o processo de codificação da unidade. Assim, por exemplo, primeiro fazemos a classe ‘A’ para então aplicarmos testes sobre ela. Entretanto, uma metodologia que vem ganhando espaço é a do desenvolvimento orientado a testes. Adotar esta metodologia, Test Driven Development (TDD), significa trabalhar no desenvolvimento dos testes antes mesmo de trabalhar na codificação das unidades do sistema. Por exemplo, supondo que queiramos fazer a classe Calculadora em que podem ser citados como métodos somar e subtrair, primeiro elaboraríamos o teste para os seus métodos para só então procedermos a construção deles.

À primeira vista, esta abordagem pode parecer um tanto quanto burocrática, afinal porque não começar logo a por a 'mão na massa' e só então passar para os testes. De fato, a aplicação desta metodologia pode, de início, ser um pouco mais lenta que a tradicional, entretanto, a sua adoção possibilita que o desenvolvedor tenha um código menos sujeito a bugs, uma vez que já de início são traçados os padrões de qualidade a que determinada parte do sistema deve obedecer.

Não bastasse isso, essa técnica diminui bastante algo que vou chamar de 'efeito sanfona' no desenvolvimento. Este ocorre quando o programador, ao passo que evolui no seu processo de codificação, precisa ficar voltando ao código gerado anteriormente para corrigir defeitos que acidentalmente tenham passado pelos seus olhos. Além disso, testes, quando bem feitos, servem como documentação de um sistema. Dessa forma, caso ainda seja preciso dar um ou outro passo atrás no processo, uma documentação mais completa é capaz de tornar esse processo menos demorado.

Onde obter os frameworks

Os dois frameworks tratados nesse artigo podem ser encontrados no sourceforge. O j2meunit, através do endereço http://j2meunit.sourceforge.net/, e o JMUnit através do endereço http://sourceforge.net/projects/JMUnit/.  

J2ME Unit

Como será visto na parte prática deste artigo, a maneira como utilizamos o j2meunit é muito parecida com a forma como utilizamos o JUnit. Com isso, as pessoas que já possuem alguma experiência com a utilização do JUnit terão mais facilidade para entender este artigo.

Vamos começar pela principal diferença existente entre esses dois frameworks. O JUnit faz forte uso de reflexão, talvez a chave de sua facilidade, já que para criarmos um método de teste com esse framework precisamos apenas iniciar o nome desse método com o prefixo ‘test’, por exemplo, testSoma(). Entretanto, a API de reflexão não é disponível em JME, logo encontramos uma grande diferença na forma como ambos irão funcionar. Quando trabalhamos com JUnit é fundamental que todos os nossos métodos comecem com ‘test’, com j2meunit não temos essa necessidade, este possui outros meios que tornam possível rodar os seus testes. Entretanto, as boas práticas recomendam a utilização deste padrão também quando se trabalha com dispositivos móveis, uma vez que isso torna o código mais legível. A partir da manutenção desse padrão, será mais fácil para qualquer pessoa identificar dentro de sua classe de testes quais os métodos são realmente de testes e quais são aqueles que existem apenas para auxiliar estes métodos."