Qual é a diferença entre testes de unidade e integração? Pode usar mock?

[@CaiqueMoraes93]

Eu tenho um desejo profundo de ser professor e o senhor é uma das minhas principais referências. Um dia, quero ser tão excepcional na didática simples, cativante e esclarecedora como você. Obrigado por mais um conteúdo de valor, professor.

[@RodrigoBranas]

Obrigado meu amigo! Valeu pelo feedback, de coração! Desejo sucesso pra você!

[@arozendojr]

Para o desenvolvimento FrontEnd, ao realizar testes unitários ou de ponta a ponta (end-to-end), qual é a sua preferência entre Stubmatic e JSON-Server? Em que circunstâncias e por quê? Seria mais vantajoso esperar que a API esteja pronta para iniciar desenvovimento do FrontEnd?

[@encinecarlos]

A primeira pergunta não vou saber te responder, mas sobre a segunda, se o back ja tiver fornecido pelo menos o contrato dessa API já é suficiente para o front iniciar o desenvolvimento, já trabalhei em time onde eu logo no inicio do desenvolvimento já passava para o time de front os contratos de requisição e resposta, em outros projetos as APIs já eram documentadas antes mesmo do desenvolvimento, dessa forma o front não fica parado esperando pelo back.

[@RodrigoBranas]

pra mim o ideal é ter todos os tipos de teste, comportamento independente com testes de unidade, componentes com teste de integração e o fluxo completo testado com end-to-end. A combinação é que faz com que exista a abrangência necessária para garantir que exista confiança no código e evite regressão e defeitos em produção

[@eurico_dev]

Começa a postar vídeos aqui novamente professor branas 🚀

[@RodrigoBranas]

vou sim, obrigado por acompanhar!

[@cronnosli]

Olha eu concordo 98% contigo. Apresento aqui um argumento sobre por que testes de integração não devem envolver bancos de dados. Dados não são determinísticos - variações no estado do banco e/ou dados podem levar a inconsistências nos resultados. Assim como ocorre com serviços externos, bancos de dados podem "sujar" os testes com comportamentos inesperados. Importante ressaltar que, em testes de integração, os dados devem ser injetados; dados explícitos nunca devem ser testados diretamente. Além disso, por ser um serviço externo ao sistema, o desenvolvedor não tem controle direto sobre o banco de dados, não podendo gerenciá-lo através do código. Quando a necessidade é realizar um teste de integração não estrito - assim denominado aqui - dever-se-ia optar por um teste E2E (End-to-End), como por exemplo na API de um backend. Este percorreria todo o caminho desde sua interface (HTTP, MQ, etc.), atravessando todas as camadas, internas e externas, incluindo o banco de dados. Ressalto que meu objetivo não é meramente expressar uma opinião, mas trazer à luz evidências discutidas amplamente por figuras renomadas como Fowler, Michael Feathers, Kent Beck e Uncle Bob. A ênfase no isolamento dos testes fundamenta-se na necessidade de que estes sejam controláveis (determinísticos), rápidos e confiáveis. A meu ver, o único argumento que justificaria o uso de banco de dados em testes é a presença de um design falho no sistema, caracterizado por um alto acoplamento entre o domínio e o banco de dados - a exemplo do que ocorre com os Active Records (repositório, entidade e adapter do banco de dados unificados em uma única estrutura). Aqui, registro minha insatisfação com 99% dos ORMs. Não à toa, muitos sistemas hoje fazem uma distinção clara e justificada entre o que é uma entidade do domínio e o que é um modelo do banco de dados, mesmo que algumas bibliotecas identifiquem o modelo como entidade. Isso gera grande confusão sobre o que realmente constitui uma entidade do domínio versus uma entidade do banco de dados. E nesse ponto temos opiniões no blog de Fowler citando exemplos sobre o assunto perante esta necessidade(Ham Vocke's The Practical Test Pyramid ). Em suma, a integridade e a eficácia dos testes de integração são comprometidas pelo uso de bancos de dados, devido à sua natureza não determinística e à dificuldade de controle. A busca por testes determinísticos, rápidos e confiáveis nos leva à conclusão de que a separação entre a lógica de negócios e a persistência de dados não é apenas uma prática recomendada, mas essencial para a sustentabilidade e escalabilidade de projetos de software. Padrões de indústria, reforçam a necessidade de abordagens mais isoladas e controláveis, pavimentando o caminho para sistemas mais robustos, manuteníveis e adaptáveis às mudanças.

[@nathanmurillodeoliveira9683]

Muito interessante seu vídeo! No caso das datas, vc disse que precisar de um mock pra retornar sempre a mesma data é uma falha de design. Nesse caso, como você faria para consertar isso?

[@RodrigoBranas]

Você pode passar por parâmetro no método, ou no construtor da classe, dessa forma você tem o controle sobre a data e não precisaria ter um Stub ou Mock. Valeu!

[@afsdab]

Qual sua visão referente ao Bigger Unit Tests? Eu assisti um meeting do Peter Schuler falando sobre achei bem interessante. Resumindo ele cobre mais camadas e os mocks/stubs ficam digamos que no ultimo componente, por exemplo não faria o stub/mock de um repositório e sim do driver do banco de dados, mas eu teria o teste de um caso de uso por inteiro batendo em todas os envolvidos.

[@andrersmatias]

No caso de agregados que fazem uso de interfaces de outras classes que serão implementadas na infra, como fazer os testes unitários uma vez que ela depende das interfaces para executar a lógica do negócio?

[@arozendojr]

No angular acho bem demorado teste unitário, mesmo usando jest. Parece que é feito o build, que não é rápido, depois realizado os teste.Não sei no react , angular é na minha opinião lento

[@RodrigoBranas]

é que no Angular você roda um teste em conjunto com algum tipo de Virtual DOM para renderizar o componente que seria renderizado no navegador, por isso é lento e isso não é um teste de unidade, pra mim já é um teste de integração

[@arozendojr]

@@RodrigoBranasCompartilhando minha experiência, Mesmo Angular com jest, escolhido pela performance "melhor", temos que adotar algumas estrategias para teste, exemplo rodar apenas um arquivo e comentar os testes que não são alvo, pós cobertura desejada, retirar os comentários e ver se algo quebrou, demorei um pouco para encontrar algo que me atenda, acho uma mini gambiarra pela ferramenta ser lenta, se tiver outras formas mais puritanas, estou acomapnado seu conteúdo