Qual é o ponto de testar repositórios falsos?
-
03-07-2019 - |
Pergunta
Eu venho tentando empurrar o meu mentallity ao desenvolver em casa para ser mais orientada para TDD e um pouco DDD.
Uma coisa que eu não entendo, porém, é por que você iria criar um repositório falso para teste contra? Eu realmente não tenho olhei para ele muito, mas certamente a idéia do teste é ajudar a separar o seu código (dando-lhe mais flexability), aparar as código necessário e reduzir o número de erros.
Assim, alguém pode preencher meu cérebro tolo a ponto de por que alguns gostam de falsos repositórios de teste? Eu teria pensado que testar contra um banco de dados real é uma alternativa muito melhor para criar um falso porque então você sabe que ele trabalha contra a sua loja real de dados mundial.
Solução
O repositório falso permite que você teste apenas o código do aplicativo.
O repositório falso significa um teste automatizado pode facilmente configurar um estado conhecido no repositório.
O repositório falso será várias ordens de magnitude mais rápido do que um banco de dados real.
O repositório falso não é um substituto para testes de sistema que irá incluir o seu banco de dados.
Outras dicas
A meu ver, há duas realmente grandes razões pelas quais você testar contra os recursos falsos:
- Não faz o teste de unidade mais rápido Quando você tem um zombou contra lento I / O ou banco de dados. Isso pode não parecer qualquer coisa, se você tem um conjunto de testes pequeno, mas quando você está até +500 testes de unidade que ele começa a fazer a diferença. Nesse montante, os testes que são executados no banco de dados vai começar a demorar alguns segundos para fazer. Os programadores são preguiçosos e querem coisas para ir mais rápido por isso, se a execução de um conjunto de testes leva mais de 10 segundos, em seguida, você não vai ser feliz para fazer TDD mais.
- Obriga você a pensar sobre seu projeto de código para fazer mudanças mais fácil. Design by injeção contrato e dependência também se torna muito mais fácil de fazer se você tiver feito a implementação em função interfaces ou classes abstratas. Se feito tal direito design faz com que seja mais fácil cumprir a mudanças em seu código.
O único inconveniente é o óbvio:
- Como você pode ter certeza de que ele realmente funciona?
... e é isso que os testes Integração são para.
Eu upvoted resposta de Giraffe, mas quiser adicionar apenas um par de pontos:
-
Cada desenvolvedor pode usar um mock / fake repositório para seu / sua própria unidade teste sem interferir com o testes a ser feito por outros desenvolvedores no mesmo projeto.
-
Usando um mock local / repositório falso reforça o utilizador de um conjunto de dados camada de abstracção, o que é bom concepção prática.
Como um exemplo, eu usei algo tão simples como um HashMap
para implementar uma simulação da camada de acesso a dados. Isso torna extremamente fácil para cada unidade de teste para garantir que exatamente existem as condições necessárias para a sua finalidade, e para verificar se as chamadas corretas foram feitas sobre a camada de acesso a dados.