Testes de componentes do Jmine

Como testar componentes e padrões comuns em aplicações JMine

Mapeamento de Business Objects

O objetivo deste teste é garantir que o CRUD do BO (Business Object) funciona de forma correta, ou seja, se ele consegue criar, ler, atualizar e deletar o BO. O Jmine possui uma classe base que pode ser utilizada para a criação destes testes: jmine.tec.persist.test.junit4.BOBaseTestCase. Estendendo esta classe, é possível criar testes para os BOs de forma simples. Os testes de BO também podem ser utilizados nos testes de DAO e outros testes que necessitem de uma base de dados inicial.

Persister Listeners

O teste de um Persister Listener consiste em verificar que as ações esperadas foram executadas quando o evento de persist acontecer. Exemplo: ao remover a entidade X, todas as entidades Y também devem ser removidas.

Basicamente, existem duas formas de testar esse Persister Listener: a primeira forma é utilizar os testes de BO para remover uma entidade X e verificar que as entidades Y relacionadas também foram removidas através de buscas ao banco. A segunda forma é mockando o comportamento esperado, por exemplo, ao remover a entidade X, espera-se que o método de remoção da entidade Y seja invocado.

Validators

Deve ser garantido que o funcionamento do validator será como o desejado. Para testar, basicamente devemos criar uma entidade a qual pertence o validator, e salvá-la com as informações a serem validadas. Por exemplo: Imagine que se queira validar que um CPF de um agente tenha sempre 11 digitos. Para isso, poderia ser criado um teste que contenha contenha um agente com 10, outro com 11 e outro com 12 caracteres.

Serviços

Uma das formas de testar serviços é utilizando a classe jmine.tec.services.impl.runner.ServiceRunner do Jmine, responsável por executar uma pequena lista de serviços. O teste consiste em executar um serviço e verificar se o serviço executou a ação esperada. Exemplo: em um serviço de incluir uma entidade, deve-se verificar que, após a execução do serviço, a entidade foi persistida.

Actors

O funcionamento básico dos actors deve ser testado de forma unitária, se necessário utilizando mocks. A corretude do negócio implementado pelo actor deve ser feita através de cenários de negócio, em geral descritos em planilhas por especialistas no negócio.

REST

Existem duas funcionalidades que devem ser testadas em um REST: a implementação da funcionalidade e se o REST em si está funcionando. O primeiro teste deve simular um JSON recebido e verificar se a implementação consegue criar o objeto RS (Representation State) e fazer o que ele o que ele deveria fazer. O segundo teste deve validar que o REST consegue receber requisições e informar o status correto (200, 404, 500, etc). Este teste pode ser feito com ajuda dos Materializers.

Componentes Wicket

O teste garante o funcionamento e comportamento do componente. Para auxiliar os testes de componente, a classe de teste pode herdar de AbstractComponentTest, a qual simula a subida de uma página.

Páginas Wicket

O objetivo do teste é garantir a funcionalidade dos componentes Wicket encadeados numa página. Serve principalmente para cravar o comportamento da página como um todo e não para testar o Business. Atualmente os testes de página herdam de JmineWicketTestCase, usando como classe auxiliar de teste classes herdeiras de PageTester. Este último contém a um conjunto de métodos que permitem testes específicos referente aos diferentes tipos de modelos de página (CrudModelPage, ReportPage, FormPage, etc). Por exemplo: Imagine que existam dois componentes numa página. Ao retirar o foco do primeiro componente o segundo é preenchido com dados do primeiro componente. No teste além dos testes de renderização, deve ser garantido que os dados disparados do primeiro componente devem estar contidos no segundo componente.

Helpers

Como helpers são classe utilitárias e não fazem parte do escopo de negócio, seus testes podem ser testes unitários que testam somente o que cada método deveria fazer. Basicamente, deve-se prover alguns dados fictícios para o teste e utilizando o helper, verificar que o resultado encontrado com a execução do helper é o esperado. Para os dados fictícios, se necessário, pode-ser mockar classes, já que o importante é testar o helper e não o negócio tratado pelas classes de negócio.