Olá, sejam todos muito bem-vindos a mais uma aula. E bom, a gente andou trabalhando aqui nos casos de uso, a gente finalizou todos, tiramos todos os comportamentos, todos os casos de uso, as regras de negócio que estavam nos controllers, passamos para classes isoladas, passamos para classes que expressam o que o caso de uso faz, implementa o padrão command. Está tomando cara, a arquitetura está tomando cara. Agora, para finalizar essa parte 1 dos casos de uso, a gente vai fazer os testes. Vamos fazer os testes, afinal, essa é uma das maiores vantagens que a gente tem, principalmente ao trabalhar com uma arquitetura bem planejada, com uma arquitetura que diz sobre aquilo que você está fazendo, uma arquitetura que faz sentido para o projeto de maneira geral. Então vamos lá, Alt Inserterte na verdade um primeiro ano os carros de uso e aí vai ficar mais fácil que esse caso já tem que ir em isquêis uma creche testes ele já vai criar para a gente lá em baixo que a gente vamos ver como que tal e, o que que ele tem aqui de teste. Tem o teste create e tem o teste de reservar um ticket. Legal, então vamos fazer o seguinte, vou copiar isso aqui, createEvent, e aí tudo que é mockMVC vai pra vala, não vamos utilizar. utilizar a gente vai utilizar aquela estrutura que a gente já sabe, given when then event.dto, isso na verdade o event.dto ele era o que era esperado antes agora não é mais então agora a gente tem o new Create event use case .input Ele recebe a data O nome, o partner id e total spots Então vamos lá Final var Expected date Vamos copiar essa data aqui Final var Expected name E aíney on ice sei la onde eu tirei finalvar expectedPartnerId igual a... vamos fazer igual a gente estava fazendo lá, random... Ah, inclusive a gente tem até ali do tsid, né? Pode até usar o tsid, ó. Fast too long. Beleza. Então, isso aqui vai pra vala a gente não vai precisar a gente pode passar aqui agora a data quais eram os próximos quero o name acho que era o partner.id e aí o total spots beleza final var create input a gente pode quebrar uma linha beleza finalvar create-input a gente pode quebrar mania beleza vamos instanciar então aqui o nosso new create-event-use-keys ele recebe event-service e o partner-service o event-service mockito, vamos com o mock event-, finalvar eventService e finalvar partnerService.class Beleza. Agora a gente pode passar para cá, os dois caras. Então a gente tem o nosso caso de uso aqui que a gente já consegue utilizar. Então useCase.execute, createInput e aí ele vai dar um output. create input e aí ele vai dar um output só que antes disso a gente sabe que a gente tem dependências aqui então o find by id e o save, vamos lá, moquito.when, cadê, eventservice.save e aí vamos só usar o auto import aqui pra que depois a gente use aqui também then answer é a e a gente vai pegar aqui o a.getFirst que é um evento event.class é um evento event.class final var e nomenclatura tá boa, né? mas ok set id cadê? ts id fast e aí return e, beleza, mocamos o event, agora a gente precisa mocar o é quer dizer é equê expected partner ativ, poderia ter feito até sem o equê mas ok e aí retorna o partner o partner não existe aqui ainda então vamos criá-lo final var na verdade é Disney vamos colocar o nome de Disney. NewPartner. Ah, e verdade, né? Mas ok. No fim das contas, não vai fazer diferença aqui. Mas vamos colocar, né? Nem precisava ter essa variável porque a gente poderia passar um newPartner ali direto. Vai, vamos retornar aqui direto. Beleza, output e agora a gente vai verificar. Expected name, name, expected total spots, actual spots, e ai tem o expected date que eu pulei aqui, date, e o ultimo é o id, id e tem o partner id também né, então o id na verdade é assert not nulo e aí a gente move ele lá para cima e agora por último tem o partner expected partner id partner beleza vamos rodar aqui ó Beleza, vamos rodar aqui, ó. Vamos rodar e aí a gente já garante unitariamente o comportamento do nosso CreateUseCase. Agora a gente, vamos aqui, ó, vamos verificar a branching que a gente criou aqui, ó. Isso aqui é uma branching, né. Então vamos, vamos testar. vamos testar é não deve criar um evento quando o partner não for encontrado partner doesn't exist should throw error então ele não vai chegar no save, vai ser primeiro o findById mas é aqui que eu vou ajustar a order para a ordem correta e aqui ele vai retornar um empty beleza, aqui instanciou, aqui assert throws, assert, assert aos assert throws, validation e colocando, actual exception, e a gente cria aqui o nosso querido expected error, e aí vamos devolver aqui esse erro, então, vala, vala, e aqui expected error, get message, e aí só pra lembrar que eu já nem sei que eu já nem lembro qual é a validação que a gente colocou aqui beleza então vamos ver, vamos rodar esse teste também então createEventTest coberto, agora a gente pode ir pro, vamos fazer o seguinte vamos pra um fácil, vamos copiar o do createCustomer e aí vou chamá-lo de partner só pra otimizar E vamos fazer o seguinte, vamos para um fácil, vamos copiar o do createCustomer. E aí vou chamá-lo de partner só para otimizar. O importante é o conteúdo que você está absorvendo, que você já absorveu, não sei se você já fez. A partir de agora vai ser basicamente a mesma coisa. Então deve criar um parceiro. E aí eu vou renomear aqui ó tudo que é customer out j tudo que é customer da partner vamos lá, vamos corrigir cpf na verdade é um .f6 aqui cnpj vamos lá no teste do partner vamos ver se tem algum cnpj aqui tem um cnpj aqui, cnpj de teste create papapá e aqui é o cnpj não deve criar um parceiro com o CNPJ duplicado vou renomear esse cara CNPJ CNPJ ali eu arrumei, ali não precisou, beleza, find by cnpj também criei parque de jota papapá expecta de cnpj retornou e aí depois parta da hora que se beleza não deve criar um parceiro com e mail duplicado cnpj cnpj é isso rodar os testes beleza tudo passando perfeito então do partner foi fácil com esse copy copy paste maroto agora vamos usar o do getbyid fazer a mesma coisa get Agora vamos mudar o GetById e fazer a mesma coisa. Get. Parther. ById. UseCase. Obter 1. Tudo que é cliente eu vou mudar para parceiro. Tudo que é expected CPF eu já mudo para CNPJ. Esse cara aqui. Depois eu copio CNPJJ E aí tudo que é Customer aqui Já mudo pra Partner Set CNPJ CNPJ CNPJ CNPJ Deve obter vazio Ao tentar recuperar um parceiro que não existe Que não existente Não, que não existe Ah, um parceiro que não existe que não existente não, que não existe ah, um parceiro não existente, beleza, por aí de customer service, não tem customer service é partner service beleza, só faltou corrigir os CNPJ ali que tá um que tá um CPF. Quer dizer, que está um erro, né? Que está qualquer coisa. Vou executar esse teste. Também passou. E aí por último sobrou o subscribe event. Subscribe event. Vamos lá, vamos criar um teste para ele. Criar um teste aqui, beleza vamos ver como está o teste lá no o teste integrado tá, beleza tá beleza vamos lá subscreve transaxial não precisamos de transaxial deve comprar um ticket de um evento teste reserve ticket event.io tá chamando aqui um tá criando um evento pra depois chamar o subscribe. Ok, no fim a gente não vai aproveitar nada disso. Vamos fazer o seguinte, ó. Vamos começar. Given when then. Beleza. Vamos primeiro colocar aqui, ó, quem que é o use case que a gente tá mirando. Então, igual a new, subscribe, event useCase. A gente precisa do customerService e do eventService. Eu acho que eu já deveria ter mudado para repository, corrigido essa layer, porque depois a gente vai ter que vir aqui em cada teste e ir alterando, né? Mas tudo bem, faz parte. Eu acho que é legal para a gente ver até a maturidade dos testes, então na verdade mock event service final var event service e aí a gente tem o customer service, então mock customer service. Final var, customer service. Beleza, então vamos passar para cá e a gente já tem o nosso use case pronto para ser usado. Show de bola. Agora, execute new input vamos criar esse input aqui para esse input a gente precisa de um new subscribe use case ponto input que precisa do event id e do customer id, então vamos fazer o seguinte, vamos criar o event e o customer. O customer é fácil, porque a gente já tem ele aqui em outros casos de uso. Então, getCustomerBy beleza então a gente já tem um customer aqui agora a gente precisa de um event também finalvar, eu falo event mas é event né, event, e aí o event, vamos lá, set id, vamos pegar um aí, a gente tá usando até esse aqui, mas a gente já tava usando o outro né, tseg, fast.toLong, que é mais interessante porque lá pode ter um valor negativo e ele meio que não faz muito sentido. Event.setName Disney. Agora, vamos ver,vent.setTickets Na real é o seguinte, a gente nem precisa mocar tanta coisa, não vai fazer muita diferença agora Agora o que a gente vai fazer? Então, a gente precisa basicamente aqui do acustomer.getId e aevent.getId Só confirmar se essa é a ordem ah não, primeiro evento depois customer vamos mudar aqui pra customer beleza tá bom voltando aqui, então customer, beleza, então já temos o final var subscribe input ok podemos passar por esse cara, a gente vai ter aqui então o final var output só que a gente precisa mocar então vamos adicionar o auto import aqui status import para fazer o import do WAN. CustomerService.findById igual... Esses caras a gente vai usar com uma certa frequência. Então, deixa eu extrair para a variável. Deixa eu extrair esse aqui para uma variável. Então, é... CustomerId... deixa eu extrair esse aqui para uma variável, então é customerId finalVar, e aí eu vou duplicar que vai ser o eventId então customerId aqui, eventid aqui e aqui é o customerid e aí a gente vai retornar then return customer quer dizer um optional de customer show de bola e aí a gente tem que também retcar o do evento, né? Então, eventService.findById, eventId, optional, event. Deixa eu ver aqui como é que tá, ó. Customer event, ah, tem esse aqui pra ser mocado também. Vamos lá, então, esse para event e para customer, e a gente vai retornar um empty porque ele não vai ter o que mais? total spots event ticket size então o ticket size se eu não me engano ele é ele já inicia como uma lista vazia então isso vai passar não tem problema depois ele vai estanciar, adicionar, salvar ok o que a gente pode fazer de verificação extra aqui tá? A gente pode, cadê, aqui no método save a gente pode capturar, na verdade a gente pode adicionar uma verificação extra no método save que é o seguinte when event save n then answer e aí aqui vai vir o parâmetro, certo? então a.get0 E ele é do tipo event class A gente já conhece var e Ruim, né? Mas vou deixar aí A gente pode adicionar A gente deve adicionar um assertions aqui assert true e.gettickets.size Na verdade, nem é um assert true true e.getTickets.size na verdade nem é um assertor, é um assert equals e aí depois a gente retorna e e aqui ponto vírgula esse 1, número mágico a gente pode colocar aqui, ó. Final var expected tickets size igual a 1. Tickets size. Só pra não ficar esse número mágico aqui voando, né? Beleza, agora a gente tem o output e aí não tem muito segredo, né? Então assertions, assert equals Output.eventId Que é igual ao EventId Que é mais ReservationDate Cadê o ReservationDate? A gente A gente, cadê? Ah, é a data ReservationDate a gente não tem gente não tenha certinho é uma data nova e aí por último o tiquete status que é a série e com a gente espera que seja o ticket status ponto pengem ponto nem de bola status.pengen.name Ficou de bola, vamos rodar esse teste? Deve comprar um ticket de um evento, alguma coisa falhou, vale event sold out A gente não colocou aqui, quantidade slots total slots, 1 por 10 número mágico aqui, mas esse aqui não importa muito. Beleza, então passou. Cenário feliz passou. A gente pode adicionar aqui os outros cenários. Fique à vontade pra explorar ou vamos fazer junto? Vamos ver quais outros cenários tem aqui. Nossa, tem um monte, né? Então vamos lá, vamos fazer rapidinho antes da gente passar porque a gente ainda precisava criar o GraphQL né, vamos lá, cadê, deve, melhor, não deve comprar um ticket de um evento que não existe test reserve ticket without event a diferença é que aqui no findById do event a gente vai retornar optional então esses caras aqui nem vai chegar o customer a gente vai tornar opcional então esses caras aqui nem vai chegar o customer a gente vai retornar event não vai existir expected equals, erro, e esse aqui é na verdade um assertions, assertTruths, validationEx reception, beleza, actual reception, pronto, get message, fechou. Então, cenário infeliz, testado, a customer, esse cara aqui, na real, a gente fez toda essa maraputaia aqui, mas agora que eu acabei de me dar conta cara aqui na real a gente fez toda essa maraputaia aqui mas agora que eu acabei de me dar conta que na verdade a gente nem usa o customer né, a gente só precisa disso aqui, ou a gente usa o customer, cadê, e customer a gente até seta aqui no customer né mas seta porque tá com essa modelagem padrão mas na verdade nem precisava na real o que importa é o event então vamos deixar assim já a gente seta um customer aqui mesmo só pra ter um resultado no optional agora não deve comprar um ticket de um evento não existente agora a gente vai fazer então com um customer não deve comprar um ticket de um evento não existente. Agora a gente vai fazer com um customer. Não deve comprar um ticket com um cliente não existente. Without customer. Customer not found. Be aí agora a gente vai retornar a empty nesse aqui ó e esse aqui nem precisa mocar show de bola agora a gente pode fazer um teste pra esse isso né então vamos lá copiar esses aqui de novo não deve comprar um ticket a tal era verdade vamos dar aqui ó um mesmo cliente não pode comprar mais de uma vez então ele vai ter basicamente aqui um erro qual que é o erro, vamos lá ver e-mail already registered a gente tem o evento ok, papapá a diferença é que não vai ter esse cara e esse aqui vai retornar um ticket, a gente já a diferença é que não vai ter esse cara e esse aqui vai retornar um um ticket, né, a gente já tem uma instância de ticket aqui, não temos uma instância de ticket na verdade eu vou dar um new ticket aqui mesmo, um ticketão e aí aqui é a mesma coisa, basicamente é isso aqui ae e por últimoimo na verdade temos essa regra aqui já estava me esquecendo dela vamos fazer assim copiar isso aqui só que agora esse aqui do ticket vai continuar retornando empty a diferença é que aqui total spots de 0 colocar 0 aqui não pode nenhum, vamos fingir que não abriu ainda e aí deve retornar a exception de event sold out um cliente não pode comprar de um evento que não há mais cadeiras. Teste de judeo, without slots. Beleza, vou mandar todos os testes para ver se tudo está passando. Tudo está passando, em tese a gente já cobriu todos os nossos casos de uso, então eu vou rodar com o coverage aqui, só para a gente verificar se de fato a cobertura dos casos de uso está 100% ou muito próxima de 100%. E... Vamos lá, application, use cases. Eu rodei só um. O que está acontecendo aqui aqui deixa eu ver porque que ele só pegou do último caso de uso cadê use cases show any classes with uncommitted agora sim 100% Agora sim 100% 100% 100% 100% 100% 100% 100% 100% 100% 100% 100% 100% 100% 100% 100% 100% 100% 100% 100% 100% 100% 100% 100% 100% 100% 100% 100% 100% 100% 100% 100% não, não significa que está sem bugs, mas já dá um bom indicativo, já dá uma boa segurança os nossos controllers, vamos rodar todo o teste, toda a aplicação com cover só para a gente ter uma boa noção de como estamos porque os controllers eu acho que também deveria estar 100%, vamos ver aqui Opa, um teste quebrou. Evento controlado, vamos ver. ID. Is ok, só que ele retornou. Unprocessable entity. A gente já, só vamos verificar só a gente já substituiu já substituiu beleza qualquer cenário de erro então deve comprar um ticket de um evento teste reserva é o seguinte o partner na verdade existe? Não, existe, before it, criou o partner, ok Customer not found, foi o que retornou Customer not found Vamos debugar para ver então o que está acontecendo aqui Ah, na verdade eu sei o que está acontecendo aqui A gente mudou a ordem Olha lá Olha lá O importante da cobertura, tá vendo? Mudou a ordem, a gente sabe que Obviamente algum teste deve quebrar Agora sim, todos passaram Vamos ver, olha lá Olha lá GraphQL, cobertura bem baixa Porque a gente também nem tem teste de GraphQL, não sei nem se a gente está pegando essa cobertura, mas ok. Partner, 100%, 100%, 100%, aqui tem uma branching que eu acho que não está testada. É, que é isso aqui, não está testado esse validation error, ok. Mas é isso, então nosso projetinho está muito bem testado. Talvez muito bem amplado, muito forte. Mas eu acho que agora você pode tentar criar testes de integração para esses nossos casos de uso. Porque a gente só trabalhou com testes unitários. E aí, na próxima aula... Na verdade, na próxima aula eu já ensino vocês a fazerem testes integrados para os casos de uso e também vamos colocar o GraphQL da parte do event. Ok? Vejo vocês lá.