MAVEN - Definir ordem dos testes? tem como?

Assuntos Gerais
#1

Pessoal, estou rodando meus testes unitários com o maven, declarando assim minhas classes de testes no pom.xml:

<testSourceDirectory>src/test/java</testSourceDirectory>

mas lá tenho várias classes, e ele está em ordem alfabética das classes:

A.java
B.java
C.java

eu gostaria alterar a ordem colocando, por exemplo, pra rodar o C.java antes do A.java, preciso pois fiz um esquema onde a classe C.java após rodar deixa os dados do banco num estado perfeito para o A.java rodar, nessa ordem atual dá erro porque ele precisa de dados que ainda não estão disponíveis no banco porque a outra classe que deveria rodar primeiro não rodou.

#2

Opa, temos um problema ai de conceito.

Os testes unitários devem ser isolados, ou seja, não depende da ordem que são executados, pois eles são isolados e não podem depender de nenhum recurso externo (no seu caso o banco de dados).

No seu caso, o ideal é que cada teste tenha um inicio (prepara os dados), meio (faz os testes) e fim (apaga os dados).

#3

Nao sei o maven faz isso, mas o TestNG te possibilita controlar este tipo de dependencia, apesar que, eu acho que os testes unitários, deveriam ser unitários e não dependentes… (mocka teu banco de dados.)

#4

na verdade meus testes unitários eu já fiz, testei cada método da minha classe de negócios e lá sim eu fiz mock do DAO usando o jmock.

Mas agora estou fazendo um teste direto nos DAOs, e vendo se cada método está funcionando perfeito. Tentei utilizar o DBUnit pra isso, mas meus objetos tem uns relacionamentos que não consegui representar no xml do DBUnit. Então estou usando o spring pra IoC, e populando o banco e apagando pra ir testando.

Só que por exemplo, eu testo a entidade Endereco, e depois Funcionário. Porém se testar Funcionário primeiro vai dar erro porque primeiro deveria ter sido testado o Endereco no qual incluiu dados…

Na verdade estou preparando testes, rodando TODOS testes e depois apago os dados, não fiz por cada entidade.

#5

[quote=JavaTux]na verdade meus testes unitários eu já fiz, testei cada método da minha classe de negócios e lá sim eu fiz mock do DAO usando o jmock.

Mas agora estou fazendo um teste direto nos DAOs, e vendo se cada método está funcionando perfeito. Tentei utilizar o DBUnit pra isso, mas meus objetos tem uns relacionamentos que não consegui representar no xml do DBUnit. Então estou usando o spring pra IoC, e populando o banco e apagando pra ir testando.

Só que por exemplo, eu testo a entidade Endereco, e depois Funcionário. Porém se testar Funcionário primeiro vai dar erro porque primeiro deveria ter sido testado o Endereco no qual incluiu dados…

Na verdade estou preparando testes, rodando TODOS testes e depois apago os dados, não fiz por cada entidade.
[/quote]

Você está fazendo um teste de integração. Nesse caso, o correto é mesmo em cada classe de teste preparar,testar e depois excluir os dados. Pode ter certeza que isso vai evitar muitas dores de cabeça no futuro :lol:

#6

[quote=Jair Rillo Junior][quote=JavaTux]na verdade meus testes unitários eu já fiz, testei cada método da minha classe de negócios e lá sim eu fiz mock do DAO usando o jmock.

Mas agora estou fazendo um teste direto nos DAOs, e vendo se cada método está funcionando perfeito. Tentei utilizar o DBUnit pra isso, mas meus objetos tem uns relacionamentos que não consegui representar no xml do DBUnit. Então estou usando o spring pra IoC, e populando o banco e apagando pra ir testando.

Só que por exemplo, eu testo a entidade Endereco, e depois Funcionário. Porém se testar Funcionário primeiro vai dar erro porque primeiro deveria ter sido testado o Endereco no qual incluiu dados…

Na verdade estou preparando testes, rodando TODOS testes e depois apago os dados, não fiz por cada entidade.
[/quote]

Você está fazendo um teste de integração. Nesse caso, o correto é mesmo em cada classe de teste preparar,testar e depois excluir os dados. Pode ter certeza que isso vai evitar muitas dores de cabeça no futuro :lol: [/quote]

Valeu ajuda Jair, vou fazer isso então.

Agora você disse que isso seria teste de integração, e realmente é isso mesmo.
Agora eu li num artigo (estou procurando pra ver se eu ainda tenho o link aqui), dizia que num sistema os testes unitários NUNCA vem antes do teste de integração.

Mas nesse caso nosso trabalho aqui foi dividido, onde alguns estão na parte de negócios onde tem os testes unitários. Outros (meu caso) estão na parte de persistência, e outros na view.

Nesse caso eu já implementei um teste de integração e ainda não houve teste unitário, pois alguns métodos que usarão meu DAO ainda não foram construídos. Já construí algo que será usado daqui a pouco, mas ainda não foi, logo ainda não tem testes unitários… mas já existe o de integração porque eu já fiz…

No caso o artigo citou algo incorreto, ou eu estou confundindo legal?

#7

Na verdade você não precisa fazer TODOS os testes unitários antes de algum teste de integração, porém não faz sentido você fazer primeiro um teste de integração sem fazer o teste unitário.

O que você faz primeiro? Codifica as classes separadamente para depois integrá-las, certo? É nesse ponto que você deve/pode fazer os testes unitários (usando Mock e etc). Quando você já possuí todas as classes da integração (e cada uma com seus respectivos testes unitários) você pode fazer um teste de integração para integrá-las. O detalhe é que você pode fazer o teste de integração na funcionalidade X, antes de fazer o teste unitario na funcionalidade Y.

Eu estou em um projeto similar ao seu, onde tem pessoas responsaveis pela camada VIEW (no caso Portal), pessoas responsáveis pela camada de negócio (no caso EJB) e pessoas responsáveis pelo WebService (JAX-RPC). Quem está trabalhando no negócio por exemplo, faz testes unitários nos serviços (com mock nos DAO) e testes de integração entre Serviço + DAO + Banco. O mesmo ocorre para a camada de view e de WS. Quando tudo está pronto, existe um teste funcional (usando o Selenium) para unir tudo.

Não importa se é teste unitário ou de integração. Cada teste tem que ser independente.

Espero que tenha ficado claro

#8

valeu, esclareu sim minhas dúvidas.

#9