BISTest

O BISTest utiliza como base o JUnit para escrita dos casos de testes e validação dos plugins, módulos e demais teste unitários.

Informações Gerais

Checkout do Projeto

O repositório do projeto está localizada no endereço abaixo. Não se esqueça ao fazer checkout de escolher a pasta "trunk" caso deseje trabalhar no código de teste atual.

http://svn.biserp.com.br:10081/svn/BISTest

Dependências

Plugins do BIS

O projeto tem apenas dependências com os pacotes "client" dos plugins. Pois é onde devem estar as classes utilitárias (para realização dos testes unitários) e as interfaces das fachadas dos plugins.

Bibliotecas do Glassfish

Para fazer o lookup como aplicação stand-alone o BISTest precisa ter as bibliotecas J2EE no projeto. O projeto já tem dependência com uma bilbioteca de ambiente chamada Glassfish Module. Para configura-la proceda de acordo com os passos abaixo:

1. Vá no menu Window -> Preferences e abra a aba de configurações em Java -> Build Path -> User Libraries.
2. Clique em New, na popup que abrir digite exatamente Glassfish Module e confirme.
3. Uma vez que a biblioteca foi criada, clique nela para deixa-la selecionada e vá em Add External JARs...
4. Procure o diretório modules dentro da instalação do Glassfish. Ex: C:\glassfish4\glassfish\modules
5. Selecione todos os arquivos .jar dentro da pasta e clique em abrir.

Projeto com Falha Após os passos acima você deve ter criado com sucesso a biblioteca de ambiente necessária para o BISTest funcionar corretamente. Caso o projeto continue apresentando erros de compilação, verifique se os projetos Client dos plugins estão no ambiente e se estão abertos.

Teste Unitário

Para testar métodos utilitários basta criar a classe de teste com os métodos a serem chamados, passar os atributos para os métodos e avaliar o resultado obtido. Basta seguir o padrão do próprio JUnit. Veja exemplos mais abaixo.

Teste dos Métodos de Fachada

Uma vez que os plugins do BIS dependem do servidor de aplicação J2EE (Glassfish) para gerenciar transações e conexões no banco, os testes de métodos do CRUD precisam que a aplicação (pelo menos os EJBs) estejam deployed no servidor antes de iniciar a execução dos testes.

Uma vez que o servidor for levantado e a aplicação deployed o BISTest oferece os métodos para fazer o lookup das fachadas dos plugins na classe ContextLookup de forma centralizada. Para testar uma chamada fachada basta obter a interface da fachada correspondente e executar o teste.

Organização das Classes de Teste

TODO Task Organização das Classes de Teste

Executando os Testes Integrado no Eclipse

Como os testes do projeto são baseados no JUnit, o eclipse já vem com a integração instalada por padrão. Para executar uma classe de teste rapidamente basta estar com ela aberta no editor e usar a tecla de atalho para executar: ALT + X, T ou para debugar: ALT + D, T.

JUnit

Teste Simples

No JUnit uma classe de teste é uma classe java padrão, com um ou mais métodos que não recebam parâmetros e que tenham a anotação @Teste (org.junit.Test) em cima do método. Ao executar uma classe de testes pelo JUnit ele procurará todos os métodos com essa annotation e os executará. A maneira mais simples de garantir que um método de testes falhou é termina-lo lançando uma exceção qualquer. Um método que termina sem exceção é considerado um caso de teste bem sucedido.

TODO Task JUnit

BISTestDirector

O BISDirector é um serviço que o BIS disponibiliza para facilitar a criação do roteiro de teste dos módulos. Como muitos testes de fachada a serem realizados são muito semelhantes e cansativos de serem escritos, o BISDirector foi concebido para realizar esses testes de funcionamento a partir da descrição do objeto. Como o teste só é executado no momento de lançamento de releases, o serviço BISDirector é fornecido em um projeto a parte. Testes Realizados O BISDirector atualmente executa os seguintes testes para cada um dos atributos individualmente: Testa se o objeto pode ser inserido/alterado apenas com os atributos obrigatórios; Testa se a fachada lança BISValidationException quando tentamos inserir/atualizar e o objeto é passado faltando qualquer um dos atributos definidos como obrigatórios; Testa se a fachada lança BISValidationException quando tentamos inserir/atualizar e o objeto contém atributos definidos como únicos igual a outros objetos já cadastrados no banco; Testa se a fachada lança BISValidationException quando tentamos inserir/atualizar e o objeto contém o atributo com um tamanho definido 1 caracter maior do que sua definição. Testa se a fachada lança BISValidationException quando tentamos inserir/atualizar e o objeto contém o atributo com um tamanho definido 1 caracter menor do que sua definição. Testa se a fachada aceita inserir/atualizar o objeto com o atributo contendo o tamanho máximo exato, assim como o tamanho mínimo. Testa se a fachada aceita inserir/atualizar objetos com os dados válidos adicionais fornecidos pelo Gerador de Dados; Testa se a fachada lança BISValidationException se tentamos inserir/atualizar objetos com os dados inválidos fornecidos pelo Gerador de Dados; Testa os métodos de Find de objetos cadastrados/atualizados e compara se os objetos são iguais. Testa os roteiros personalizados (se inserido algum).

Funcionamento Para criar um novo roteiro de teste, o primeiro passo é criar uma nova instância do BISDirector. O BISDirector aceita dois parâmetros como do tipo generics, primeiro o VO (que deve ser o objeto a ser testado), e o segundo o MO (relacionado ao VO que estamos testando). Por se tratar de uma classe "abstract", será necessário implementar alguns métodos. Esses métodos tem a finalidade apenas de abstrair o acesso a fachada. Desta forma qualquer teste que queira usar o BISDirector deverá acessar a fachada do seu módulo e passar os objetos gerados. Para realizar os testes do objeto de empresas, o CompanyVO, o código para criação do BISDirector ficará como o código a seguir:

[PICTURE Java.png] Criando novo BISDirector: public static void testBISDirector() {

 BISDirector<CompanyVO, CompanyMO> td = new BISDirector<CompanyVO, CompanyMO>() {
   @Override
    public void deleteVO(Long id) throws BISException {
     facade.deleteCompany(id);
   }

   @Override
   public CompanyVO insertVO(CompanyVO vo) throws BISException {
     return facade.insertCompany(vo);
   }

   @Override
   public void updateVO(CompanyVO vo) throws BISException {
     facade.updateCompany(vo);
   }

   @Override
   public Long count(CompanyVO mo) throws BISException {
     return facade.countCompany(null);
   }

   @Override
   public CompanyVO findVO(Long id, String[] attributes) throws BISException {
     return facade.findCompany(id, attributes);
   }

   @Override
   public List<Long> findIDs(CompanyMO mo) throws BISException {
     return facade.findCompanyIDs(mo, null);
   }

   @Override
   public List<CompanyVO> findList(CompanyMO mo, String[] attributes) throws BISException {
     return facade.findCompanyList(mo, null, attributes);
   }
 }
 ...

}

Tendo em mãos o BISDirector, devemos descrever o objeto para que ele gere os testes a serem executados. Continuando nosso exemplo para o CompanyVO, o descritivo deste objeto ficará assim:

[PICTURE Java.png] Descrevendo o objeto para o BISDirector: ... td.addAttribute("name", TDStringAnyChar.getInstance(), 100, null, true, true); td.addAttribute("cnpj", TDStringCNPJ.getInstance(), 14, 14, false, true); td.execute(); ...

A primeira linha descreve o atributo "name" do CompanyVO. Este atributo receberá dados gerados pelo TDStringAnyChar, que gera Strings com qualquer tipo de caracter. Define que seu tamanho máximo é de 100 caracteres, tamanho mínimo é indiferente. E por fim, indica que é obrigatório e que é de valor único. A segunda linha descreve o atributo "cnpj". O atributo CNPJ usa o gerador de dados de CNPJ, um gerador específico para o teste de CNPJs. Como CNPJ tem sempre 14 dígitos, foi definido que tanto seu tamanho máximo como mínimo é 14. Este campo não é obrigatório, pois podemos cadastrar uma empresa sem CNPJ, mas o CNPJ deve ser único quando informado. Por fim, chamamos o método "execute()", os testes serão iniciados e o tempo dependerá da complexidade do objeto e da quantidade de testes gerados. Caso todos os testes passem, o método simplesmente é executado, caso algum erro aconteça ou teste falhe, o método lançará as exceções ocorridas. Casos Especiais A medida que vamos escrevendo os casos de testes, vamos descobrindo novas situações em que os testes ou o BISDirector precisam se adaptar.

@ToDo Terminar de Escrever os casos especiais, como Skip de Testes, Criação de Roteiros adicionais, etc.