Beginner Unit Testing - testando entradas complexas para métodos

9

Estou aprendendo a usar o Unit Test e lutando com alguns conceitos bem básicos. Vamos dizer que eu tenho dois métodos.

O método A pega um arquivo como entrada e retorna uma hierarquia complexa de objetos.

O método B pega a hierarquia de objetos e faz algo com ela.

Eu entendo como testar o Método A (e os vários outros métodos que ele chama por sua vez). Estou confuso com a melhor forma de testar o Método B.

Eu posso construir uma falsa hierarquia de objetos no meu teste de unidade para ser a entrada para o Método B, mas quando faço isso parece que meu teste de unidade se tornou menos de teste no Método B e mais de um teste criou manualmente uma hierarquia de objetos válida corretamente.

Parece mais lógico testar o Método A, manter a saída e depois usá-lo para testar o Método B, mas entendo que cada teste de unidade serve apenas para testar uma coisa.

Eu (acho) eu entendo o conceito de zombaria e fingimento, mas não tenho certeza se essa é a resposta aqui, pois o Método B vai usar a hierarquia do objeto inteiro e não apenas olhar para uma pequena parte dele.

    
por Plessiez 16.05.2011 в 03:49
fonte

1 resposta

5

Um teste unitário rigoroso testa algo isolado. Então, se é um teste de unidade, você deve testar de forma isolada. Você também pode ter testes de integração que testam methodA e methodB juntos. Eu pessoalmente começaria com um teste de unidade base que testa de forma isolada, especialmente se o método B não é trivial ou é de missão crítica. Quando você testa isoladamente, reduz a possibilidade de que algo sobre o teste esteja causando um passe, quando um teste isoladamente revelaria uma falha.

Existem casos em que é impraticável testar isoladamente. Há também casos em que dois métodos são tão triviais que eu os testaria juntos, como setters / getters. No entanto, isso não parece um deles porque você está reclamando principalmente sobre a criação dos dados de teste.

Para aliviar a dor da criação de dados para teste de unidade, eu frequentemente construo uma classe TestUtil com métodos estáticos (em Java-terra) que retornam dados para testes, e então eu teste o TestUtil . Dessa forma, eu só vou passar pela dor de fazer um tedioso objeto de construção uma vez, e estou confiante de que está correto. No seu caso, desde que você testou o código de geração de arquivos, eu pegaria sua saída e a colocaria em um desses métodos utilitários, e então usaria o método utilitário para testar o methodB isoladamente.

Finalmente, se methodB toma uma entrada complexa, e faz seu trabalho em toda a entrada, e é complicado, pode ser que o methodB seja muito complicado e deva ser dividido em métodos menores, mais gerenciáveis e testáveis.

Um dos principais benefícios do teste de unidade / integração é o design do aplicativo. Se é difícil testar, provavelmente é muito complicado ...

EDIT - pelo seu esclarecimento, parece que o método B é bastante complicado. Definitivamente, teste os métodos que B chama isoladamente; a única vez que eu não faria isso é se todos os métodos são privados e não podem ser testados isoladamente.

    
por hvgotcodes 16.05.2011 / 03:54
fonte