Estou fazendo um estudo sobre a conversão do Junit3 para o Juni 4, aqui utilizamos Excel para armazenar os testes pois facilita a entrada de formulas matemáticas e acaba sendo utilizado como documentação.
Tem varias planilhas que possuem mais de uma aba para testes, por exemplo:
Para testar uma tela temos uma aba com os testes de Inclusão outra para Alteração e assim por diante, e somente uma classe de teste, utilizamos o ddsteps para fazer a ligação entre as abas dos teste com os metodos que serão testados.
Mas uma pessoa da equipe levantou um problema o ddsteps esta parado no tempo, quando pensavamos como nos livrar do ddsteps surgiu outra questão, motivo do post.
Será que não estamos escrevendo testes de forma errada?
O correto seria ter uma classe para testar a inclusão outra para a lteração?
Se paramos para pensar como foi feito o Junit e o Tng, parece que foi criado com este objetivo pois não tem nada para facilitar o processo que utilizamos hoje.
Se puderem me ajudar a responder esta questão agradeceria…
Nunca vi essa abordagem, achei até interessante, mas não saberia dizer se está certa ou errada.
Eu normalmente crio uma classe para testar varios dados de um mesmo objeto e faço a separação das classes de testes conforme a pertinencia destes.
Por exemplo os testes de persistência de um objeto são separados de outros destes (quando não é necessário uma vinculação) assim consigo testar cálculos e outras regras de um objeto sem necessidade de conexão com um banco de dados!
Tb nunca vi esta abordagem, eu utilizo JUnit a um tempão, bom eu utilizo da seguinte forma:
Cada classe do sistema possui uma classe respectiva de Teste, e dentro da classe de teste existem varios, muito mesmo, métodos que testam cada regra que eu quero que meu sistema faça…
Exemplo: Quero testar uma classe chamada PessoaBO… ficaria assim:
public class PessoaBO{ //(Esta classe tem a funcção de gravar um objeto pessoa no banco de dados)
public Pessoa salva(Pessoa p){
//codigo
}
}
public class PessoaBOTest{ // (Esta classe é os testes de unidade para a classe PessoaBO).
@Test
public void deveCadastrarUmaPessoaApenasSeAIdadeForMaiorQue18Anos(){
// -- este método ira testar o cadastro de pessoas que não atende o criterio de idade, minha regra desta classe(negocio)
}
@Test
public void deveEditarUmaPessoaApenasSeAIdadeForMaiorQue18Anos(){
// -- este método ira testar a edilão de pessoas que não atende o criterio de idade, minha regra desta classe(negocio)
}
// e por ai vaii.., cada regra é testada em um método separado dentro de cada classe de test
}
No meu caso, eu não preciso ter historico dos testes em planilhas., simplesmente tem que funcionar se não o codigo não esta correto para produção, no meu caso…
Minhas respostas seriam:
Se tiver escrevendo varios testes apenas em uma classe, tá errado, cada classe deve ter uma classe respectiva para teste
Não, o correto seria ter uma classe de teste, que teria métodos que testariam a inclusão e alteração.
[quote=Araujobr]Antes de mais nada agradeço pelos comentários.
Vou dar outro exemplo.
Imagine que vc tenha uma classe que faça cálculos de pensão alimentícia, essa classe calcula as pensões:
1-)Um terço sobre o Salário Bruto.
2-)Um terço sobre o Salário Liquido.
3-)Vinte por cento do Salário Bruto.
Imagine que os três cálculos são feitos em métodos diferentes na mesma classe.
Qual seria a forma correta de testar.
Teríamos três classes de teste ou somente uma para testar tudo?
Obrigado.
[/quote]
Não sou especialista em testes, para afirmar se seria certo ou errado, mas eu criaria uma classe única de testes para testar os cálculos gerados por esse objeto.
Neste seu caso, eu criaria apenas uma classe de teste, sendo que nesta classe teria 3 métodos que testam cada funcionalidade descrita por vc…
Exemplo:
public class PensaoAlimenticiaUnitTest{
@Test
public void deveCalcularUmTercoSobreoSalarioBruto(){
//implementacao do test
}
@Test
public void deveCalcularUmTercoSobreoSalarioLiquido(){
//implementacao do test
}
@Test
public void deveCalcularVintePorcentoSobreoSalarioBruto(){
//implementacao do test
}
}
Os testes tem que ser simples, ao ponto de ser auto explicativo, isso ajuda muito na hora de fazer manutenção nos testes e a documentação fica visivel facilmente atraves das classes de test, sem contar outras coisa há + tb como design das classes. Esta é a maneira correta a meu ver, separar cada criterio/regra de suas classes em métodos auto explicativo, cada método testa uma coisa.
Não tem certo e errado nessa questão filosófica. O que eu acho importante considerar é: se você quer quebrar os testes de uma classe em mais de uma classe, isso não seria uma indicação de que a classe sob teste está com responsabilidades demais?