Estava escrevendo uns testes e me bateu uma dúvida. Para efeito de exemplo, suponham que eu tenha um método assim:
[code]public class Calculadora {
public Calculadora() {
// Faz algo
}
// …
public double dividir(double a, double b) {
if (b == 0) {
throw new ArithmeticException(“Divisão por zero.”);
}
return a / b;
}
}[/code]
Agora suponham que vou escrever uma classe de testes para testar essa calculadora. Eu tenho duas alternativas:
Testar cada possibilidade de erro em um método diferente.
[code]@Test(expected = ArithmeticException.class)
public void testeDivisaoPorZero() {
Calculadora calc = new Calculadora();
calc.dividir(1, 0);
}
@Test
public void testeDivisao() {
Calculadora calc = new Calculadora();
assertTrue(calc.dividir(10, 2), 5);
}[/code]
2) Testar as duas possibilidades em um mesmo método de teste.
@Test(expected = ArithmeticException.class)
public void testeDivisao() {
Calculadora.calc = new Calculadora();
calc.dividir(1, 0);
assertTrue(calc.dividir(10, 2), 5);
}
Já que a linha 4 da segunda alternativa disparará uma exceção com toda certeza, a linha 5 será testada?
Eu não sei te responder com precisão, mas seria legal você fazer o teste e falar o resultado para nós
Agora é comum você fazer seus testes separados por métodos, ou seja, cada método na sua classe JUnit deve testar apenas 1 ação. Fica mais fácil para entender o teste, assim como fazer futuras melhorias/refactoring.
Entendi.
De fato, o assert após a chamada ao método que lança a exceção nunca seria executada, conforme confirmei posicionando o System.out.println(“Teste”) em posições estratégicas.
Mas peczenyj, no caso desse exemplo da calculadora, não estou conseguindo enxergar a necessidade de escrever um método setUp(), a não ser que fosse para criar um objeto da classe Calculadora que seria utilizado em todos os métodos de teste. Especificamente nesse exemplo da calculadora, o que você colocaria no setUp()?
Ahhh, então o setUp() é executado antes de cada teste?
Eu pensava que fosse executada apenas uma vez, como um construtor. Mas se eu fosse mais inteligente, perceberia que não faria sentido criar um método setUp() que faz o mesmo que um construtor :oops: