Exibir código-fonte para 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.

<pre>http://svn.biserp.com.br:10081/svn/BISTest</pre>

== 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:

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

{{nota|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|Organização das Classes de Teste|Definir como será a organização das classes de teste.

Pensando que as classes de teste devem testar apenas métodos específicos, talvez a organização das classes de teste deva seguir a mesma organização de pacotes da aplicação. E em cada "pacote" pai, criar uma classe de teste que agrupe todos os testes filhos. Facilitando assim a execução de testes específicos ou de testes mais genéricos, até o ponto de ter uma classe na raiz que execute todos os testes da aplicação em sequência (pensando em um teste final de aplicação antes do fechamento de versão).}}


== 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|JUnit|Com o tempo ir documentando os demais casos e funcionalidades do JUnit, como os asserts, MockObjects, etc.}}

= BISDirector =

O BISDirector é um projeto do BIS 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 e a permutação das possibilidades.

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:

{{java|Criando novo BISDirector|<syntaxhighlight lang="java">
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);
    }
  }
  ...
}
</syntaxhighlight>}}


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:

{{java|Descrevendo o objeto para o BISDirector|<syntaxhighlight lang="java">
...
td.addAttribute("name", TDStringAnyChar.getInstance(), 100, null, true, true);
td.addAttribute("cnpj", TDStringCNPJ.getInstance(), 14, 14, false, true);
td.execute();
...
</syntaxhighlight>}}


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.