Quem conhece um site que mostre modelos de testes do Junit com integração com o banco de dados?
Estou me referindo somente a consulta
De início, tenha em mente que, se o teste for unitário, não será integração.
Agora para realizar um teste de integração, vai depender do que vc está usando para desenvolver seu sistema.
Não existe teste unitário integrado, fera.
Teste unitário visa testar a menor unidade testável de um sistema, ou seja, um método (teoricamente, deveria ser uma classe, pois a classe deve ter uma única responsabilidade. Ocorre que, muitas vezes, criamos vários métodos e damos à classe “superpoderes”. É errado, mas é feito). A ideia básica do teste unitário é explorar todas as possíveis ocorrências que sigam o caminho feliz e os possíveis desdobramentos tristes.
Teste integrado, aquele em que você vai até o banco de dados, é outra coisa. Visa entender a relação da estrutura criada (lógica + modelo) para uso com algum tipo de informação.
Neste aspecto, para entender melhor sobre testes unitários, integrados, smoke tests, caixa preta, caixa branca e regressão, TDD, BDD, DDD e tantas outras siglas relacionadas, seria bom você procurar um curso específico.
Essa é uma das falhas que temos nos cursos (superiores ou não) de programação: poucos são os que se preocupam em ensinar isso. A regra geral é testar em produção e corrigir bugs em homolog.
3 curtidas
Deve estar se confundindo ao dizer unitário na frase, mas o que você quer deve ser isso:
tudo bem!
muito obrigado
Para teste unitário a melhor solução é “mockar”. Seja com auxílio de alguma lib ou criar os repositórios fakes na unha mesmo. Agora, para integrados, eu acho interessante partir para algo in-memory. H2 com Spring Boot fica lindo!
Se a funcionalidade que ele quer testar depende de banco de dados, testa logo integralmente o que é usado de fato, sem esses testes de mentirinha.
Mentirinha é o H2 como db in memory ou o Mock?
Mock.
E como você simula cenários massivos de forma que cubra também o que você ainda não tem na sua massa de dados por um custo baixo de não ter que criar cenários que não precisam do IO do database?
Se ainda não tiver o cenário, nao entendi qual problema de inserir quando necessário. É opção sua querer solução que economize recursos de IO, por outro lado o teste fica bem longe do que acontece de fato.
Não disse que é um problema, quero apenas entender o cenário mesmo. Lembro de um projeto onde tínhamos 93% de cobertura sendo quase 100% disso integração.
Para fazer um deploy os testes duravam em média 56 minutos para executarem quando subíamos na máquina de prod (em dev era absurdo). Reduzimos tudo que podíamos incluir em mocks ao invés de bater no banco de dados e reduzimos o tempo para 9 minutos.
Conseguimos sair de 2 deploys/dia para 4 e ainda criou-se a capacidade de aumentar os cenários de testes. Claro que dependendo da sua realidade isso é irrelevante, mas para empresas que trabalham com validação/MVP é questão de vida ou morte. 
1 curtida
Tempo se resolve com execução de testes em paralelo, com n máquinas virtuais ou n físicas se necessário. É questao de investimento, mas fazer teste em cima de algo fake é justificável se está mais preocupado com economia do que efetividade, sem testar o que é executado de fato na aplicação.
Sim, se você tem muita $$ pra investimento e pode fazer, maravilha, normalmente não é o que se vê por aí, afinal tanto investimento assim por algo que dá pra fazer de forma bem mais simples garantindo praticamente o mesmo resultado é visto por muitos como “rasgar dinheiro”. But, quem tem pra fazer que o faça
Não tem como ser o mesmo resultado se você está deixando de testar parte do código que realmente é executado na aplicação, seu teste deixa mais furos.
Em um projeto spring boot, faço teste de integração simulando as tabelas com H2, mas tenho uma entidade mapeada com JoinTable e por não ter uma classe java nem um repository para um .save, como simulo ela no teste de integração?