BISTest - Histórico de revisão

Rodrigogml: /* Funcionamento */

2015-07-03T21:03:33Z

Funcionamento

← Edição anterior		Edição das 21h03min de 3 de julho de 2015
Linha 78:		Linha 78:
	== Funcionamento ==		== 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).		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.		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:		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:

Linha 136:		Linha 138:

	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 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.		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.		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.

Rodrigogml: /* BISTestDirector */

2015-07-03T20:04:15Z

BISTestDirector

← Edição anterior		Edição das 20h04min de 3 de julho de 2015
Linha 57:		Linha 57:
	{{TODO\|JUnit\|Com o tempo ir documentando os demais casos e funcionalidades do JUnit, como os asserts, MockObjects, etc.}}		{{TODO\|JUnit\|Com o tempo ir documentando os demais casos e funcionalidades do JUnit, como os asserts, MockObjects, etc.}}

	= ~~BISTestDirector~~ =		= 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.

	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.		Como o teste só é executado no momento de lançamento de releases, o serviço BISDirector é fornecido em um projeto a parte.
	Testes Realizados
			== Testes Realizados ==
	O BISDirector atualmente executa os seguintes testes para cada um dos atributos individualmente:		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 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 é 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 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 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 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 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 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 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 métodos de Find de objetos cadastrados/atualizados e compara se os objetos são iguais.
	Testa os roteiros personalizados (se inserido algum).		* Testa os roteiros personalizados (se inserido algum).

	Funcionamento		== 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).		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.		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:		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]~~		{{java\|Criando novo BISDirector\|<syntaxhighlight lang="java">
	Criando novo BISDirector:
	public static void testBISDirector() {		public static void testBISDirector() {
	BISDirector<CompanyVO, CompanyMO> td = new BISDirector<CompanyVO, CompanyMO>() {		BISDirector<CompanyVO, CompanyMO> td = new BISDirector<CompanyVO, CompanyMO>() {
Linha 120:		Linha 121:
	...		...
	}		}
			</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:		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]~~		{{java\|Descrevendo o objeto para o BISDirector\|<syntaxhighlight lang="java">
	Descrevendo o objeto para o BISDirector:
	...		...
	td.addAttribute("name", TDStringAnyChar.getInstance(), 100, null, true, true);		td.addAttribute("name", TDStringAnyChar.getInstance(), 100, null, true, true);
Linha 132:		Linha 132:
	td.execute();		td.execute();
	...		...
			</syntaxhighlight>}}


Linha 137:		Linha 138:
	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.		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.		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.~~

Rodrigogml em 19h57min de 3 de julho de 2015

2015-07-03T19:57:47Z

← Edição anterior		Edição das 19h57min de 3 de julho de 2015
Linha 1:		Linha 1:
	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.		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 ==		= Informações Gerais =
	=== Checkout do Projeto ===		== 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.		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.
Linha 8:		Linha 8:
	<pre>http://svn.biserp.com.br:10081/svn/BISTest</pre>		<pre>http://svn.biserp.com.br:10081/svn/BISTest</pre>

	=== Dependências ===		== Dependências ==

	==== Plugins do BIS ====		=== 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.		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 ====		=== 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:		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:
Linha 26:		Linha 26:
	{{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.}}		{{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 ===		== 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.		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.

Rodrigogml: /* JUnit */

2015-07-03T19:56:52Z

JUnit

← Edição anterior		Edição das 19h56min de 3 de julho de 2015
Linha 48:		Linha 48:
	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'''.		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 ==		= JUnit =

	=== Teste Simples ===		== 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.		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.
Linha 56:		Linha 56:

	{{TODO\|JUnit\|Com o tempo ir documentando os demais casos e funcionalidades do JUnit, como os asserts, MockObjects, etc.}}		{{TODO\|JUnit\|Com o tempo ir documentando os demais casos e funcionalidades do JUnit, como os asserts, MockObjects, etc.}}


	= BISTestDirector =		= BISTestDirector =

Rodrigogml: /* JUnit */

2015-07-03T19:56:19Z

JUnit

← Edição anterior		Edição das 19h56min de 3 de julho de 2015
Linha 56:		Linha 56:

	{{TODO\|JUnit\|Com o tempo ir documentando os demais casos e funcionalidades do JUnit, como os asserts, MockObjects, etc.}}		{{TODO\|JUnit\|Com o tempo ir documentando os demais casos e funcionalidades do JUnit, como os asserts, MockObjects, etc.}}


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

Rodrigogml: /* BISTestDirector */

2015-07-03T19:55:33Z

BISTestDirector

← Edição anterior		Edição das 19h55min de 3 de julho de 2015
Linha 35:		Linha 35:

	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.		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.

	~~=== BISTestDirector ===~~

	~~BISTestDirector é uma ferramenta de teste do BIS que permite o teste automatizado dos métodos padrões do CRUD do BIS.~~

	~~{{TODO\|Exemplificar a Ferramenta\|Quando houver tempo reavaliar a ferramenta existente e verificar sua funcionalidade se mante-la explicar seu funcionamento.}}~~

	== Organização das Classes de Teste ==		== Organização das Classes de Teste ==

Rodrigogml: /* Dependências */

2015-05-12T15:56:13Z

Dependências

@@ Linha 9: / Linha 9: @@
 === Dependências ===
 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.
 === Teste Unitário ===

Rodrigogml: Criou página com '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...'

2015-05-12T15:31:03Z

Criou página com '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...'

Página nova

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

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.

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

=== BISTestDirector ===

BISTestDirector é uma ferramenta de teste do BIS que permite o teste automatizado dos métodos padrões do CRUD do BIS.

{{TODO|Exemplificar a Ferramenta|Quando houver tempo reavaliar a ferramenta existente e verificar sua funcionalidade se mante-la explicar seu funcionamento.}}

== 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.}}