Devo usar o try catch nos meus métodos de teste?

18

Estou fazendo testes de unidade.

Estou tentando testar uma função.

Eu chamo isso do meu componente de teste. Mas se a função remota não puder lidar com a exceção, meu componente testador também receberá exceção, eu acho.

Então, devo me preocupar em obter uma exceção no meu componente testador?

Obrigado.

EDITAR:

PS:

Lançar um erro é bom, mas apenas para outras funções, não para usuários finais até que seja a última opção!

OMG eu escrevi uma citação de programação !!

testing unit-testing exceptions

— Vikas
fonte

Eu sou novo no teste e devo testar apenas o comportamento da função. Eu acho que é chamado de teste de caixa preta e caixa branca. Ah, eu lembro disso. Eu estudei isso na faculdade!

— Vikas

Qual linguagem e estrutura do xUnit você está usando especificamente? Eu diria que sim em alguns casos.

— Greg K

Estou usando o MXUnit com a linguagem MockBox e ColdBox for ColdFusion.

— Vikas

23

Resposta curta: NÃO.

Não pegue exceções em testes de unidade. Você está testando a unidade para encontrar erros e situações em que as exceções são geradas.

A estrutura de teste de unidade deve lidar com exceções de maneira sã. A maioria das estruturas (se não todas) do xUnit tem uma construção que espera certas exceções que você usa quando deseja induzir uma condição de exceção específica no sistema em teste e passa no teste se a exceção esperada for gerada, mas falhar, caso contrário.

— mcottle
fonte

Eu acho que a estrutura de testes avançados pode lidar com exceções muito bem, mesmo eu acho que no Visual studio podemos testar contra exceções como você disse "exceção esperada". Então é bom saber e compartilhar. Obrigado ..

— Vikas

Às vezes, você deseja verificar se uma exceção é lançada, porque bons testes não testam apenas casos em que as coisas funcionam, mas também casos em que elas falham.

— Deadalnix

1

Você deseja capturar exceções, assim como deseja testar as situações nas quais as exceções acontecem (especialmente suas próprias exceções). Se você escrever um código projetado para falhar com uma exceção sob certas condições, essas condições deverão fazer parte do seu conjunto de testes e, portanto, deverão ser testadas. Sob esses testes, essas exceções devem ser capturadas e analisadas.

— precisa saber é o seguinte

1

@Jwenting Leia o segundo parágrafo - estruturas de teste de unidade capturar as exceções e permitir testes para passar se certas exceções são levantadas e falhar se eles não são

— mcottle

5

(Em contraste com a resposta de mcottle) Resposta longa: NÃO ... na maioria das vezes

Quando você diz que espera que um teste gere uma exceção específica, você saberá quando QUALQUER linha nesse teste gera essa exceção específica.

Isso não é o mesmo que saber que o método em teste gera a exceção.

Se o seu teste envolver a configuração de um objeto ou contexto (dentro do teste, e não na versão de sua estrutura SetUp), é melhor agrupar a única linha que você realmente deseja testar em uma tentativa / captura, possivelmente com um ajudante.

Por exemplo,

public static class AssertHelper {
    public delegate void Thunk();

    public static void DoesNotThrow<T>(Thunk thunk, string message = "")
        where T: Exception {
        try {
            thunk.Invoke();
        } catch(T) {
            Assert.Fail(message);
        }
    }
}

e depois

[TestMethod]
public void assertHelperInAction() {
    // Random setup stuff here that's too annoying to put in my SetUp
    // method.
    AssertHelper.DoesNotThrow<IllegalArgumentException>(() =>
        {/* My random method under test */})
}

Se esse teste falhar, sei que meu método em teste lançou a exceção, e não algo no material de instalação aleatória.

(Você deve tentar evitar itens de configuração aleatórios. Às vezes, é mais fácil ter algum código de configuração no teste.)

— Frank Shearar
fonte

Bom exemplo! Eu tento ser muito cuidadoso ao limitar a fase "teste" apenas ao teste preciso, mas lembrarei desse truque para quando simplesmente não conseguir descobrir uma maneira de fazer isso (por exemplo, ao testar uma condição de corrida e precisa de 'configuração' próxima ao 'teste' para atingir a condição).

— Ethel Evans

1

Em geral, você deve deixar escapar a exceção, e a estrutura de teste fornecerá um bom relatório com todas as informações necessárias.

Mas na metodologia TDD, espera-se que você siga os seguintes passos:

Escreva um teste
Assista a falha e torne o erro compreensível
Corrija o código
Refatorar o código e o teste

Quando você solta uma exceção, se o erro estiver claro, tudo bem. Mas, às vezes, a exceção é obscura ou até equivocada. Como você pode deixar isso constar no seu código (para você mais tarde, quando tiver esquecido, ou para um membro da equipe que perderá muito tempo tentando descobrir o problema)? Portanto, minha política é: " Se for necessário esclarecer uma falha, você precisará capturar a exceção ".

— KLE
fonte