Bom eu nunca usei mocks, na verdade trabalho em um ambiente sem cultura de testes, desatualizado, onde agilidade, boas práticas, inovação, passam longe. Até por isso, estou cumprindo meu aviso prévio lá e vou caçar uma vaga melhor no mercado.
Tenho estudado TDD por conta, estou lendo um livro e tenho mais 2 engatilhados para ler. EStou muito interessado por este assunto, o próprio conceito de mock, stubs, ainda não está 100% claro pra mim, mas está no pipeline de estudo.
Bom lá onde trabalho já integramos com diversos sistemas de terceiros. O que o pessoal costumava fazer era gerar uns retornos fakes no código mesmo para ter o que exibir nas telas, grids, etc…depois de bem adiantada a parte visual conforme o desenvolvimento ia andando eram gerados simuladores ou quando a integração era com banco ai o DAO buscava direto do banco mesmo, era gerada uma massa fake, etc…
Bom nessa experiência o que pude observar é que toda vez que o sistema ia pra homologação no cliente ou deploy em produção pipocavam erros que não aconteciam nos simuladores ou base fake pq assim como os mocks, e o cara disse lá na thread do Bill Burke:
“When you DO use mocks you are testing in an environment that is biased toward a passing test. An artificial environment will always make invalid assumptions about the behavior and stability of that environment.”
Bom eu acho que nesse ponto não tem muito o que fazer mesmo, é só testando a quente que a coisa vai ferver mesmo, é na base de produção que vai ter um cara lá com um nome escroto gigantesco truncado e o sistema não vai conseguir fazer o match em algum ponto. Ou vai ter um senhor lá com 103 anos de idade e algum infeliz fez alguma conta envolvendo idade pensando somente em 2 dígitos, etc…
Mas até aí, acho que o cara que inventou o mock, ou o teste unitário, ou o que quer que seja, nunca pensou em cobrir todos esses cenários, na verdade o que percebo é que alguns acham que o teste unitário é a verdade, “ah, deu verde, blz tá funcionando”. Não é bem assim. Na verdade estudando TDD percebe-se (se eu estiver errado me corrijam) que o simples teste em si depois de pronto é o que gera menos valor no processo, é o menos “importante” digamos assim, como li no livro de DDD do Jimmy NIlson, ele cita um colega dele que fala que o verdadeiro valor do TDD está no vermelho e não no verde.
Os testes são importantes e é extremamente necessário ter essa cobertura de testes (sejam feitos antes via TDD ou não) principalmente para refactoring, mas o resultado de um teste ao meu ver não é nem nunca vai ser algo 100% confiável.
Então o problema as vezes é que o pessoal gerencia mal as expectativas.
Sobre o que usar, como disse ainda estou estudando essas coisas etc, mas sou mais um na onda do “depende”.
Minha conclusão baseado no que usei é que simuladores e bases fakes muitas vezes mais atrapalham do que ajudam até pelo tempo que se consome para construir (simulador de web service por exemplo é um saco, mainframe então…), gera mais código para manter (depois de 2 anos vai um outro cara que não participou daquele desenvolvimento mexer em uma rotina que precisa do simulador, não funciona nada e demora 1 dia para descobrir que a base que tava apontando nem existe mais ou o banco migrou de servidor) então nos últimos projetos minha ideia era ou atuar em um legado o mais próximo possível da realidade como uma cópia da base de produção mascarada ou então usar uma solução o mais simples possível e gastar o tempo outrora gasto em construir essas porcarias para revisar melhor o código, discutir as implementações com os programadores, fazer pareamento, etc…
abs
