Boa tarde, acho muito legal seus vídeos. sou cego, e programador java também. é legal essa ideia de sempre compartilhar os códigos desenvolvidos nas aulas no gi. ajuda de mais a não ficar pesquisando por fora.
Estou estudando testes unitários também e gostei muito de usar o mockito, muito útil e bem bom pra entender os fundamentos de de testes. MockMvc também é bom pra fazer testes de integração
Fernanda, comecei a acompanhar seus vídeos agora, excelente conteúdo. Vou pedir um vídeo um pouco diferente: um vlog sobre como voc mantém sua saúde em dia mesmo trabalhando o dia inteiro sentada e lidando com stress. Pra mim tem sido um baita desafio. Parabéns pelo canal! ❤
Show de bola, Fernanda! A empresa que trabalho está bastante empenhada em cobrir os projetos com testes unitários e seus vídeos têm me ajudado demais. Mesmo no Spring quanto em outras tecnologias. Vc manja muito! Parabéns 👏🏻
Conteúdo excelente, seria interessante um video falando de testes em geral, pois muita gente, inclusive outros "Seniores", de onde trabalho, acham perca de tempo. Olhando assim, parece ser muito código para testar um create, ou find, sendo que você pode fazer testes na mão, ignorando total o efeito dos testes em cascata. Também seria legal falar mais sobre automatização de testes. Gostei muito do seu canal. Parabéns.
Gostei muito de estudar o Mockito com este vídeo. Com sua didática e objetividade consegui finalmente fazer algumas coisas bem legais com esta tecnologia. Depois de aprender, fui um pouco mais a fundo pois precisava mockar apenas algumas das dependências, não todas, pois queria que algumas das dependências utilizassem o objeto real. Pesquisei e acabei encontrando o @Spy do Mockito. Parabéns pelo canal !
Que legall, Ricardo. Fico feliz que tenha ajudado você 💜 Boaa! É isso aí, depois de aprendermos algo temos que nos aprofundar pra entender como aplicar aquilo no nosso contexto. Parabéns pela iniciativa! E muito obrigado pela confiança por se tornar membro 💜
Para quem está no VSCODE é importante ter a extensão "Test Runner for Java" para conseguir realizar os testes, essa ext irá criar na barra lateral esquerda um opção de testes onde será possível rodar separadamente.
Ótimo conteúdo! Dúvida de iniciante, eu preciso testar todas as classes? controllers, services, repositorys, configs, infra, utils etc.... Pelo que entendi do vídeo o que se testa são as regras de negocio e métodos que tenha algum retorno certo? não sei como estruturar os testes e o que realmente temos que testar.
É uma boa prática utilizar service dentro de service? Nesse caso, foi-se usado o userService com o método padrão da JPA (FindById), e isso facilita, porque, geralmente tratamos o retorno desse Optional no service. Mas, por curiosidade mesmo, tem problema no quesito de boas práticas? Se alguém souber, vai me ajudar bacana. 😁☕
Na maioria dos contextos isso é super comum, pois é dentro da camada service que você irá tratar as regras de negócios do domínio, como por exemplo User. Mas, não confunda. Lá você faz o tratamento e pode invocar os métodos do repositório, através da injeção de dependências mas é dentro da camada do repositório, é que você ta tratando o FindById ou qualquer outro método relacionado ao banco de dados. Dessa forma, você está garantindo uma boa prática. Bons estudos!
Boa tarde Fernanda. Muito obrigado pelo vídeo ajudou muito. Me tira uma duvida por favor? No Java tem como fazer uns teste end2end como, ocorre no node.js ex: supertest + jest. Como realizar testes o controller ?
Opa, parabéns pelo conteúdo, só não entendi muito bem a necessidade de utilizar o EntityManager para persistir o usuario no teste do repository, sendo que já estava a disposição o UserRepository, consegue clarear para mim?
Seu conteúdo é bem full Stack, duvida de front, dentro dos teste unitários, você coloca teste estruturais e de estilos, ou outro nome, tipo verificar se o form tem label, inputs, depois teste de estilhos , cor, fonte, tamanho?
Professora.... A) Pensa comigo uma coisa... Me ajuda a entender... B) Estou fazendo essa pergunta, para varios JAva Influencers do YT... C) E o seguinte: - Se mock's/Mockito permite a "manipulacao do resultado", ou seja, eu dou o resultado que eu quiser. Qual o valor de um TESTE, onde eu eu defino o "resultado que eu quero"???? (manipulacao do resultado) Por exemplo: O metodo retorna uma String..... No mock, eu determino que o resultado sera 22.22 (uma Double)... E o Mock, logicamente, "me da o resultado de 22.22". Para que serve um teste desses? Onde ao inves de ele me dar o resultado REAL(testes de integracao), ele me da um resulta "maquiado"(teste mockados)???
Então, mano, a ideia do teste unitário é testar uma pequena unidade do seu código, como um método, de forma isolada. Quando digo 'de forma isolada', refiro-me a testar sem influência de dependências externas. Para garantir que o resultado do meu teste unitário não seja afetado por dependências externas (como no exemplo do vídeo: transactionRepository, authorizationService e afins), preciso 'mockar' essas dependências, ou seja, criar implementações falsas e definir as respostas que elas fornecerão para uma entrada específica. Perceba que definimos o resultado esperado para as dependências (coisas externas), não para o método que estamos testando. Com isso em mente, vem a resposta para sua pergunta 'Para que serve um teste desses?': É simplesmente para testar a lógica única e exclusiva do método ou classe sob teste. No caso do vídeo, ao testar o método 'createTransaction' do transactionService, queremos validar, por exemplo, se a transação está autorizada. Assim, no nosso teste unitário, queremos verificar como o método 'createTransaction' se comporta em um cenário onde o método 'authorizeTransaction' do authService retorna true. Qual comportamento esperamos do método 'createTransaction' neste cenário? Esperamos que ele não lance uma exceção, persista a nova transaction no banco e atualize o sender e o receiver. Perceba que o pensamento ao criar testes unitários é: 'Como meu método se comporta nessas condições? Ele realmente faz o que eu espero em um cenário X? E em um cenário Y?', 'O método que estou testando executa o método save do repository quando determinada condição é verdadeira?', 'Ele lança uma exceção quando determinado serviço retorna false?'. Note que em nenhum momento estamos pensando em testar se o resultado de algo que a gente mockou está certo, testamos a lógica do método dado esses resultados. O objetivo dos testes de integração/componente é diferente dos testes unitários e, a depender do contexto, ainda é utilizado alguns mocks. Nos testes de integração normalmente validamos entrada e saída de determinado fluxo e não se um método X foi executado em uma condição y. Ter somente testes unitários não garante a qualidade do software, nem assegura que nosso software funcione como deveria. Da mesma forma, ter somente testes de integração/componente também não oferece essa garantia. Por isso, em um sistema, realizamos vários tipos de testes: testes unitários, testes de integração/componente, testes E2E, testes de fumaça, testes de regressão e testes de performance. Tudo isso é apresentado pela literatura em uma pirâmide de testes que mede o custo e a eficiência de cada tipo de teste. Espero que eu não tenha sido redundante e tenha tirado sua dúvida. Se precisar de ajuda estamos ai
Em palavras resumidas, inclusive para quem ler sua pergunta, quando você cria um teste unitário para cobrir seu método, você tá garantindo através do Junit que aquele método dentro da sua aplicação terá o resultado ou a devida exceção para qual ela foi elaborada. Isto é, quando você trás os resultados mockados e faz o teste, o entendimento é que o teste traga o valor mockado que você definiu e compara (simula) se é o mesmo retorno do método que você tem na aplicação.
Oii, @jonataswf. Tudo bem? Eu basicamente estudei com tutoriais no RUclips, documentação e no próprio trabalho. Mas hoje, a Rocketseat, plataforma que eu me especializei em React, lancou a trilha de Java e ela á muuuito boa. www.rocketseat.com.br/one?KIPPERDEV-none-none-none-none-redes_kipperdev&referral=kipperdev&coupon=KIPPERDEV
Oi fer, tudo bem? Uma dúvida, porque vc colocou no TransactionServiceTests o @Autowired e @InjectMocks no TransactionService? Só o @InjectMocks não é suficiente?
![I.N "HALLUCINATION" | [Stray Kids : SKZ-PLAYER]](http://i.ytimg.com/vi/n5B5q1Hwt_U/mqdefault.jpg)
👉 TORNE-SE UM ESPECIALISTA EM JAVA! (10% OFF)
tr.ee/kipperdev-desconto-rocketseat-one
Boa tarde, acho muito legal seus vídeos. sou cego, e programador java também. é legal essa ideia de sempre compartilhar os códigos desenvolvidos nas aulas no gi. ajuda de mais a não ficar pesquisando por fora.
Concordo
Oii Joao, muito obrigada, fico feliz que gosta dos videos!
E sim, sempre tento compartilhar o link do Github para auxiliar nos estudos também 😊
Estou estudando testes unitários também e gostei muito de usar o mockito, muito útil e bem bom pra entender os fundamentos de de testes. MockMvc também é bom pra fazer testes de integração
Fê, valeu por compartilhar conhecimento, esse video deu vários insights para otimizar alguns códigos por aqui!!
Que showw, @FacesMaker 💜
Tomara que melhore as suas aplicações!
Fernanda, comecei a acompanhar seus vídeos agora, excelente conteúdo. Vou pedir um vídeo um pouco diferente: um vlog sobre como voc mantém sua saúde em dia mesmo trabalhando o dia inteiro sentada e lidando com stress. Pra mim tem sido um baita desafio. Parabéns pelo canal! ❤
TOP! sentia falta de Junit no canal... quem sabe agora vem um de circuit breaker, docker, SOLID 💖
👀...
Fernanda Muito obrigado! Você de fato me ajudou a compreender o que são os mock e a diferença para o injectmock! Que didática! Sucesso!
obrigado por isso! sua didática é foda, estou evoluindo demais com seus vídeos!
muito bom, Kipper. Vlw pela aula!
Show de bola, Fernanda! A empresa que trabalho está bastante empenhada em cobrir os projetos com testes unitários e seus vídeos têm me ajudado demais. Mesmo no Spring quanto em outras tecnologias.
Vc manja muito! Parabéns 👏🏻
tava precisando desse conteudo! valeu Fe 💓💓
hahah só eu fiquei olhando pro espelho
Conteúdo excelente, seria interessante um video falando de testes em geral, pois muita gente, inclusive outros "Seniores", de onde trabalho, acham perca de tempo. Olhando assim, parece ser muito código para testar um create, ou find, sendo que você pode fazer testes na mão, ignorando total o efeito dos testes em cascata. Também seria legal falar mais sobre automatização de testes.
Gostei muito do seu canal. Parabéns.
Gostei muito de estudar o Mockito com este vídeo. Com sua didática e objetividade consegui finalmente fazer algumas coisas bem legais com esta tecnologia. Depois de aprender, fui um pouco mais a fundo pois precisava mockar apenas algumas das dependências, não todas, pois queria que algumas das dependências utilizassem o objeto real. Pesquisei e acabei encontrando o @Spy do Mockito. Parabéns pelo canal !
Que legall, Ricardo.
Fico feliz que tenha ajudado você 💜
Boaa! É isso aí, depois de aprendermos algo temos que nos aprofundar pra entender como aplicar aquilo no nosso contexto. Parabéns pela iniciativa!
E muito obrigado pela confiança por se tornar membro 💜
Conteúdo top! Faz um vídeo mostrando testes de integração, por favor!
Muito obrigadaa, Adam 💜
Boa! Vou trazer um vídeo assim!
gostei muito dos conteudos que você entrega são muito bem explicados
👏
38:17 tem que passar todas informações do objeto? não tem como mockar o que não importa e passar apenas o que precisa?
Essa menina é dms meu orgulho
Para quem está no VSCODE é importante ter a extensão "Test Runner for Java" para conseguir realizar os testes, essa ext irá criar na barra lateral esquerda um opção de testes onde será possível rodar separadamente.
Boaa, ótima dica!
que aula insana fer, keep it up!
Muito obrigadaa, @alexandrepellegrino2699 💜
Foda dms esses 2k pra fazer o curso de java da rocketseat, convenhamos, tá um preço bem salgado pra quem é iniciante e n tem nem grana direito
Ótimo conteúdo! Dúvida de iniciante, eu preciso testar todas as classes? controllers, services, repositorys, configs, infra, utils etc.... Pelo que entendi do vídeo o que se testa são as regras de negocio e métodos que tenha algum retorno certo? não sei como estruturar os testes e o que realmente temos que testar.
É uma boa prática utilizar service dentro de service?
Nesse caso, foi-se usado o userService com o método padrão da JPA (FindById), e isso facilita, porque, geralmente tratamos o retorno desse Optional no service. Mas, por curiosidade mesmo, tem problema no quesito de boas práticas?
Se alguém souber, vai me ajudar bacana. 😁☕
Na maioria dos contextos isso é super comum, pois é dentro da camada service que você irá tratar as regras de negócios do domínio, como por exemplo User. Mas, não confunda. Lá você faz o tratamento e pode invocar os métodos do repositório, através da injeção de dependências mas é dentro da camada do repositório, é que você ta tratando o FindById ou qualquer outro método relacionado ao banco de dados. Dessa forma, você está garantindo uma boa prática. Bons estudos!
Vídeo perfeito! Tem algum sobre teste de integração também?
eu to apaixonado, porem didatica mt boa
Boa tarde Fernanda. Muito obrigado pelo vídeo ajudou muito. Me tira uma duvida por favor? No Java tem como fazer uns teste end2end como, ocorre no node.js ex: supertest + jest. Como realizar testes o controller ?
Valeu por compartilhar @kipperdev bom fim de semana!
Obrigadaa Lipe! Para você também
Ótima aula
Agora sim hein Fê!!!
Video muito bom, pena que quando fui testar meu repositorio não recuperou nada no meu banco nem gravou o registro
Opa, parabéns pelo conteúdo, só não entendi muito bem a necessidade de utilizar o EntityManager para persistir o usuario no teste do repository, sendo que já estava a disposição o UserRepository, consegue clarear para mim?
Seu conteúdo é bem full Stack, duvida de front, dentro dos teste unitários, você coloca teste estruturais e de estilos, ou outro nome, tipo verificar se o form tem label, inputs, depois teste de estilhos , cor, fonte, tamanho?
qual plugin theme vc usa que parece o eclipse?
Professora....
A) Pensa comigo uma coisa... Me ajuda a entender...
B) Estou fazendo essa pergunta, para varios JAva Influencers do YT...
C) E o seguinte:
- Se mock's/Mockito permite a "manipulacao do resultado", ou seja, eu dou o resultado que eu quiser.
Qual o valor de um TESTE, onde eu eu defino o "resultado que eu quero"???? (manipulacao do resultado)
Por exemplo:
O metodo retorna uma String..... No mock, eu determino que o resultado sera 22.22 (uma Double)...
E o Mock, logicamente, "me da o resultado de 22.22".
Para que serve um teste desses?
Onde ao inves de ele me dar o resultado REAL(testes de integracao), ele me da um resulta "maquiado"(teste mockados)???
Então, mano, a ideia do teste unitário é testar uma pequena unidade do seu código, como um método, de forma isolada. Quando digo 'de forma isolada', refiro-me a testar sem influência de dependências externas. Para garantir que o resultado do meu teste unitário não seja afetado por dependências externas (como no exemplo do vídeo: transactionRepository, authorizationService e afins), preciso 'mockar' essas dependências, ou seja, criar implementações falsas e definir as respostas que elas fornecerão para uma entrada específica. Perceba que definimos o resultado esperado para as dependências (coisas externas), não para o método que estamos testando.
Com isso em mente, vem a resposta para sua pergunta 'Para que serve um teste desses?': É simplesmente para testar a lógica única e exclusiva do método ou classe sob teste. No caso do vídeo, ao testar o método 'createTransaction' do transactionService, queremos validar, por exemplo, se a transação está autorizada. Assim, no nosso teste unitário, queremos verificar como o método 'createTransaction' se comporta em um cenário onde o método 'authorizeTransaction' do authService retorna true. Qual comportamento esperamos do método 'createTransaction' neste cenário? Esperamos que ele não lance uma exceção, persista a nova transaction no banco e atualize o sender e o receiver.
Perceba que o pensamento ao criar testes unitários é: 'Como meu método se comporta nessas condições? Ele realmente faz o que eu espero em um cenário X? E em um cenário Y?', 'O método que estou testando executa o método save do repository quando determinada condição é verdadeira?', 'Ele lança uma exceção quando determinado serviço retorna false?'. Note que em nenhum momento estamos pensando em testar se o resultado de algo que a gente mockou está certo, testamos a lógica do método dado esses resultados.
O objetivo dos testes de integração/componente é diferente dos testes unitários e, a depender do contexto, ainda é utilizado alguns mocks. Nos testes de integração normalmente validamos entrada e saída de determinado fluxo e não se um método X foi executado em uma condição y.
Ter somente testes unitários não garante a qualidade do software, nem assegura que nosso software funcione como deveria. Da mesma forma, ter somente testes de integração/componente também não oferece essa garantia. Por isso, em um sistema, realizamos vários tipos de testes: testes unitários, testes de integração/componente, testes E2E, testes de fumaça, testes de regressão e testes de performance. Tudo isso é apresentado pela literatura em uma pirâmide de testes que mede o custo e a eficiência de cada tipo de teste.
Espero que eu não tenha sido redundante e tenha tirado sua dúvida. Se precisar de ajuda estamos ai
Em palavras resumidas, inclusive para quem ler sua pergunta, quando você cria um teste unitário para cobrir seu método, você tá garantindo através do Junit que aquele método dentro da sua aplicação terá o resultado ou a devida exceção para qual ela foi elaborada. Isto é, quando você trás os resultados mockados e faz o teste, o entendimento é que o teste traga o valor mockado que você definiu e compara (simula) se é o mesmo retorno do método que você tem na aplicação.
muito bom!
Qual curso você fez para aprender java, spring boot e testes unitarios?
Oii, @jonataswf. Tudo bem?
Eu basicamente estudei com tutoriais no RUclips, documentação e no próprio trabalho.
Mas hoje, a Rocketseat, plataforma que eu me especializei em React, lancou a trilha de Java e ela á muuuito boa.
www.rocketseat.com.br/one?KIPPERDEV-none-none-none-none-redes_kipperdev&referral=kipperdev&coupon=KIPPERDEV
Muito obg..
Fazer os testes parece mais complicado do que criar a aplicação e testar na prática
maravilhoso, como sempre!
ps: repository tem a tônica em reposi"to"ry. Fica repositóry
Valeuu Daniel! 😃
Não seria rePÓsitory?
usa o app do tradutor e faz ele falar pra você ouvir direitinho como pronuncia 😁
@@danieldamacena5197 entao, o translater fala "repÓsitory" e nao repositóry kkk, é leviOsa e nao leviosá
@@alexandrepellegrino2699 translator, você diz, né? aqui eu ouço repósitóri. Coloquei agudo no primeiro o porque ele soa aberto
Essa menina é demais. Uma coisa que não vem ao caso (só curiosidade), você em algum momento já foi hiperativa?
Mannnns...
First
deirabeise... rum... aulinha de inglês é? 😬
Oi fer, tudo bem? Uma dúvida, porque vc colocou no TransactionServiceTests o @Autowired e @InjectMocks no TransactionService? Só o @InjectMocks não é suficiente?