Mock Objects em excesso podem atrapalhar | Guilherme Chapiewski
« Dijkstra, um grande jornalista
iPhone desbloqueado e funcionando no Brasil »
This entry was posted on Tuesday, August 28th, 2007 at 9:03 pm	and is filed under Integração Contínua, TDD, Testes. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.
5 Responses to "Mock Objects em excesso podem atrapalhar"
Rafael Mueller says:
Eu também acho que esta é a melhor abordagem.
Sempre procuro utilizar mock ou stub em coisas mais lentas (rede ou um maior processamento) nas outras situações prefiro utilizar um objeto "verdadeiro". Isto não é regra, depende da classe também que irei testar… é uma questão de feeling
Isso traz uma clara desvantagem que é a redução do isolamento do teste, mas traz um benefício também que ao fazer um teste da classe B que utiliza A, você pode testar um comportamento de A que havia esquecido.
Sobre testes unitários e testes de integração (e um exemplo usando Spring) | Blog do Urubatan says:
[...] Mock Objects em excesso podem atrapalhar [...]
Eu também acho Mock Objects melhor aproveitado nas dependências entre camadas. Como uma definiçaõ mesmo dos limities de forma clara. Como você disse, existem situações onde mocks se tornam contra-produtivos e eu citaria a implementação de um modelo de objetos onde há mais dependências e comportamentos para serem verificados, nesses casos eu prefiro usar objetos falsos e validação de estado.
O ideal é acomodar essas diferentes situações no mesmo projeto.
JMock - trabalhando com mock objets em java | Blog do PacMan says:
[...] claro que Mock Objects em excesso podem atrapalhar, mas é tudo uma questão de bom senso: costumo dizer para quem esta começando a focar os testes [...]
lookyller says:
Galera concordo plenamente que em muitas situações é complicado realmente aplicar um Teste Unitário isolando todas as dependências, por intermédio de Mock Objects.
No entanto, acredito também que essa complexidade se deve na maioria das vezes a uma falha de projeto, e não somente a questão do aplicar ou não?
Será que o projeto ou até mesmo a arquitetura adota não teria que ser revista? Se há muitas dependências na unidade testada, com certeza tem algo de errado por trás.
A minha opinião é que cada tipo de Teste aplicado tem seus objetivos bem idealizados e por consequência, se adotado uma abordagem já integrada na geração dos testes, alguns defeitos exercitados apenas em situações isoladas poderiam passar desapercebidos e vice-versa.