# Testes integracao mock banco: guia passo a passo > Testes de integração com mocks de banco de dados permitem validar regras de negócio e fluxos sem infraestrutura real. A técnica substitui dependências externas por simulações controladas, garantindo previsibilidade e velocidade na execução. O guia passo a passo demonstra configuração de mocks, cenários de sucesso e falha, e verificação de interações com o repositório. Essa abordagem reduz custos e aumenta a confiabilidade dos testes automatizados em ambientes de desenvolvimento e CI/CD. *Blog Sem Juízo · Novidades · 03 de setembro de 2026 · Babi Cordeiro* Testes de integracao sem banco real sao possiveis e eficazes. Veja como usar mocks para validar regras de negocio e fluxos sem depender de infraestrutura. Testes de integracao com mock de banco resolvem um problema classico: como validar a logica da aplicacao sem depender de um banco real que pode estar lento, indisponivel ou com dados inconsistentes. A resposta esta em simular a camada de persistencia com mocks, mantendo o foco no comportamento da aplicacao. Neste guia, vamos mostrar um caminho passo a passo para estruturar esses testes, com dicas e erros comuns para evitar. ## Passo 1: Entenda o que voce quer testar Antes de escrever qualquer teste, defina o escopo. Testes de integracao com mock de banco nao validam SQL, constraints ou indices. Eles validam como sua aplicacao usa o repositorio, como os servicos orquestram as chamadas e como os dados sao transformados entre as camadas. Se a sua preocupacao e a query em si, um banco real ou um Testcontainers sao mais adequados. Para logica de negocio, o mock resolve. **Dica:** liste os fluxos criticos que precisam de cobertura, como criar um pedido, atualizar um usuario ou consultar um relatorio. Cada fluxo vira um cenario de teste. **Erro comum:** tentar mockar tudo, inclusive o que nao e necessario. Isso gera testes fragilizados que quebram a cada mudanca de implementacao interna. ## Passo 2: Configure o mock do repositorio ou DAO Na maioria dos frameworks modernos, como Spring Boot, Micronaut ou Quarkus, a injecao de dependencia facilita substituir a implementacao real do repositorio por um mock. Use bibliotecas como Mockito, MockK ou a extensao de mocking do seu framework. O mock deve responder as chamadas esperadas com dados controlados, sem executar SQL de verdade. **Exemplo:** se o metodo findById do repositorio deve retornar um objeto Usuario, o mock retorna esse objeto quando o metodo e chamado com um ID especifico. Nada de banco, nada de conexao. **Erro comum:** esquecer de configurar o retorno para todos os caminhos possiveis. Um teste que nao define o comportamento do mock para uma chamada inesperada falha com NullPointerException ou retorna null silenciosamente. ## Passo 3: Isole o teste com um cenario especifico Cada teste deve representar um cenario unico, com dados de entrada bem definidos. Nada de dados aleatorios ou dependentes de execucao anterior. O mock garante que o estado inicial e sempre o mesmo, entao voce controla exatamente o que acontece. **Dica:** use nomes de teste descritivos, como deveLancarExcecaoQuandoPedidoNaoEncontrado. Isso documenta o comportamento esperado e facilita a manutencao. **Erro comum:** criar testes que dependem da ordem de execucao. Mocks independentes evitam isso, mas se voce usa um objeto compartilhado entre testes, pode haver interferencia. Prefira criar um mock novo para cada teste. ## Passo 4: Valide as interacoes, nao so o retorno Um bom teste de integracao com mock nao verifica apenas o resultado final. Ele tambem verifica se as chamadas esperadas aconteceram, na ordem certa e com os argumentos corretos. Isso garante que o fluxo interno da aplicacao esta correto. **Exemplo:** ao testar um servico que salva um usuario e envia um email, verifique se o metodo save do repositorio foi chamado uma vez e se o servico de email tambem foi acionado. Se o repositorio nao for chamado, o teste falha, revelando um bug de logica. **Erro comum:** usar verify em excesso, checando detalhes irrelevantes da implementacao. Isso torna o teste acoplado ao codigo e quebra facilmente em refatoracoes. ## Passo 5: Combine mocks com um banco real quando necessario Nenhuma estrategia e absoluta. Ha casos em que o mock nao basta, como quando a query usa funcoes especificas do banco ou quando a integracao com o ORM precisa ser validada. Nesses cenarios, considere usar um banco real em memoria, como H2, ou um banco descartavel via Testcontainers. O equilibrio ideal costuma ser: mocks para a maioria dos testes de servico, banco real para testes de repositorio e de integracao pontual. **Dica:** mantenha os testes com mock mais rapidos e os com banco real mais lentos. Se a suite inteira ficar lenta, os desenvolvedores tendem a nao rodar. **Erro comum:** usar banco em memoria para todos os testes, achando que isso substitui o mock. Isso pode dar falsa sensacao de seguranca, pois o H2 nao se comporta identico ao banco de producao. ## Passo 6: Documente e padronize no time Sem padrao, cada dev escreve testes de um jeito e a suite vira um caos. Defina convencoes: quando usar mock, quando usar banco real, como nomear testes, como organizar os cenarios. Isso vale mais do que qualquer ferramenta. **Dica:** crie um exemplo de teste de integracao com mock no repositorio do projeto, servindo de referencia para o time. **Erro comum:** deixar a documentacao desatualizada. Se a convencao mudar, atualize o exemplo e comunique o time. ## Checklist do que foi feito - Voce definiu o escopo do teste, separando logica de negocio de persistencia. - Configurou mocks para repositorios e DAOs com dados controlados. - Criou cenarios isolados, sem dependencia de estado anterior. - Validou as interacoes com verify ou equivalente. - Combinou mocks com banco real apenas quando necessario. - Documentou a estrategia para o time. ## Perguntas frequentes ### Qual a diferenca entre testes unitarios e testes de integracao com mock? Testes unitarios testam uma unica unidade, geralmente um metodo ou classe, isolando todas as dependencias. Testes de integracao com mock testam a interacao entre componentes, como um servico e um repositorio, mas sem usar a infraestrutura real. O mock substitui o banco, mas o fluxo entre as camadas e real. ### Quando devo usar mock em vez de um banco de teste real? Use mock quando o objetivo e validar a logica de negocio, regras de validacao ou orquestracao de chamadas. Use banco real quando precisar validar queries, constraints ou o mapeamento do ORM. A escolha depende do que voce quer garantir com o teste. ### Testes com mock de banco sao suficientes para garantir qualidade? Nao sozinhos. Eles cobrem a logica da aplicacao, mas nao garantem que as queries funcionem no banco real. O ideal e ter uma piramide de testes: muitos testes unitarios, alguns testes de integracao com mock e poucos testes com banco real ou Testcontainers para os pontos criticos. ### Como evitar que mocks deixem os testes lentos ou instaveis? Mocks sao naturalmente rapidos, pois nao ha I/O. Para evitar instabilidade, crie um mock novo por teste, defina retornos explicitos para todas as chamadas e evite verificar detalhes internos desnecessarios. Isso mantem os testes deterministicos. ### Posso usar mock de banco para testar uma API REST completa? Sim, e comum. Ao testar um endpoint, o servico usa o mock do repositorio, e a camada HTTP e validada com o framework de testes. Isso permite testar serializacao, status codes e tratamento de erros sem subir o banco. ### Qual a melhor biblioteca de mocking para Java? Mockito e a mais popular, com integracao nativa ao Spring Boot. Para Kotlin, MockK e uma alternativa forte. A escolha depende da linguagem e do framework, mas o conceito de mock e o mesmo em todas. --- Fonte (canonical): https://blogsemjuizo.com.br/novidades/testes-integracao-mock-banco-guia-passo-a-passo/