No momento, estamos escrevendo casos de teste de unidade em nosso projeto. As implementações para métodos de banco de dados existem e estão funcionando bem. Nesse caso, por que precisamos escrever objetos simulados? Existe algum motivo específico? Por que não consigo testar diretamente a implementação do DAO?
Respostas:
Você não deve simular chamadas para o banco de dados, pois isso anularia o objetivo. O que você DEVE zombar são, por exemplo, chamadas para o seu DAO, digamos, de uma camada de serviço. A zombaria permite testar métodos isoladamente.
Digamos que você tenha uma simulação de restaurante com uma arquitetura como esta:
Cook <=> Server <=> Customer
Você deseja testar cada camada independentemente. Aqui Serverestá a sua camada de serviço e Cookpode ser pensada como um DAO. O Serveré o que você quer zombar durante o teste Customer, e o Cooké o que você quer simulada durante o teste do Server. Os Cooktestes de unidade, no entanto, devem verificar se a implementação está devolvendo um hambúrguer quando um hambúrguer foi pedido e não um pneu de borracha.
Não há problema em testar o businesslogic junto com o banco de dados. mas esses testes são chamados de testes de integração, mesmo se você usar nunit ou junit ou phpunit para executá-los.
Os unittests são testes espezializados nos quais é importante testar isoladamente (ou seja, buisinesslogic sem o banco de dados). Zombarias / falsificações / stups são usados para impor esse isolamento.
Simplesmente: para testar o DAO real e não o conteúdo do banco de dados.
Suponha que sua classe DAO Person tenha um método getByName (). Você escreve um teste e chama Person.getByName ("John Smith"). Suponha que o teste falhe, porque alguém removeu o registro de John do banco de dados. Agora, todo software de CI e seus supervisores / revisores podem afirmar que seu software está com defeito, enquanto na realidade não está. Se você zombar do banco de dados, poderá provar que seu DAO funciona se receber a linha correta da tabela correta.
Se você realmente deseja testar o próprio banco de dados, ou seja: se a execução de um determinado método DAO coloca os dados em um determinado estado, também é possível. Além disso, é realmente útil com modelos de dados malucos (EAV, conjunto de árvores aninhadas), onde você não pode esperar que o banco de dados forneça integridade à prova de balas. Dê uma olhada no DBUnit para facilitar sua vida.
Outro motivo é evitar o tempo de execução da execução real dos comandos do banco de dados. Pode não parecer muito, mas a sobrecarga de configuração e remoção de conexões acabará aumentando e provavelmente aumentará significativamente o tempo total para executar o conjunto de testes em comparação ao uso de objetos simulados.
Para isolar a classe que você está testando. Caso contrário, se o teste falhar, como você sabe que o problema está na classe que está testando ou em uma de suas dependências.