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.

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

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.

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?

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?

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?

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.

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