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

Fala galera no vídeo de hoje eu vou falar sobre a diferença entre testes de unidade e de integração e se testes de unidade podem ter mooc essa pergunta do Vinícius bonim e foi enviada lá pelo Instagram Aliás se você não me segue o link tá aqui na descrição e semanalmente eu vou abrir essa caixa de perguntas para que vocês possam mandar os temas dos próximos vídeos não só sobre testes automatizados mas também sobre domain driven design Clean architecture zonal Solid principles design patterns e muito mais tá Ah bom primeira coisa que eu queria dizer é

que quando a gente pensa em testes sempre tem que vir à mente a ideia da pirâmide em que a base é mais larga e tem em maior quantidade os testes de unidade que são mais rápidos porém menos abrangentes que que eu quero dizer com isso o teu sistema numa condição real de uso ele vai interagir com recurso externo ele vai interagir com o banco de dados ele vai interagir com uma epi externa eventualmente você vai ter alguma interação com file System então se você só tem testes de unidade você vai ter cobertura muitas vezes eh

de boa parte desse código já vou discutir a a noção de unidade tá só que isso não vai garantir que o teu sistema de fato funciona ou que ele não vai ter regressão ah ou que você não vai ter um impacto muitas vezes numa query que você altera e que pode sim introduzir eh algum defeito e muitas vezes grave então o teste de unidade ele é tão importante quanto o teste de integração A diferença é que você muitas vezes vai ter esse teste em maior quantidade enquanto Conforme você sobe os níveis da pirâmide você tem

testes de integração em menor quantidade testes end to end em menor quantidade ainda por quê Porque são testes mais lentos mais caros mas muitas vezes ã difíceis de serem implementados às vezes mais frágeis com conceitos menos estáveis mas todos os testes são relevantes eu sempre digo o seguinte só testa aquilo que você quiser ter certeza que funciona Tá bom o que você não precisar ter certeza que funciona você não precisa testar tá a única forma que você tem como assim garantir que aquele código que você escreve funciona é com teste automatizado Ah mas eu faço

o teste manual tudo bem mas o seu có muda e ele muda bastante outras pessoas mudam o seu código no momento em que elas mudam você precisa fazer todos os testes manuais de novo isso vira uma grande bola de neve você não consegue sustentar a realização de todos os testes manuais o tempo inteiro por diversos motivos inclusive escrevi um artigo lá no meu blog vou deixar o link aqui na descrição também falando sobre a importância dos Testes automatizados e e o que que faz com que teste manual não seja de fato escalável no dia a

dia não só escalável mais viável até tá conforme eh a quantidade de código aumenta você cada vez mais vai ter dificuldade em testar tudo né então o teste de unidade ele vai exercitar uma parte do código que é independente e desacoplada de recursos externos então ah isso vai se aplicar principalmente em Sistemas que adotam uma coisa chamada de domain Model tá isso vem desse livro que é o mar e basicamente Você tem dois caminhos duas estratégias de design transaction script e o domain Model o domain Model tem mais a ver com orientação objeto onde você

junta tá comportamento e dados preservando o estado interno por meio do encapsulamento para isso que servem aqueles modificadores de visibilidade como Private Protect n não deixar que exista ento com os detalhes enquanto você expõe determinados comportamentos que fazem sentido Ah isso faz com que você consiga distribuir bem complexidade em uma grande quantidade de objetos diferentes é a proposta inclusive de domain driven design quando a gente pensa nos objetos de domínio nos aggregates nas entities nos value objects E aí você tem um sistema ã Sem dúvida nenhuma muito mais reusável mais manuten mais estável sobre ponto

de vista de comportamento ã só que requer mais maturidade para que seja implementado outro caminho é o que a gente chama aqui de transaction script que é quando eu tenho um domínio anêmico isso não é pejorativa simplesmente uma estratégia de design Ah e eu junto no mesmo bloco de código as regras de negócio e a interação com recursos Não Existe uma separação entre essas coisas né né E aí você vê aquele fenômeno de um service que chama outro service que chama outro service e volta pro primeiro e aí você começa a a a talvez misturar

demais as responsabilidades e isso faz com que você tenha mais dificuldade para testar nesse caso somente por testes de integração Mas voltando aos testes de unidade né então nos sistemas que adotam Clean architecture domain driven design que tem algum tipo de cam de domínio Lembrando que que a arquitetura exagonal não prevê necessariamente uma camada de domínio Então tá muito mais pro DDD e pro pro cinar né E aí você tem essas regras então Independentes Ah eu tenho o cálculo da distância entre duas coordenadas eu tenho o o de repente as regras de mudança de estado

de um pedido eu tenho validação de determinados Campos como um CPF ou um CNPJ tudo isso São Regras Independentes você vai ter testes de unid nessas regras com uma grande quantidade de cenários Você já pensou a quantidade de cenários para um teste de um simples CPF tem vários cenários ali tem CPF com o dígito errado você tem CPF com menos caracteres com mais caracteres você passa uma string vazia você passa um nul você tem vários cenários possíveis dentro dos cpfs ainda Inválidos você vai ter CPF em que todos os dígitos são iguais Considerando o dígito

verificador Você pode ter o zero e e um número diferente de zero né um número diferente de zero e zero zero e zero você muda a regra de negócio então assim você vai exercitar uma grande quantidade de cenários diferentes quando a gente pensa num nível de unidade porque eles são muito rápidos Quando você vai para um teste de integração você já tá subindo na pirâmide aí poxa mas o que que é um teste de integração é mais nebuloso o conceito porque normalmente você tem a integração entre mais de uma camada entre mais de uma responsabilidade

e não quer dizer que sejam só duas quando a gente pensa eman architecture você tem a camada de US cases que é responsável por orquestrar regras de negócio independente que são as entidades né conforme o Robert Martin chama mas também os recursos externos por exemplo por meio de um repository de um Gateway então Ali você vai ter Sem dúvida nenhuma um teste de integração você tem essas responsabilidades diferentes sendo exercitadas mas nada impede que você você vá mais para fora ada de interface adapters por exemplo onde você tem lá um um http Controller e você

teste diretamente nele ele exercite o US case e também as entidades pregue sendo um teste de integração então repare que o teste de integração ele normalmente vai abranger mais de uma camada mas não necessariamente duas podem ser três quatro Depende de como você estruturou o design da tua aplicação então eles vão funcionar bem em conjunto existem partes do sistema que só vão conseguir ser testadas com testes de integração e outras com testes de unidade e é justamente a junção deles que faz com que você tenha abrangência essa palavra chave aqui principal talvez é ter a

abrangência necessária para que você possa garantir que aquilo que você implementou funciona e segue funcionando agora quando a gente fala em Moc que foi a segunda pergunta do Vinícius né testes de unidade podem ter Mox testes de unidade na minha visão não precisam ter Mox porque você não tem o que mocar quando a gente fala em mock é maneira de falar Pode ser um stub pode ser um mock pode ser um fake Pode ser algum outro tipo de test double test pattern depois a gente pode ter um vídeo discutindo somente essas diferenças né entre cada

um cada um deles Tá mas salvo que você tenha de repente alguma deficiência de design Quando eu digo isso assim por exemplo você tem uma data sendo definida dentro de uma determinada regra independente isso vai te levar a precisar de um stub para que você possa arbitrar aquela data e fazer com que esse teste seja repetível tá então lembra que um conceito muito importante de test chama test first first vem de fast Independent repeatable S valida e timely o repeatable é muito importante se eu rodar 10 vezes o teste ele tem que dar 10 vezes

o mesmo resultado se eu tenho um New date dentro de um de uma mudança de estado de uma entidade eu não tenho controle sobre essa data aí indica um problema de design que pode ser suprido por um stub que é basicamente a sobrescrita deste comportamento é como se o new date voltasse sempre a mesma data porque você fez com que isso acontecesse por meio do stub mas não é muito normal ter essa necessidade indica uma deficiência de design agora no nível de integração é perfeitamente aceitável e comum que você tenha ah a necessidade de contar

com esses recursos porque veja bem você vai fazer um sistema de e-commerce que tem produtos em dólar para fazer o checkout em real você tem que saber a cotação do dólar só que ela muda a cada minuto Então você usa um Gateway para que você possa acessar uma API externa que te retorna a cotação bom se eu rodar 10 vezes o teste vai dar 10 vezes valores diferentes porque a cotação mudou então é fundamental nesse caso que você por exemplo use um mooc para que você defina olha sempre que eu eh fizer o checkout a

cotação do dólar deve retornar três ou quatro ou cinco e assim eu consigo ter a garantia que esse teste vai retornar sempre o mesmo valor então no nível de unidade não não foi a pergunta do Vinícius nesse caso mas no nível de de unidade não de integração é fundamental contar com esse tipo de recurso é normal Ah mas eu eu faria isso no banco de dados não na minha visão não por qu Porque para mim quando eu tô fazendo um teste de Integração eu quero exercitar o banco de dados não precisa ser o banco de

produção não deve ser o banco de produção porque é um banco normalmente muito grande com uma indexação mais complexa normalmente mais lento para diversas operações Mas você pode ter um banco em memória um banco Limpo você tem várias outras opções para isso pode fazer um pipeline de de continuous delivery que traga uma imagem do banco e carregue e rode o teste mas para mim para que eu tenha abrangência fundamental Que recursos como o banco de dados sejam testados no nível de integração é a minha opinião agora api externas Ah eu vou fazer de repente a

uma transação num Gate de pagamento não dá você pode sim ter um teste ã que você vai garantir o contrato com este Gateway quando você principalmente homologa h de repente uma nova conta para que você Execute uma transação veja o resultado depois cancele Mas isso não é viável para rodar testes no dia a dia você faz 10 deploys num dia você não vai rodar 10 vezes uma transação e cancelar essa transação você vai ter problemas daqui a pouco com esse GAT né além de custar pelo menos a taxa de processamento do do da transação então

a diferença de testes de unidade integração É exatamente esse nível de abstração enquanto unidade exercita algo Independente de recursos integração normalmente exercita algo dependente de recursos Lembrando que você pode ter níveis diferentes de integração você pode exercitar duas três quatro camadas vai depender um pouco é extremamente desejável que você conheça os test patterns e aplique nos cenários onde faça sentido principalmente os stubs né e não vejo necessidade de usar stubs em testes de unidade salvo em problemas de design como o caso da data que eu acabei de falar para vocês tá então H esse assunto

de teste eu abordo bastante lá no meu meu curso Ah eu vou deixar o link aqui na descrição A cada dois meses eu abro as inscrições pro curso de Clean cod de Clean architecture onde eu vou des do Clean code passando por refactory test driven development que praticamente Eu uso o tempo inteiro né arquitetura exagonal Clean architecture domain driven design Solid principles design patterns microservices C krs e arquitetura entada de eventos então durante oo semanas a gente tem essa experiência juntos ao vivo tirando dúvida e a gente mergulha muito nesse assunto então se tem interesse

clica aqui no link da descrição deixa o teu nome e-mail que eu vou te avisar assim que as inscrições forem abertas vai que você tá vendo esse vídeo num momento em que a inscrição tá aberta mas Senão deixa teu númer e-mail que eu vou te avisar assim que abrir tá bom Espero que tenha gostado do vídeo eh mandem perguntas lá pelo Instagram porque eu vou filtrar essas perguntas e vou trazer aqui num vídeo Possivelmente semanal Tá bom então te espero e a táa alo