Estou com dúvida no curso de Testes de Unidade e TDD, no exercício do capítulo Testando exceções.

Ao meu ver o try catch não faz muito sentido em código de testes porque queremos somente validar se a exceção foi ou não lançada, já no código de produção o try catch é usado para tentarmos recuperar o sistema em caso de falha

Caro, Eu vejo com muito entusiasmo testes de software, mesmo que o nome não ajude muito. Acredito, porque observo diversas vantagens ao praticar. Dentre estas vantagens, percebo que é possível aprender como usar uma funcionalidade ao ler seus testes. Fica muito claro para qualquer programador, e por vezes, mesmo para leigos. Neste sentido gostaria de compartilhar minha opinião de que uma anotação torna quase que oculta, e pode passar despercebida, ao passo que um try catch dentro do código de testes é um exemplo concreto de como usar o código. Entretanto observe, a opinião de cada um não deve mudar pela opinião do outro. Posso estar errado, e como estou ficando velho, certamente também ultrapassado. Não se trata mais de programação em Cobol, nem tenho os mesmos vinte ou trinta aninhos de idade. Um abraço

Oi Fernando,

entendo sua visão na questão da legibilidade e até passei por ambos os modelos: no JUnit3 a única opção era fazer um código que falhava quando passava impune por uma linha de código e passava apenas quando caía no catch. Ele ficava mais ou menos assim:

public void testCadastrarProdutoSemNomeCausaExcecao() {
    try {
        new Produto(null, 10.55);
        Assert.assertTrue(false);
    } catch (IllegalStateException e) {
        Assert.assertTrue(true);
    }
}

No começo, eu realmente estranhava a forma nova, com a configuração na anotação, mas com o tempo, meu olho foi treinando para enxergar o expected como parâmetro e, hoje, eu realmente acho mais bonito (e meu time acha que éramos loucos por fazer da outra forma) ter a versão muito mais reduzida que a anotação permite:

@Test(expected=IllegalArgumentException.class)
public void cadastrarProdutoSemNomeCausaExcecao() {
    new Produto(null, 10.55);
}

Acredito mesmo ser uma questão de costume. Que tal perguntar a opinião do seu time sobre isso? :-)

A minha humilde opinião é depende do caso.

A solução da @Cecilia é ótima para excecões customizadas, específicas para uma regra de negócio, além de usar um recurso do @Test(expected) do JUnit (bem mais legível). No entanto para sistemas legados que lançam exceções mais genéricas (IllegalArgumentException por exemplo) podemos ser enganados pelo teste passar, quando na verdade algum outro ponto da regra de negócio lançou essa mesma exceção.

Neste caso acho válido a solução do @Fernando

public void testCadastrarProdutoSemNomeCausaExcecao() {
    try {
        new Produto(null, 10.55);
        Assert.fail();
    } catch (IllegalStateException e) {
        Assert.assertEquals("Produto Sem Nome", e.getMessage());
    }
}

Não considero isso elegante, mas é considerado mais seguro nesse caso devido ao problema das exceções genéricas de código legado.

Olá Fernando! Conseguimos tirar sua dúvida? Esperamos que sim! Inclusive você pode dar os créditos à resposta que você acha justa clicando em "Marcar como solução".

Abraço

Obrigado, Flavio. Quero deixar registrado que considero os cursos muito bons. Um grande abraço amigo.