O que devo zombar nos testes de um aplicativo com a camada de serviço e a DAO?

8

Minhas aulas estão seguindo essa estrutura

Camada de serviço (cria e mapeia InputDTO para dados de banco de dados)
Camada DAO (na verdade, executa chamadas de banco de dados)

Quando escrevo testes JUnit da camada de serviço, a camada DAO é chamada e isso espera uma conexão com o banco de dados real e a obtenção de dados do banco de dados.

Devo estar zombando completamente da camada DAO da camada de serviço ou zombando da conexão e dos dados recebidos do banco de dados?

Em segundo lugar, o aplicativo espera determinados dados de um cache.

Para o tempo de execução do JUnit, não há cache; então, como isso deve ser tratado? O método da camada de serviço inclui procurar no cache para obter os detalhes.

— shinynewbike
fonte

9

Eu vou falar sobre Test Duplas, se você não tiver executado através deste prazo, então você provavelmente vai wan para ler o artigo de Martin Fowler ligação pela primeira vez.

Para o teste do banco de dados - Se você estiver seguindo uma abordagem pura de teste de unidade, use um tipo de teste duplo Stub ou Mock para simular a conexão com o banco de dados e suas respostas. Se você estiver usando um Mock , eu recomendaria o Mockito, o JMock ou sua outra ferramenta de zombaria favorita. No entanto, isso é bastante trabalhoso quando se trata de testar um grande recurso de terceiros, como um banco de dados.
Para o teste do banco de dados - Se você estiver seguindo uma definição um pouco mais flexível de teste de unidade, poderá usar um falso teste duplo. No seu caso particular, esse seria um banco de dados na memória, como o HSQL. Essa é uma maneira muito popular de 'unidade' testar sua camada de banco de dados. Alguns argumentam que este não é um teste de unidade, e que é um teste de integração. Eu acho que está tudo bem - o fato é que você tem alguns testes que excisam seu código :-)
Para o teste de cache - é provável que um estilo Stub do Test Double seja seu amigo aqui - dependendo da complexidade da API de cache.

HTH!

— Martijn Verburg
fonte

3

Linda resposta, nossa idéia é a abordagem pura de teste de unidade - tentando não criar grandes testes de integração, mas pequenos testes de unidade . Eu não estava ciente do termo Teste Duplas, graças

— shinynewbike

2

O +1 sempre favorece a maneira menor e mais simples de exercitar o código específico com o qual você está trabalhando. À medida que o sistema cresce, introduz testes de integração / funcionais / do sistema para atuar como indicadores rápidos de falhas.

— Gary Rowe

1

+1 por mencionar Mockito. É de longe a estrutura de zombaria mais intuitiva que já usei em qualquer idioma, e ainda possui recursos bacanas que reduzem a dor de forçar retroativamente em testes de unidade a um código legado que nunca foi originalmente projetado com testes de unidade em mente. O objeto Mockito Spy é incrivelmente útil para isso.

— Maple_shaft

Atualmente, o termo "teste de unidade" é mais comumente usado para descrever as características técnicas de um teste: um teste de unidade é um teste que é executado rapidamente e sem pré-requisitos. O termo "teste de integração", quando usado corretamente, descreve o objetivo do teste: testar a integração de peças. Portanto, um "teste de unidade" pode ser facilmente um "teste de integração" se ele testar alguma integração e executar rapidamente.

— Oberlies

2

No resumo, a resposta é bastante simples.

Você tem três camadas.

[O caso de teste] -> [O comportamento em teste] -> [Os colaboradores usados por esse comportamento]

A terceira camada é o que deve ser ridicularizado. Por exemplo:

o PokemonCaptureServiceTest;
testes PokemonCaptureService;
que usa Pokeball

Neste exemplo, verifica-se que Pokeballé lógica de terceiros. Ele exige que todos os tipos de encanamento como conexões de banco de dados e arquivos de propriedade etc. Você confia no seu terceiro testou-lo adequadamente, para que gostaria de omiti-lo do seu teste de PokemonCaptureService. Por isso, deve ser ridicularizado.

No entanto, em outro momento e local, o colaborador Pokeballé uma classe simples que introduz muito pouca complexidade no caso de teste e pode ser incluída no teste facilmente. Nesse caso, você pode optar por incluir uma instância real Pokeballna PokemonCaptureServiceinstância que está sendo testada.

Não existe uma regra rígida e rápida. Cabe a você projetar seus testes da maneira que lhe parecer melhor. Seu objetivo é criar testes corretos e de manutenção o mais rápido possível. A experiência é fundamental aqui. Faça mais testes e em breve você terá uma boa intuição.

— Synesso
fonte

0

É difícil dizer exatamente o que você deseja testar porque, a julgar pela pergunta, você está em todo lugar. Portanto, é difícil dar um exemplo prático de como proceder, além de levá-lo a artigos sobre como zombar de coisas. Então, você precisa ser mais específico e dividir as coisas um pouco:

Deseja testar para que o cache funcione corretamente?
Deseja testar alguma chamada de banco de dados em particular?
Deseja testar o aplicativo para que ele esteja usando o cache corretamente?

Depois de decidir exatamente qual é a unidade que você deseja testar, a seleção do que deve ser ridicularizado torna-se fácil: em um teste de unidade puro, tudo , exceto a "unidade em teste", deve ser ridicularizada. A lógica por trás disso é que você pode ter certeza, com base nas suas expectativas de configuração nos trocadilhos, de que a unidade testada funciona como deveria.

Fora isso, você pode escrever alguns testes no JUnit que são testes de integração, ou seja, usam menos zombarias. Mesmo que sejam usados como verificações de sanidade para ver se o design do software está correto, você deve estar ciente de que eles serão quebradiços e nem sempre fornecerão um indicador sobre o que exatamente está errado com seu aplicativo ou sistema.

— Spoike
fonte