Mockito: teste de unidade em Java

1. Bem-vindo ao curso!: Olá pessoal e bem-vindos a este curso na estrutura de testes de unidade Java, Mockito. Meu nome é alces e sou um engenheiro de software que vem usando essa estrutura no meu fluxo de trabalho de codificação há algum tempo, quando ouvi falar da possibilidade de criar um curso para explicar mais sobre o uso e também benefícios. Eu estava bastante ansioso para desenvolver um. Esta aula será estruturada em 11 lições que podem executar passos práticos para você tomar, a fim entender exatamente o que pode ser feito com Mockito, eu primeiro evolui mostrar-lhe como configurar um local ambiente em sua máquina com Mockito nele. Em seguida, analisaremos mais de perto todas as maneiras pelas quais esses dois facilitam o teste de unidade para nós. Coisas como especiarias, combinadores de argumentos, funções em ordem e verificação, especificando valores de retorno para métodos e assim por diante. Se você estiver interessado em melhorar o seu caminho em torno de testes unitários em Java, este curso é para você. Não há outros pré-requisitos do que um computador com conexão com a Internet. Quanto ao projeto desta aula, será extremamente prático e envolverá você a seguir as etapas apresentadas durante este curso. Assim, você pode começar sua jornada de escrever testes de unidade para o código que você está desenvolvendo usando Java. Pensamos, dissemos, acho que já o vemos na primeira lição. 2. Instalando o JDK: Pessoal, bem-vindos novamente a este tutorial. Neste tutorial, vamos começar a aprender , é claro, preparando nosso ambiente em nossa máquina local. Então, antes de tudo, é claro, sendo a estrutura que está usando código Java, precisamos ter certeza de que temos o JDK instalado em nossa máquina local. Portanto, o PIB vem do Java SDK. Sdk vem do kit de desenvolvimento de software. Para este tutorial. Vamos usar a versão de um ponto ponto 01 para Java 16. Primeiro de tudo, você precisa ter certeza que você tem esses JDK instalados no seu computador. Agora, eu tenho uma máquina Windows aqui. Como você verificaria se você já tem esse JDK instalado no seu computador ou se não o possui, você só precisa executar seu CMD. Então, seu prompt de comando com administração e, em seguida, escreva em cada versão java dash. Como você pode ver, eu não o tenho instalado. E o que traz na minha tela é que o Java não é reconhecido como um comando interno ou externo, não está instalado. Dessa forma, você pode confirmar que não o instalou. Se ele tivesse sido instalado, a mensagem seria algo como versão Java e, em seguida, ela informará a versão, depois algumas outras mensagens de farming. Mas agora que sabemos que não o temos instalado, vamos armazenar imagens. Se você já o tiver instalado, poderá pular para a próxima etapa que será em alguns minutos. Mas, por enquanto, como você instalaria seria ir para o link que eu forneci nesta tela aqui, e isso é oracle.com, tecnologias Java. Java SE baixa o HTML. Isso você pode ver que temos aqui o trabalho de downloads do Java SE, vejo 16. E podemos clicar no Oracle JDK no download do JDK. Agora ele nos redirecionará para o Java Development Kit 60. Então você vê o Java SDK e depois rolando para baixo, você pode escolher a versão para o seu sistema operacional, no meu caso, é um Windows 64 batidas, então é a versão aqui. Selecionarei diretamente os arquivos executáveis para que possamos continuar e revisar o contrato clicar em Download. Você pode ver que o executável está realmente baixando agora. Em apenas alguns segundos, isso será feito para que possamos clicar na unha. E como você pode vê-lo iniciando esta instalação, bem-vindo à instalação. Podemos clicar em Avançar. Agora, o banho padrão onde ele o instalaria. E eu sugiro que você deixe a SEC é Arquivos de Programas C, Java, dish e, em seguida, a versão JDK dele. A razão pela qual eu digo para você deixar dessa maneira é porque mais tarde estaremos definindo algumas variáveis do ambiente. A especificação. E se você alterá-lo, você precisará lembrar que Beth mudou os dois e que pode ser baseado no documento do Bloco de Notas. Mas, por enquanto, podemos continuar e clicar em Avançar. E como você pode ver, basicamente começará a instalar o GDK, que foi completamente instalado. Podemos fechá-lo. E assim, o primeiro passo deste tutorial está concluído. A segunda etapa, como eu disse, precisamos definir uma variável de ambiente, mais especificamente a variável de ambiente doméstico Java. E precisamos apontar para o banho onde paramos esses JDK. Então, para fazer isso, você precisa ir para o botão Pesquisar e escrever as variáveis de ambiente do sistema. Clique em Enter. Em seguida, aqui em variáveis de ambiente. Em seguida, podemos clicar em Novo. Em seguida, temos o nome da variável, que será Java em casa e, em seguida, o diretório de navegação. E então o diretório vai para a BSA disse Arquivos de Programas Local Disco C, e então, claro, Java, e então este JDK para a dívida, ele nos pegou. Então, isso vai ficar tudo bem. E como você pode ver aqui, a variável de sistema doméstico Java agora é adicionada e o valor dela é a Beth real. Agora podemos além disso, além de adicionar a variável de sistema do Java home com o valor do caminho aqui no bat, precisamos editar isso e também adicionar novo. E então precisamos gráficos para a dívida da pasta bin com a edição aqui. E então, como você pode ver, o Java JDK e essa pasta de estarem bem aqui depois que eu cheguei, iniciaram meu computador. Porque se você não reiniciá-lo, você não poderá ver que o Java foi instalado ao reiniciá-lo e inserir a versão java dash, você pode ver que ele realmente informa algumas informações sobre os atributos e especificamente, o fato de o JDK instalado com sucesso em seu computador. Mais uma vez, adicionei às variáveis do sistema no início do sublinhado Java definido para o caminho onde o GDK foi instalado e adicionei à parte de trás. Então, variáveis de usuário para seu usuário, clique nele, clique em Editar e, em seguida, no novo navegador e, em seguida, na pasta bin da respiração de instalação do JDK. Se você fizer isso depois de instalar o JDK obtido deste link, você instalará com êxito o JDK em seu computador e concluirá as duas primeiras etapas. Por enquanto. Isso era sobre o Enter. Agradeço muito a vocês por ficarem comigo até o final desta palestra. 3. Instalando a IntelliJ IDEIA: Olá pessoal e bem-vindos de volta ao tutorial. Para este tutorial, precisamos obviamente ter um IDE no qual possamos pular código. E para isso, vamos usar o IDE de ideia do IntelliJ, que minha opinião é o melhor IDE para java por aí. Mas podemos começar a crescer para inteligente e depois clicar no site Download no JetBrains. Isso o redirecionará para o download da ideia do Intel G. Agora, é claro que vamos usar a versão da comunidade. Não é o máximo não escrever código para a empresa de TI. Vamos usá-los no conforto de nossas próprias casas. Mas se você quiser fazer isso por todos os meios, se você tem uma empresa ou algo assim, você pode ir para o máximo. É só que, para este tutorial, vamos usar o Windows dot EXE. E, como você pode ver, o download basicamente começou. Vou voltar para vocês assim que terminar. Ok, então estou de volta que a Intel foi baixada contas e agora, quando clicarmos nesses arquivos executáveis, seremos recebidos por um processo de instalação. Você pode ver o fim de semana de configuração apenas começar a instalar. Ele come nossa pasta de destino padrão na unidade C. Agora, a longitude de 64 bits é o que você precisará selecionar aqui. Em seguida, vamos associar os arquivos Java a ele. Em seguida, podemos atualizar o menu de contexto, editar o projeto Abrir pasta é. Os lançadores diretórios para a cama. Eu não acho que isso seja necessário é que vamos abrir as coisas do aplicativo real para que possamos continuar e clicar em Avançar e depois instalá-lo. Depois de instalado, você será recebido com esta janela final. E você pode optar por executar o Intel J depois que eles realmente terminaram a instalação e podemos clicar em dívidas. Confirmamos que lemos e clicamos em Continuar. Você pode ver que o Intel G ID será aberto agora. E nos pedirá para abrir um projeto ou criar um novo. E, claro, alguns plug-ins na janela de personalização sobre Temas de cores e coisas assim. Então isso foi sobre isso com a instalação do GID para o trabalho que vamos usar neste tutorial. É um WordPress bem simples e direto, mas achei que deveria fazer o tutorial sobre eles apenas para garantir que vocês estejam cientes da maneira como vocês vão começar a funcionar. Espero que você tenha tirado algo desse tutorial, e eu realmente estou ansioso para vê-lo no próximo. Muito obrigado por ficar comigo até o final desta palestra. 4. O que está a mocking?: Olá pessoal e bem-vindos de volta a este tutorial do Mockito, onde entendemos como podemos melhor em relação aos nossos métodos Java usando essa estrutura de testes. Nesta palestra, vamos dar uma olhada em algumas noções teóricas sobre zombar. Pouco antes de mergulharmos profundamente na estrutura de testes do Mockito e entendermos como podemos escrever código para testar nossos métodos. Vamos cobrir algumas coisas básicas, como o que está zombando, o que deve ser marcado, diferentes tipos de marcas e esse tipo de coisa. Só para que possamos ter um bom conhecimento deles antes de aplicá-lo. Entendemos o processo que iremos para onde escrever o código real em nossas IDs. Agora, em termos simples, o processo de marcação refere-se a fornecer controle, instância ou implementação, ou até mesmo dependência da qual o código em teste depende. Para testar cada lógica principal. No caso do nosso primeiro aplicativo Mockito, a cadeira vai olhar na próxima palestra da seção antes de entrarmos em recursos mais detalhados do Mockito, vou apresentar-lhe um básico aplicativo usando Mockito e em aplicação de dívida. O método que será referenciado em uma função que queremos testar será zombado e será feito por solicitado a retornar um valor específico que desejamos. Portanto, essa é a prática de marcar. Essas marcas são resgatadas nas situações em não importa se você está dependente e treinando ou não, você sempre tem a garantia de executar sua lógica de negócios com uma resposta programada para a dependência que está sendo chamada do código em teste. Se você já ouviu o terceiro teste duplo se refere essencialmente a um objeto que é substituído por uma instância ou dependência de árvore ou objeto equivalente. Existem duas vantagens principais sobre por que os processos de simulação são úteis ao testar nosso código. Você pode pensar neles como os pilares de base nos quais baseamos o uso de nossos testes unitários. A primeira vantagem é a eficiência que o processo de fumar traz consigo. Porque com zombaria, temos a certeza de que existe apenas nosso código que é executado. Ao ser testado. Todas as outras dependências terão valores codificados e simulados dados por nós e esse código não será realmente executado. Agora, o outro motivo é sobre o controle exato que temos em todos os outros componentes que nossa função IF de teste precisa. Isso pode criar uma separação muito benéfica. Ajudando-nos dessa maneira a ver rapidamente se a função que queremos testar está comportando AES-128 ou não como as partes que são usadas no processo que não fazem parte da função que queremos teste. Teremos valores definidos que serão marcados por nós. Já saberemos qual o retorno e como eles se comportam. E só limitamos nossos testes. A função que realmente queríamos testar. Existem diferentes tipos de duplas ou marcas de teste. E vamos percorrer cada um deles apenas para que você tenha uma melhor compreensão da classificação deles. E em uma palestra futura, se você vir um desses nomes, você vai se familiarizar com ele e entender rapidamente e ter um ponto de referência sobre que exatamente esse tipo de E's duplo. Primeiro de tudo, temos as falsificações. As falsificações são uma implementação que é bastante semelhante a uma dependência real, exceto o fato de que ela está situada na máquina local onde o código em teste está realmente permanecendo. Aqui, o exemplo que é mais usado e o cenário em que somos falsos são os mais úteis. Ao lidar com a persistência de Theta. Ao lidar com bancos de dados. E, em vez de ajustar um banco de dados de produção real, teste usa uma coleção simples ou uma memória para armazenar dados. E por que isso é muito útil é porque você pode não querer, para cada teste que você faz para realmente preencher algumas linhas no banco de dados de produção real. Ou mesmo você tem um banco de dados de testes. Talvez você não queira preenchê-lo porque pode surgir alguns problemas quando fazemos isso. O primeiro seria que Daniel tenha que excluí-lo. segundo seria o tempo e a eficiência desperdiçados nessas duas operações. Mesmo para dizer que o banco de dados não é nem a profundidade que você deseja testar. Queremos testar um método que está chamando o banco de dados real. Você queria ver como a função se comporta e não se a chamada para o banco de dados está realmente funcionando, isso deveria estar em outra classe. Se você tiver uma boa separação em seu projeto. E essa classe deve estar no projeto de repositórios, onde a equipe relativa ao banco de dados ainda é ajustada. Quais falsificações são usadas na maioria das vezes. Eles são muito importantes a partir disso uma perspectiva. Em seguida, temos os talões. E essas coisas são apenas respostas pré-configuradas quando uma dependência é chamada do sistema que esses 100 testes. Agora, além de paradas, também temos Spice. Estes são diferentes das paradas, falsificações e também marcas porque a função real ou dependência realmente é chamada. Em especiarias. Ele tem algum mecanismo de observação anexado a esta chamada para teste Delta B e postar a chamada este mecanismo de observação. Pode-se verificar se o carvão foi realmente acionado ou não junto com os parâmetros. E, por último, temos o tipo de teste duplo mais importante qual vamos concentrar no qual vamos concentrar a maioria deste curso. Essas são as simulações. As marcas são instâncias especiais de objetos e as respostas dos sujeitos podem ser especificadas pelo testador. É isso que os torna únicos. O fato de que o intestino Mach chamado pode ser verificado afirmação de SAML no teste. E este será o ângulo em que Mockito vamos brilhar, como você verá no projeto de pré-visualização do qual estou falando. E entraremos nisso em apenas um momento na próxima palestra. Isso facilita a criação de objetos simulados sem problemas. A maneira como ele faz isso é usando o recurso de reflexão em Java para criar objetos simulados para uma determinada interface. Então você tem uma interface e ela basicamente cria um objeto instanciado como concreto. Mas esse concreto realmente não existe. Basta marcar até inventá-lo e fazer com que ele retorne alguns valores que você pensa na linha que você está interessado para os valores de dívida apareçam na função que você realmente deseja testar . Além disso, para ver novamente como a função se comporta quando possui parâmetros de entrada controlados, dado I, seja como parâmetros ou como resultados das funções que são chamadas Imagem longa. Agora, apenas algumas palavras sobre por que Moche W tão popular e você deve escolher estudar, é que essa estrutura permite que você crie e configure crie e configure esses objetos simulados sobre os quais falamos. Isso seria bastante óbvio a partir do título dessa estrutura também. Mas o uso do Mockito simplifica muito o desenvolvimento de testes que você faz para classes com dependências externas ou métodos simples dentro dessas classes. Se você, a estrutura estatística de teste, você pode, como eu disse, zombar das dependências externas e também inserir as marcas no código em teste. Dose que você deseja dar esses valores específicos para funções dentro da função que você deseja testar para ver como ela se comporta. É claro que você pode executar o código em teste com macaco DO e também validado que o código é executado corretamente neste ambiente controlado que você configurou com o processo de marcação. Tratava-se de comer para as noções teóricas zombeteiras que você filma, tem em vigor pouco antes de começarmos a zombar real no código e ver como isso funciona. Por isso, em diante. Na próxima palestra, veremos uma rápida olhada no primeiro projeto Mockito que vou ter configurado usando o resolvedor de dependência de cascalho. E se isso soa interessante, estou ansioso para ver vocês na próxima palestra. E agradeço muito por ficar comigo até o final deste. 5. Olhar rápido para um projeto Mockito: Olá pessoal e bem-vindos de volta a este tutorial do Mockito, onde entendemos como podemos testar melhor nossos métodos de chatbot usando essa estrutura de teste de unidade. Para esta palestra, vamos dar uma olhada rápida sobre como podemos configurar nosso projeto em Nova Délhi para que possamos escrever testes unitários que estão usando principalmente a estrutura Mockito. Depois de abrir o IntelliJ, você pode clicar em Novo Projeto para que você obviamente o suficiente grego, um novo projeto. Então, nesta janela que você vê na tela agora, você precisa selecionar Gretel. Então você precisa ter o Java marcado e o SDK do Java que você baixou em sua máquina local. Eu já tive uma palestra agora você pode fazer isso. Mas se você já o tiver instalado, você pode, é claro, adicionar o JDK. Então pisque o caminho que você tem em sua máquina local ou você pode baixar diretamente o TFUE não seguiu esse passo de baixar seu GDK diretamente do inteligente, mas nós conseguimos. Assim, podemos clicar em Avançar. Aqui estão a nomeação do nosso projeto. Vou nomear meu projeto ou tutorial. E o local será o padrão que está situado na pasta Projetos Idea. Em seguida, o ID do artefato vai superar o tutorial, o ID do grupo ou exemplos de pontos ORT. Isso é bem simples. E ao clicar em Concluir, vou selecionar a nova janela é que já tive uma janela aberta com outro projeto. Agora você pode ver que temos um projeto básico aberto e ele está praticamente pronto para escrever código. E você pode ver que, quando ele abrir, Gretel fará com que a iniciação seja construída sobre ela. Só para ver que está tudo bem e pronto para começar. Você pode ver que a compilação foi bem-sucedida. E aqui na parte direita também temos uma ótima torneira sem a tarefa de construir, montar, construir e todas essas coisas boas. E você pode executar cada um deles para que você diga que está tudo bem, mas deve ser tudo deve estar em ordem em seu ambiente se você seguir os passos que acabei de descrever mas deve ser tudo deve estar em ordem em seu ambiente se você seguir nas aulas. Então, a primeira coisa que você vai precisar fazer para colocar o Mockito em funcionamento é ir para este arquivo de conta para esse Gretel aqui mesmo na janela do projeto abrindo em cima e em na seção de dependências na linha 12, você precisará inserir essas duas linhas. Então teste a implementação do nosso jipe. Esse Mockito, Mockito na linha 377 e Mockito, você precisa Júpiter 377. Depois de inserir esses dois valores, você pode ver que você tem esse elefante. Ele também tem um sinal de sessões síncronas no canto inferior direito dele. E se você passar o mouse sobre ele, você pode ver que os meios que você pode permitir as mudanças graduais. E basicamente detecta que a estrutura do projeto mudou. E para que essas mudanças sejam assimiladas no sistema e construam com base nele e resolvam todas as referências, você precisa carregar essas mudanças graduais no. Depois de clicar nisso, você pode fazer outra compilação. E uma vez que isso foi feito, você pode basicamente continuar e escrever seu código. O código será colocado nessas duas pastas. Você tem a pasta principal com a subpasta Java onde você vai colocar o local de trabalho, essas interfaces e assim por diante. Então, basicamente, esse é o código que será testado. O código de lançamento. Então, para nomeá-lo na pasta de teste, mais especificamente novamente, no trabalho de uma subpasta, você fará uma classe de teste. As classes usarão o Mockito para testar os métodos das classes que estão disponíveis e escritas por você que você deseja ter testado na pasta Java da pasta principal principal. E, claro, você pode continuar depois dessa configuração básica para amadurecer seu teste unitário do Mockito. Claro que você precisa importar Mockito, mas isso é apenas uma linha de código. Mais especificamente é importar ORT estático que Mockito ponto Mockito com uma letra maiúscula M e, em seguida, ponto estrela para que ele recupere toda a biblioteca. E depois disso você pode usar todas as coisas boas, como métodos de Mach quando e assim por diante. Vamos, claro, entrar nas próximas palestras. Mas isso estava acima disso. Agora, se você não vê que sua solução simples Gradle está criando, como no meu caso, ela foi criada automaticamente. O que você precisa fazer é clicar nesta grade azul e, em seguida, clicar nesta grade azul e, em seguida mouse sobre ela e , em seguida, executar o tutorial. E isso, por padrão, executar são construídos em todo o projeto. Claro, ele o executará com todas as dependências inseridas aqui. Esse era um ambiente básico que você precisa configurar em sua máquina local antes de ir mais longe, este tutorial, se você quiser fazer, realmente tem uma boa experiência seguinte. Então, se você quiser replicar o que eu faço ou faço do seu jeito ou de maneiras semelhantes, porque começa com as dependências e essa é a maneira que você precisa configurar seu projeto Intel J. Mas isso foi sobre isso para esta palestra. Estou ansioso para vê-lo nas próximas, onde vamos pegar algumas palavras-chave, noções e coisas que o framework Mockito e fazer mais detalhadamente, entendê-lo e mergulhar profundamente nela. Isso parece interessante. Estou ansioso para ver vocês lá. E mais uma vez, muito obrigado por ficar comigo até o final desta palestra. 6. Como configurar seu primeiro projeto Mockito: Olá pessoal, e bem-vindos de volta a este tutorial do Mockito, framework Java, onde entendemos melhor como podemos testar por unidade nossos métodos Java usando essa estrutura de teste. Pois, para esta palestra, vamos dar uma olhada na primeira aplicação que temos, alguns dos conceitos nos quais vamos mergulhar mais adiante neste tutorial. Só para você fazer a imagem de como um projeto se pareceria em cada uma. E também como você criaria o início a partir de 0? Para começar, vamos, é claro, ir para o IBD escolhido para Java. Isso é o IntelliJ J, como você viu nas últimas palestras. Em você vai criar um novo projeto, é claro. E você pode ir arquivar um novo projeto ou, se ainda não tiver um projeto aberto, ele não abrirá nada além da janela inicial onde você o redireciona para abrir um projeto ou um novo projeto. Você pode configurar um novo projeto e o que deseja selecionar Próximo é gradual. Em vez de Java simples. A razão para isso é que isso torna nosso trabalho muito mais fácil ao vincular a estrutura Mockito em nosso projeto. Então, em vez de apenas continuar e baixar os arquivos do GIA IR dos repositórios Maven, o arquivo JAR ham crest, o Mockito e também vincular variáveis do sistema DOS à parte de trás. O que isso fará. Grader vinculará automaticamente o Mockito com muita facilidade, pois mostrarei em um segundo ao nosso projeto. Então, usaremos a grade off para este tutorial. Caso você não saiba, vou passar por uma breve descrição de qual crédito. Então você pode pensar que é apenas uma ferramenta para automação. Então, o que ele faz, está automatizando a criação de aplicativos, tornando-o muito mais fácil e rápido. Estas são automação que inclui o link na embalagem e compilação de diferentes partes do seu código. Mas, por enquanto, você pode simplesmente escolher Gretel aqui na densidade do projeto j, você precisa. Claro, escolha o JDK que você instalou. Em sua máquina local. Instalamos nossa dívida de 16 JDK é detectada automaticamente por inteligente porque a deixamos em seu próprio caminho padrão. Mas se você escolheu esse caminho uma maneira diferente ou tiver uma versão diferente do JDK instalada, ele deve ser automaticamente, como eu disse, ser escolhido aqui. Mas se não acontecer, você pode baixar o JDK se não o tiver e ele será baixado automaticamente para você. Você não precisa passar por todo esse processo da palestra anterior. Ou você pode adicionar seu JDK se você já o tiver instalado, mas ele não for detectado. Você pode escolher um caminho de onde você instala esse arquivo bin. Mas, por enquanto, você também pode escolher Java e , em seguida, clicar no próximo nome do projeto e do local. Além disso, as coordenadas do artefato como o ID do artefato dependem inteiramente de você. Portanto, isso não será de fato nosso projeto de forma alguma. Então, quando você clicar em Concluir, ele abrirá um projeto para você por padrão a partir da largura inferior não incluída. Claro, vamos fazer isso em uma palestra futura e eu vou orientá-lo exatamente como as dependências são construídas e o que você deve fazer para importar Mockito e todas essas coisas boas. Mas esta palestra é apenas para mostrar um projeto rápido que eu criei aqui com algumas aulas que estão realmente trabalhando em conjunto com o framework Mockito. Para testar um método específico de uma classe específica, vamos dar uma olhada apenas para você ter uma ideia melhor de como as coisas funcionam nessa estrutura de testes exclusiva. Você pode ver aqui eu tenho arquivo industrial sees, o arquivo principal. Aqui eu tenho um Java. Um arquivo, é claro, junto com o arquivo principal, temos o arquivo de teste onde intuitivamente, vamos escrever nossos métodos de teste. No Java. Vamos apenas declarar nossas aulas. Tipos de métodos que podem ser desejados ser testados. Para começar, temos o vidro do carro aqui. Essa classe tem três campos, ID do carro, que é uma string, nome, que é uma string e quantidade que é uma string. E imaginamos que esses exercícios como algum tipo de autoridade que está vendendo carros vendem bem, eu chamei isso de concessionária. E também temos um serviço de carro que facilita essas transferências. Agora, outra observação aqui é que quando você ouve que a classe tem serviço em seu nome, você deve estar automaticamente pensando que essa classe está fazendo alguns métodos para suas outras classes. Nós fomos serviços dos EUA nele. E se você ouvir o repositório algo a ver com a persistência de bons dados, armazená-lo em um banco de dados e assim por diante. Isso foi apenas um parêntese rápido. Então, agora avançando, o carro da classe, é claro, tem um construtor com todos os três parâmetros que ainda inicializados aqui. E então temos alguns setters e getters que são públicos. E através disso, vamos realmente definir ou fazer com que nossos campos particulares sejam alcançados dessa maneira. Encapsulamento feito, boas práticas. Esta é a lista, nada realmente fora do comum aqui. Apenas alguns campos que ainda definem e obtêm parede celular. Não podemos realmente testar nada aqui, mas vamos ver que estamos apenas testando ou classe que fazem facilmente. Bem, esteja mais longe aqui agora, também temos as concessionárias de carros. Então, esse é o método que testaremos a célula de vidro. Primeiro de tudo, importamos Java util beast, pois vamos fazer uso da lista aqui na linha 15. Mas a concessionária de carros da classe tem que filtrar. Você precisa de um serviço de carro, que é uma interface e lista de vinhos de carros porque a concessionária teria pelo menos carros, é claro. Agora, o serviço de carro fica getter e também um setter. E então a lista de carros também recebe um no getter. Por fim, temos outro método aqui que será testado usando o caso do framework. Você verá em apenas um momento, o que ele faz é declarar uma variável do tipo duplo chamado valor de mercado, e ele a incrementa com 0. Agora, vamos iterar para os carros menos que ele seja membro desta classe. Vamos aumentar o preço de obtenção de um carro. Assim, os serviços de carro podem ver que é apenas uma interface que tem essa assinatura de preço get aqui. E esse é o método que vamos zombar usando o Mockito para devolver algo que queríamos. Isso é o que marca significa. E além disso, vamos multiplicar o preço que vamos marcar o valor que vamos dar. O método de quantidade que, claro, está na classe de carro. A quantidade que retorna quantos carros existem. Finalmente, depois de iterar cada carro e incrementá-lo com esse valor de multiplicação, vamos retornar esse valor. Então, como eu disse, o serviço de carro tem essa assinatura, um método que não é realmente implementado. E agora vamos passar para a classe de testes. Como você pode ver em teste e Java, dessa forma grade, não sabemos se esse é o método de teste. Aqui está a magia acontecendo, por assim dizer, e Mockito está envolvido. Esta é a classe de testes de cartão que vamos importar alguns utilitários que vamos usar. Então, com isso, você pode ver que estamos importando o Mockito. Como eu disse em uma palestra futura, vamos ver exatamente como podemos importar esses Mockito usando Gretel. Estamos começando a na classe de testador de cartões aqui. Então, temos uma concessionária de carros, o serviço de carro. O serviço é uma interface. Aqui temos o método principal que é o ponto de entrada em que vamos executá-los, isso bastante simples. Estamos declarando testador de cartões, que é essa classe. Então, vamos instanciá-lo e, em seguida, você vai chamá-lo de configuração para ele. Portanto, a configuração é esse método aqui que instancia a concessionária e o serviço de carro. Pode ver que o serviço de carro é apenas uma interface que eu disse na verdade não implementada. Vamos usar o método simulado de Mockito. E nós vamos dar-lhe o serviço de carro e o vidro. Então, vamos apenas marcar a classe, pois será uma classe concreta em não apenas uma interface para a concessionária. Nós também vamos definir o serviço de carro para esses serviços de carro marcados, como você pode ver aqui em seguida no método principal depois de configurar esses testes, seu objeto de testador de cartão de tipo, nós somos indo codificar esse valor de mercado de teste. E dependendo do booleano e ele retornar, vamos comer o que é melhor emoldurado se o teste passar ou falhar. Se ele falhar. Chegando mais fundo nesse valor de mercado de teste, um método. Aqui vamos apenas declarar uma lista de carros. Então eu vou realmente instanciar dois objetos do tipo carro. O primeiro é Lamborghini e o segundo sendo um Audi. Vai usar o construtor com todos os valores reais. Vamos dar-lhes algum ID de estoque, alguns nomes e as quantidades que temos que aprender a trabalhar bem. E três são estes, ambos os carros, que na verdade são listas de carros porque eles devem começar a usar esses três ou estes serão adicionados à nossa lista, claro, que é chamado de carros como você pode ver online lá até 1637. Então, no 40, vamos chamar o método no objeto da concessionária. É uma concessionária de carros. O que esses métodos de set cards fizeram foi, se você se lembrar de ajustar a atribuição da lista que lhe damos como parâmetro para a lista de campo para a concessionária de carros. Além disso, depois de fazermos isso, é aqui que demo.com cena e, claro, teremos uma palestra posterior, onde explicarei exatamente o que esse método faz. Mas, por enquanto, só para que você possa ter uma visão maior, o que esse método de quando recebe basicamente uma chamada. Diz quando o método do preço da diferença do serviço de Cristo seria chamado com um parâmetro de Lamborghini. Então você deve ler 250 mil, que seria o preço da Lamborghini que eu estimei. E, novamente, quando eles recebem o método de preço do serviço de carro seria chamado usando o carro, então você deve retornar 50 mil. Novamente, ele marca essas chamadas. Portanto, o código não precisa passar por todas as classes de preço, porque você só vai querer testar o método de valor de mercado. E é isso que ele faz. Ele marca o vidro do método de obter Bryce. E depois de vermos isso, você pode ver que vamos chamar a função get market value vidro da concessionária, que foi esta. E como você pode ver aqui, estamos marcando o método de preço líquido porque não é isso que queremos testar. Só queremos que isso obtenha o método de valor de mercado. E como eu disse, quando isso seria chamado, ele iria iterar para os carros e, em primeiro lugar, ele o entregará ao número guinéus. E quando o serviço de carro obter preço de Lamborghini seria chamado, o Mockito diz para você retornar a 50 mil e nem se preocupar em chamar o preço real get, o que, claro, nem sequer é implementado porque esta é uma interface e estamos marcando. Então todo o ADI da mesma forma e besta nos permite testar o método get market value em condições muito controladas e também de forma muito eficiente como eles obtêm método de preço não vai para o frio et al. Vamos, como eu disse, chamá-lo da concessionária. Depois disso, vamos transformar o valor de mercado igual a 650 mil, que seria o valor correto dado o fato de que 250 mil vezes dois é 525.000 mil vezes 350 mil. Adicione esses dois e você ganharia 650 mil. Claro que agora, ele vai imprimir passar ou falhar, dependendo desses verdadeiros ou não, o valor que esse valor de mercado de teste retorna. Então, se clicarmos com o botão direito do mouse na classe de testador de carros, dizemos o domínio Ron Cortez. Você pode ver que agora está realmente construindo todo o projeto e interesse. Segundo, você pode ver que é o melhor. Agora vamos ver se funciona. Se aqui tivéssemos 65 mil, que não é o valor correto, você deve obter uma falha aqui. Então, vamos ver se isso acontece. Acontece. Agora, isso foi sobre ação para a primeira introdução no Mockito. Vendo um projeto maior na cidade, Mockito se acostumaria em um projeto já configurado. Mas, começando com a próxima palestra, vamos apresentar gradualmente desde o início como você pode criar seu primeiro projeto. Também apresente palavras-chave e recursos específicos do framework Mockito e como eles são usados, o que fazem e assim por diante. Então, se isso soa interessante para você, espero ver vocês lá. E muito obrigado por ficar comigo até o final deste tutorial. 7. Especializando valores de retorno: Olá pessoal e bem-vindos de volta a este tutorial do Mockito, onde entendemos melhor como podemos testar nossos métodos em Java usando essa estrutura de teste de unidade. Nesta palestra, vamos dar uma olhada em como o Mockito pode especificar valores de retorno em diferentes cenários para algumas funções que chamadas em diferentes tipos de situações. Com o Mockito, você pode adicionar funcionalidade para marcar um objeto usando métodos diferentes. Você pode ver que fizemos isso aqui em nossa mesa na linha 23. Marcamos toda a classe de serviço de carro que estava em uma interface e não lideramos nenhuma implementação real. Mas além daquele rim Mockito, também pode marcar o comportamento de uma função que é chamada com certos parâmetros. E ao marcar a dívida, ele pode especificar o valor de retorno exato que essa função deve ter quando chamada com esse parâmetro específico. Por exemplo, online 43. Como você pode ver, o Mockito instruiu a função de obter o preço do serviço de carro, que na verdade não tinha implementação na interface. Para devolver os 250 mil falham quando esfriar, poderíamos o argumento de Lamborghini. E como você pode ver, a sintaxe empilhada para isso é a palavra-chave wing. Em seguida, a função que será chamada com um parâmetro específico. Portanto, a dívida é a situação em que você quer que esse comportamento seja adicionado. E então a palavra-chave den return e, em seguida, o valor, a função que está sendo chamada com esse parâmetro específico deve ter na situação exata da dívida. Neste ponto do tempo. Mock já gravou o comportamento e está funcionando objeto simulado, tipo de interface de serviço de carro. O objeto de serviço de carro já é um objeto simulado em funcionamento. Novamente, eu já disse isso, esse código aqui é muito útil porque esse código será executado na concessionária, obterá valor de mercado. Vamos testar e queremos que essas duas chamadas tenham nossos valores exatos dados, valores marcados, apenas para que possamos ter certeza de que esta função está indo bem ou não em para que possamos ter certeza de que esta função está relação a essas funções de get preço. Portanto, se a função de get priced funciona ou não, método definido duas vezes, porque especificamos os valores que ele deve retornar. E queremos nos concentrar em testes unitários para obter o método de valor de mercado. Este é o método básico de quando e depois retornar, que é disse SHE, o framework Mockito especificando os valores de retorno. Como alguns outros programadores podem pensar. Isso está adicionando o comportamento. Em certos tipos de situações. Isso é uma coisa muito útil quando você quer criar essa separação sobre a qual falamos da classe que você deseja testar na dependência abaixo e classes que são chamadas dentro dela. Então isso estava acima da ação para esta palestra. E no próximo, vamos começar a olhar para a palavra-chave verificada, que é uma palavra-chave muito importante, droga de demonstração, estrutura de teste de unidade. E vamos ver exatamente o que ele faz e todos os vários cenários que são muitos deles que verificam que a palavra-chave pode ser usada. Isso parece interessante. Estou ansioso para ver vocês lá e muito obrigado por ficarem comigo até o final desta palestra. 8. Verify o comportamento do método: Olá pessoal e bem-vindos de volta ao smoky contou Turiel. Onde quer que entendamos como podemos testar melhor a unidade nossos métodos escritos em Java usando essa estrutura. Nesta palestra, vamos falar sobre o método de verificação que o Mockito nos fornece. Também como podemos usá-lo e por que é útil para nós ao tentar unir este ou até mais métodos que escrevemos no R. Talvez em produção ou talvez queiramos implantá-los em algum momento no futuro. Então, começando aqui, criei um projeto totalmente novo na Intel J. E a maneira como fiz isso foi bem semelhante ao outro que vimos na palestra anterior, onde eu apresentei o visão geral de um projeto para você. Mais especificamente, acabei de clicar em File New Project. E então, quando isso se abriu, escolhi o sistema de resolução de dependências Gradle, escolhi Java e, em seguida, o JDK de minha escolha. Em seguida, acabei de escolher um título para ele, mesmo para as coordenadas do artefato e, em seguida, clico em Concluir e então ele criou meu projeto para mim. Depois disso, acabei de criar o gradle e importei algumas coisas para algumas dependências que precisaremos para fazer esses projetos funcionarem. Ser mais específico que a dívida. Usou JUnit e também os pacotes Mockito. A API JUnit Jupiter já estava aqui depois que você os incluirá. Como você se lembra, se você alterar qualquer caractere do arquivo gradle de compilação DC, você obterá o self e com o botão de sincronização que você precisa clicar para que ele seja importado em sincronizado com todas as dependências mais recentes, diretamente no arquivo Gradle de compilação. Depois que eu fiz isso, a fonte é arquivada com a média e as pastas de teste foram criadas após a criação do projeto. Na pasta Java, tenho uma classe e a interface. A classe é chamada de aplicativo de faturamento, e a interface é chamada de serviço de loja de títulos. O serviço de loja de penhores tem dois métodos que você precisa vender e comprar. Primeiro, eles não são implementados no aplicativo de faturamento. Na verdade, é uma clínica, não uma interface. Eu tenho esses campos particulares. Esse é um serviço de loja de fontes de tipo, que era a interface. E então eu tenho o serviço de loja de celeiro set, que define meu campo de serviço de loja de títulos. Então eu tenho a função de célula que apenas adiciona dois números. O primeiro deve ser o lucro total que o soco teve até este ponto. E o segundo deve realmente ser o preço pelo qual vendemos nosso objeto específico. Novamente, estes são praticamente apenas para um exemplo em que não são implementados em um grau em que seriam intuitivos ou nada por método também. Isso chama a bicicleta do serviço de punch up, que como você viu, não é implementado, mas vamos ver como isso funciona em apenas um segundo. Agora, onde fica interessante, porque até este ponto era bem parecido com o outro projeto que vimos. Facilidade na pasta de teste, onde criamos automaticamente a pasta java e crio essas duas funções aqui. Essas são as duas aulas. Um deles é chamado de testadores de aplicativos de faturamento. Portanto, cada aplicativo de teste para monitores que você vê na tela aqui não fez um aplicativo de cobrança. E então eu tenho um executor de teste que tem a função principal que você precisa, como veremos em um segundo, é responsável por realmente executar todas as diferentes classes de mesa é que teríamos em esta pasta, em minhas restrições, apenas uma. Mas em um projeto de produção maior, pode haver muitos óculos de teste. Eu sei que é bastante útil para executar a barragem em vez de ter domínio em cada um deles, porque isso seria muito mais demorado clicar muito nos botões em cada um dos projetos. Além disso, para o teste de solicitação de cobrança aqui. Como você pode ver, é bem diferente daquele que vimos no último projeto. E a principal diferença é que essa classe de testador é lida com o treinador JUnit. E como você viu se você se lembrar, importamos a unidade de intercâmbio no meu caso é 4131, a versão. E explicando um pouco o que esses pontos, um corredor JUnit é apenas uma classe que estende a classe de corredor da JUnit, que é abstrata. Esses limites são usados para executar as classes de teste. Eles têm alguma paciência com o sinal de at que ajuda o processo de construção entender qual objeto é a marca, qual objeto é o objeto que deve injetar o simulado dele também, e também as funções de teste. Os testes JUnit são iniciados usando a classe principal JUnit. E isso pode ser feito ao executá-lo a partir da linha de comando. Mas no nosso caso, isso será feito por padrão, pelo nosso IVE quando vamos pressionar o botão Executar na unidade de disco que tem o método principal. Veremos isso em um segundo. Este corredor JUnit usa reflexão para encontrar o treinador apropriado para os melhores óculos de teste. E, claro, ele vai primeiro procurar a anotação da largura da rima na classe de teste, e nenhum outro corredor é encontrado. O executor padrão será usado. Ele será instanciado e a classe de teste será passada para o corredor. No nosso caso, dívidas, a classe testador de aplicativos. O trabalho do corredor é instanciar e melhor teste de vidro. Então essa é a corrida ou é bem simples? Isso só nos ajuda a executar nosso teste no Intel J usando condições intuitivas e para mostrar ao ID qual componente é switch n. Qual é o papel de cada ator nesse processo? Agora, passando para o corredor de testes e voltaremos a esse melhor da categoria em apenas um pouco. Na classe test runner, você pode ver que temos a função principal e temos um resultado atribuído ao método JUnit run classes. E isso é dado como a classe de teste do parâmetro d. Como eu disse, a unidade da cadeia ou vai executar a classe de testes. E, claro, essas anotações vão ajudá-lo a fazer isso. O resultado é atribuído às classes de tronco JMU. O núcleo de dois minutos classifica esse vidro usando reflexão e, em seguida, coloca o resultado nessa variável de resultado aqui. Agora vamos iterar essas falhas de resultados. Portanto, esse objeto de resultados tem um método máximo chamado get failures e retornará todas as falhas se houver algum em nosso teste. E isso vai imprimi-los na tela. Claro, também será impresso se nosso resultado foi bem-sucedido ou não no DC vai imprimir true se todos os testes forem bem-sucedidos ou falsos se alguns deles estiverem falhando, como você pode ver na descrição na tela, momento, essa era praticamente a estrutura do nosso projeto. Vemos na tela. Eu só queria mostrar todos os elementos que fiz em detalhes. Só assim, se você quiser acompanhar este projeto ou talvez até mesmo escrevê-lo e depois modificar que você está online. Você vai ser capaz de fazer isso. Após esta apresentação. Vou me aprofundar mais no conceito sobre o qual vamos falar nesta palestra. E verificar método, a classe pública de testes de aplicativo de faturamento que escrevi na tela aqui, faz algumas coisas que são muito conhecedoras dentro do Mockito estrutura em seu despejo, muito bom com essa estrutura e é por isso que eu queria apresentá-los a você. Em primeiro lugar, ele declara um objeto de aplicativo de faturamento. A anotação das marcas Injetar testa que este é o objeto em que a marca deve ser injetada. E como você pode ver aqui, o serviço da loja de penhores é a marca porque é apenas uma interface e devemos injetá-lo neste copo. Agora também declaramos dentro desses objetos testados no serviço de loja, que anotamos. Isso é realmente uma simulação como você viu, iterando, que é uma interface e devemos comercializar e comercializar o comportamento para retornar exatamente o que queremos retornar e que realmente implementá-lo. Lembre-se, estamos fazendo isso para evitar sobrecarga no teste de nossas classes de produção. Ou por não querer recriar todos os fluxos de banco de dados em apenas alguns valores simulados dados por nós e também controlar melhor o fluxo de peças muitas vezes funcionam que não estão realmente relacionadas a ele. E nós só queríamos testar essa função separadamente de qualquer outra classe. E agora o teste na função, que é o teste único real que escrevemos neste aplicativo. Como você pode ver, isso é anotado com o sinal de teste. Vamos, em primeiro lugar, com o comportamento usando Mockito, que quando o método de venda do serviço de loja de penhores for chamado com os parâmetros de 1020, dano deve retornar 30. Estamos adicionando esse comportamento caso contrário, essa linha de código aqui não teria existido. O serviço de loja de penhores com o método cell não retorna nada, pois esse método não é componente, adicionamos o comportamento. E então vamos testar essas funcionalidades de adição e afirmar se o método de venda do serviço de loja de penhores com os argumentos de 1020 realmente retornará 30 S que instruímos a fazer. E vamos fazer isso como você pode ver com o método assert, que pertence à classe JUnit, a referência JUnit é muito importante aqui. E então esse lugar tem um método assert equals, como você pode ver, que pega dois objetos e em seguida, começa se eles são iguais ou não. Isso é bem simples. Agora, podemos verificar o comportamento usando essas palavras-chave de verificação e também método. Verificar comportamento diz que devemos verificar o método de venda do serviço de loja de penhores com os argumentos em 20. O que isso significa é basicamente verificar se o método de classe de serviço bond shop da célula com o argumento 1020 foi realmente chamado. Também podemos fazer outra coisa usando check. E isso também está sugerindo os tempos dessa função sendo chamada. Agora, indo um pouco mais aprofundado no conhecimento do método de verificação teórica. Mockito pode acompanhar todas as chamadas de método que você faz nos métodos de teste e também seus parâmetros para o objeto simulado de dívida. Você pode fazer isso usando esse método de verificação do qual estou falando aqui no objeto simulado. Como eu disse, você precisa usar isso para verificar se as condições especificadas foram atendidas. Por exemplo, você pode teoricamente verificar se o método foi chamado de certos parâmetros é que estamos fazendo aqui na linha 30 para esse tipo de teste às vezes é chamado de teste comportamental. Isso é bastante sugestivo. E não verifica o resultado de um amigo de chamada de método verifica se o método é chamado com os parâmetros corretos. Como você pode ver nesta confirmação online 3333, o resultado real, que é 30 e deve ser 30 no método de dívida que está marcado em nenhum lugar para ser encontrado, modo que isso não está implicado. O resultado dessa chamada de método, acabamos de verificar se o método de profundidade foi chamado ou não com parâmetros vermelhos e também o número de vezes que foi chamado. Claro, ele pode fazer muitas outras coisas que vamos fazer, verificar as palestras posteriores. Mas nesta palestra vamos nos concentrar apenas nesses dois fatores. Passando por isso novamente, os métodos refinados de brinquedos de macaco são usados apenas para verificar o comportamento certo aconteceu. Podemos usar esses métodos de verificação no final dos métodos de teste e é assim que eles devem ser usados como você pode ver na minha tela também. Para se certificar de que os métodos especificados que nós chamamos para cima deles sejam realmente chamados. Dessa forma, tenha outra maneira de verificar se o fluxo de trabalho real que sugerimos, esse método de teste realmente ocorreu e E está funcionando como pensávamos que seria. Podemos seguir em frente e executar isso e ver o que acontece com essas funções de teste. Ao clicar com o botão direito do mouse no executor de teste e executá-lo, ele irá para a função principal. Em seguida, usando o núcleo JUnit, ele executará todas as classes nesta classe de teste. Em seguida, ele irá iterar cada uma das falhas, se houver alguma, imprimi-las e, se não, ou mesmo que fossem menores, o VT imprimirá na tela se o resultado foi bem-sucedido ou não. Bem sucedido, o que significa que houve algum erro ou não. É bastante intuitivo quando o método de classes de execução do núcleo JUnit é chamado de largura do teste do aplicativo de faturamento. Nosso método de teste será chamado. Primeiro, adicionamos o comportamento do método de venda do serviço de loja de penhores que chamado com o primeiro documento é Dan e o segundo argumento como 20, ele deve retornar 30. Agora vamos afirmar se o comportamento é realmente feito afirmando se o método de célula dessa interface e o valor real e o valor 30 são iguais. Então, vamos apenas verificar se esse método celular, bem, na verdade é chamado online 29. E também vamos verificar se o método da célula, os argumentos do inquilino 20, o que é chamado de uma vez online 20 também. Quando nós executamos estes, como você pode ver aqui, diz que a tarefa do corredor de testes Maine era. Invocado, que era essa tarefa aqui. Tensão anti-confiança para verdadeira. branco resultou em verdade. Bem, isso porque ele iterou durante todos esses anos getfield e literalmente completou nove anos porque nosso método de teste não teve falhas. E então ele imprime que os resultados foram bem-sucedidos. Estes, o que o B é verdadeiro, significa. Tudo aconteceu quando plantamos aqui, nosso método celular foi chamado. Foi chamado, de fato, uma vez. Agora vamos verificar o que acontece. Se quisermos verificar se o método da célula com a varredura de argumentos em 30 foi chamado. Se executarmos cada filmagem, informe-nos que não foi chamado com os valores 1030, mas os valores reais 1020. E como você pode ver aqui no teste de tarefa render principal, ele diz que os argumentos são diferentes. Queríamos que os argumentos fossem 1030, mas a invocação real que aconteceu na linha 29, como dito aqui também, onde 1020. Então, ele nos especifica a falha em detalhes, como instruímos a fazer no teste Turner online e também imprime para nós que o resultado não foi bem-sucedido, então foi falso. Agora vamos continuar verificando este 1020, então ele deve devolvê-lo. Tudo bem, mas agora vamos verificar se a célula do método com o parâmetro padrão 20 do objeto simulado do tipo punch up service foi realmente chamada duas vezes. Então, novamente, ele deve nos avisar e deve retornar falso quando o executarmos. Como você pode ver aqui, novamente, ele retorna false. E especificamente a dívida dos EUA, o método de teste falhou. E a função de célula de serviço da loja de penhores com esses parâmetros queria ser chamada duas vezes. Então é isso que queremos que isso aconteça. Isso é o que especificamos que isso aconteceria. Mas, na verdade, o número de invocações, foi uma vez. Isso é bastante simples porque foi chamado Apenas uma vez aqui na linha 26 não é chamada. É só especificar que quando Scott você deve retornar 30. Portanto, isso não é realmente uma chamada para ele executa C. O método Verificar é extremamente útil para que possamos verificar se o fluxo está especificado em nosso teste foi realmente executado. Não só que os métodos que queremos que você chame foram realmente chamados, mas também os tempos em que foram chamados. O fato de ter especificado que essa profundidade, as coisas que deram errado, é novamente muito útil porque você pode ver em um nível mais profundo o que deu errado exatamente. E você pode depurar com muita facilidade, você está testando e vê o que acontece de errado. Talvez seja na sua mesa especificando a coisa errada ou no seu método real. O método tem muitas outras funções complementares reais como essas vezes funcionam aqui. E vamos passar por eles em detalhes nas futuras palestras. Mas para este, eu só queria mostrar rapidamente nosso projeto de configuração e também esses recursos da verificação. Novamente, iterando através deles que a função foi chamada com determinados parâmetros e os tempos iguais chamados para outras funções que foram complementares com o método verify em Mockito parece interessante para você. Sugiro que você fique por aqui nas futuras palestras. E novamente, sou muito grato você ficar comigo até o final deste. Estou ansioso para ver vocês também no próximo. 9. Verifique o intervalo de chamadas de métodos: Olá pessoal e bem-vindos de volta a este tutorial da estrutura de testes do Mockito, onde entendemos melhor como podemos usar esse framework específico para testar melhor nossos métodos escritos no linguagem de programação de Java. Nesta palestra, vamos continuar entendendo o método de verificação do framework Mockito, mais em profundidade. E você vai fazer isso por meio alguns outros métodos experimentais que podem funcionar com esses métodos de verificação e também alguns outros métodos relacionados para verificar o método. O projeto que estamos vendo, o que é apresentado na última palestra. Era o da aplicação do edifício com a superfície da loja de penhores, o serviço de perfuração novamente com a interface e a aplicação do edifício. Enquanto uma classe concreta que estava usando o serviço de loja de penhores no método de bytes. O aplicativo de construção. Esta é a classe em que temos nossos testes unitários reais escritos, nós Mockito. E esta é apenas uma classe real que executará todos os testes que temos. Algum snarky é apenas o aplicativo de faturamento após a aula. E da última vez, analisamos o método de verificação para verificar se a função foi chamada. Além disso, analisamos o método complementar Times que estava trabalhando com verificação da ordem para verificar um número exato de vezes que o método foi chamado. Mas mais do que esses tempos funcionam, existem outras funções complementares que funcionam com esse método de verificação do Mockito e são novamente muito úteis quando queremos testar por unidade nossos métodos. É útil novamente para verificar com muitas vezes o método natural de vidro que estamos testando foi executado. Primeiro de tudo, você precisa se lembrar da sintaxe geral desse método de verificação, que é a palavra-chave verify. E então ele pode tomar como parâmetros, em primeiro lugar, o objeto da classe que você deseja testar em nossa classe, é o mercado da superfície das lojas de penhores. Em seguida, ele pode opcionalmente usar um segundo parâmetro que é uma função. Veremos o que essa função faz em um minuto. Mas após essa verificação real, verifique as datas do método o argumento apenas o objeto de Demócrito que queremos testar. E, em seguida, a sintaxe especifica o método dessa classe com parâmetros reais. Ele verifica não apenas o método do gráfico que especificamos como o primeiro parâmetro, mas também seus parâmetros. Agora, voltar ao segundo argumento é opcional, mas novamente seja entregue ao método verificado. Ele especifica os tanques que essa função teve custos reais podem fazê-lo. Ele pode ser vezes. E falamos sobre essa última vez, como eu disse, que especifica quantas vezes esse método real com esses argumentos reais foi chamado. Mas também pode ser pelo menos no máximo e a rede pelo menos especifica se o objeto da classe como o primeiro parâmetro dado ao método verify e seu método com esses argumentos foi chamado neste teste pelo menos. E então cada um toma uma parte integral quanto ao número de centavos é chamado ou célula máxima. Você pode colocar um limite aqui, mas não apenas isso, também podemos ter a função de rede, que novamente é muito útil porque é basicamente o oposto da função de verificação simples que verifica se a função de dívida foi chamada. A segunda função complementar aqui, que nunca garante que o método desse objeto em que esses parâmetros específicos nunca tenha sido chamado. Além disso, do que essas funções complementares que podemos dar como parâmetros verificados ao longo do vidro marcado Arctic Dr.. Também temos o método para verificar não há mais interações. Isso leva o objeto simulado como um parâmetro. O que isso faz, verifica se todas as interações foram verificadas. Ele elimina a causa real dos métodos com esses objetos de classes. E verifica se todos esses custos verificados. E se houver interações não verificadas nesses objetos marcados, ele retornará false nele. Especificaremos que, como você pode ver neste momento, não há interações não verificadas. Como o método celular é o único que está sendo chamado e ele realmente é chamado online. 29 é que eu configurei para a linha 39. Não existe um método não verificado do serviço de perfuração do objeto. Se executarmos o teste neste ponto, você poderá ver que ele retornará verdadeiro e como tudo é verificado. Mas então, na linha 40, chamei o método cell novamente no grupo de objetos de serviço. E desta vez vou escrever novamente o verificar não há mais interações. O que essa função faz, ela verifica até o ponto em que está escrita. Portanto, somente antes disso, se há interações não verificadas de métodos do objeto que ele recebe como parâmetro 41. Agora, eu novamente especifico essa função apenas que online 40, chamei o método do soco de serviço. Como você pode ver, com os argumentos de 1020 DC menos importantes. Mas o importante é que depois que eu chamo isso, eu não verifiquei de forma alguma. Então, se executarmos isso agora, quando chegar às direções normalmente muito finas aqui, sentirá que é falso. E como você pode ver, ele diz especificamente muito detalhe que saber as direções onde um talão, linha 41, como dissemos especificamente com essa função. Mas encontramos a interação do serviço de loja de penhores simulados em 940. E também o manteria adicional para sua própria lista de referência de todos os locais que foram feitos para esses objetos simulados on-line 40 não foi verificado. Online, 29 quarta-feira briga. E diz que esse sinal aqui significa que a implicação real não estava lutando. Como você pode ver as informações online 40, que é essa em que não é verificada. E o 29 online, que é este, foi verificado. Portanto, não há ponto de interrogação lá. Então, se além disso retornar false, como você se lembra, esse foi o resultado da linha 13 de saber se o resultado da classe Alcorão chaminé do testador de aplicação de construção de vidro foi bem sucedido ou não. E no nosso caso, não foi bem-sucedido. Então, isso foi sobre isso para este tutorial em que analisamos novamente alguns outros métodos complementares no método de verificação de múltiplas doses. E também olhamos a última interação mais para entender como ela funciona. No próximo tutorial, vamos dar uma olhada na ordem dos custos que são feitos e como podemos verificá-los também. Novamente, usando a palavra-chave verify. Se isso soa interessante para vocês, estou ansioso para ver vocês lá. Mais uma vez. Obrigado por ficar comigo. Após o término desta palestra. 10. O curso de InOrder: Ei pessoal, e bem-vindos de volta a este Mockito, tutorial de estrutura de teste de unidade Java, onde entendemos melhor como podemos testar por unidade nossos métodos escritos na linguagem de programação do Java. Nesta palestra, vamos continuar falando sobre o método de verificação, o framework Mockito. E mais especificamente do que isso, vamos verificar nesta palestra, o altar da invocação sobre os métodos de entre objetos. Em nossa aula de testes. Podemos usá-lo na classe de ordem, como você pode ver aqui, para verificar a ordem das invocações de diferentes métodos em nosso objeto simulado. Na verdade, podemos pular alguns métodos que queríamos verificar. Mas os métodos que queremos verificar devem ser invocados na ordem para que você possa pular essa cadeia, é claro, a qualquer momento que você quiser, mas a cadeia detunhada verificando precisa estar na ordem real que você o fornece no objeto em ordem que você cria. Você não pode ignorar custos entre o custo que você está tentando fazer. Com o objeto em ordem. Olhando para o código na tela, você pode ver na linha 40, como eu disse, declarei um objeto em ordem do tipo em ordem, que é uma interface que está disponível na estrutura Mockito. E isso realmente levará um tipo de objeto em ordem, simulado, o único parâmetro. E, em seguida, usando os objetos em ordem que criamos, podemos chamar nele o método verificado que novamente está tomando, como sabemos, como o primeiro parâmetro, o objeto simulado que temos na classe de teste. E, opcionalmente, pode usar outro parâmetro que especifica o número de vezes que a chamada foi feita. E esse é o Phi díspar. Temos a sintaxe que conhecemos agora, pontuar a função que queríamos testar para obter o código do objeto simulado e, em seguida, seus parâmetros. Linha sólida 41. Estou muito bem com o objeto em ordem, se a célula de serviço soco com o argumento 20 foi invocada e tente depois. Verifico se o método de célula do grupo de objetos com os argumentos então em 30 foi chamado duas vezes. E depois disso, estou testando se o método de ligação com os argumentos de 1035 do grupo de objetos de serviço foi chamado. Estamos novamente verificando a ordem das invocações do discurso no mercado. Objeto com eles para classificar e, além disso, verificar o método. Como você pode ver, mudei um pouco o código antes dessa chamada de método. E online 30 temos a célula de serviço da loja de penhores com a célula argumento 20. Este é o início da verificação das invocações de encadeamento. Então temos online 35362 cos do método celular com os argumentos é feito em 30. E você pode ver que é isso que estamos testando na linha 42. E, finalmente, on-line para D3, estamos testando se o método de ligação que documentamos o padrão 35 foi chamado de próximo, qual táxi foi H pode ver online 35. Neste momento, se executarmos essa classe, você pode ver que ela vai retornar verdadeira. Mas o que acontece, por exemplo, se em vez de chamar o método com os argumentos, então em 35 eu chamaria de documentos padrão 45. Com eles ainda funcionam bem teoricamente agora você pode ver na tela que não funciona. E comer novamente especifica em detalhes, o que é um recurso muito útil que a verificação de inorder, foi falha e o método 35 foi desejado, mas não invocado. Era procurado em qualquer lugar após a seguinte interação, que é a 1030. Mas essa invocação real nunca foi chamada. Ec2 está esperando o 1035, ele realmente conseguiu 45. E o método da função objeto de serviço com o argumento padrão cinco nunca foi realmente chamado na sequência. Esse erro falso foi dado aqui. Isso foi sobre isso com a função em ordem disponível na estrutura múltipla pode ser muito útil se você quiser verificar uma sequência de chamadas que você faz em sua classe de teste. Espero que você tenha tirado algo desse tutorial. Muito obrigado pessoal por ficarem comigo até o final deste tutorial. E eu vou te ver no próximo. 11. Matches de argumento: Olá pessoal e bem-vindos de volta ao tutorial de pequenas cetonas. Nesta palestra aqui, vamos discutir Mockito, matchers de argumentos e, mais especificamente, ser Amy argument matcher no framework demo Quito. Esses são componentes muito importantes para a estrutura Mockito e veremos o porquê em apenas um momento. Agora entrando um pouco nas coisas sobre as quais já discutimos, Mockito nos permitiu criar os objetos simulados e também adicionar comportamento para eles. A forma como o comportamento foi adicionado foi pelas palavras-chave quando e depois retornar a palavra-chave, o objeto simulado. E lembre-se que tínhamos a palavra-chave when e, em seguida, o parâmetro tomou a função de objeto simulado de dívida e também seus parâmetros. E, em seguida, a palavra-chave return seguida pelo documento. O que esse método dos Objetos Marcados com esses parâmetros específicos deve ser lido lá. Foi assim que a Dinamarca. Vamos adicionar comportamento específico, comportamento marcado, é claro, aos objetos do nosso mês apenas para que possamos fazê-los retornar exatamente o que queremos. Agora, é claro, até este ponto em que você vê qualquer dobro aqui, nós tínhamos valores reais como você vê esses sujos aqui. Essa era uma maneira bastante genérica de zombar do comportamento de um objeto simulado. Mas os matchers de argumentos fracos tardios do Mockito fazem uma maneira bonita, direta e muito mais ampla basicamente permitir que você marque esse comportamento. Vamos supor que quiséssemos marcar o comportamento para qualquer argumento do tipo dado. Nesse caso, podemos usar essa matriz de argumentos da qual estou falando. Eles são definidos na classe Mockito, matriz de argumentos e são métodos estáticos. Como você vê, nós só, podemos chamá-los aqui. Conversamos sobre qualquer objeto relacionado a eles. Podemos chamá-los por conta própria. Como você pode ver, em vez de realmente escrever valores específicos aqui, podemos escrever essa função dupla. E o que isso fará, ele retornará 34, na verdade, quaisquer valores duplos recebidos como parâmetros no mesmo método do serviço Objetos marcados, LB da classe de serviço. E como você pode ver, fiz um monte de afirmações aqui que têm um monte de argumentos diferentes que são bem diferentes uns dos outros. E para cada um deles, especifiquei que ele deveria retornar 30. Esta é apenas uma maneira de testarmos que esse comportamento adulto aqui com o argumento importa em Mockito está realmente funcionando. Se clicarmos com o botão direito do mouse sobre ele e clicar em Executar, você verá que, para cada um desses métodos de célula com todos esses argumentos diferentes, esses métodos realmente retornam 30, podem vê-lo retorna verdadeiro. Se você se lembrar que foi o resultado do método bem-sucedido, o método de classe errado no JUnit. Para o argumento da nossa classe de testes. Na verdade, funciona. Portanto, essa matriz de argumentos é muito útil novamente, se você quiser fazer um comportamento geral simulado e você nem se importa com os argumentos que a função recebe. Para qualquer argumento que ele possa receber, você só deseja retornar o mesmo resultado. Talvez porque você quer testar o método e há outro método dentro desse método e você entrou no mercado. Então você só quer comer essa função e nenhuma outra função. E se houver alguma outra função, você foi zombar deles para retornar valor estético, o que neste caso seria, como eu disse, 30. E nesse cenário, as dívidas são algo muito valioso que o Mockito permite que você faça, além do método N duplo. Claro que comemos qualquer booleano e assim por diante. Para cada tipo de dados que você possa pensar, qualquer método, você pode substituir qualquer tipo de dados que possa ser dado como um argumento para o método Where. Mas muito obrigado por ficarem comigo até o final desta palestra. E no próximo, vamos discutir espiões. Dentro da estrutura Mockito, vamos dar uma olhada no que exatamente eles são e como eles podem ser úteis para perguntar ao testar nossos métodos por unidade. Então isso soa interessante para você. Estou ansioso para ver vocês. Lá. 12. Espião: Olá pessoal e bem-vindos de volta a este tutorial do Mockito, onde entendemos melhor como podemos testar por unidade nossos métodos escritos na linguagem de programação Java. Nesta palestra, vamos discutir sobre Spice, Mockito framework. E também entenda o que exatamente eles são e como eles podem ser úteis em uma jornada. Para escrever esses testes unitários, podemos usar um espião Mockito para zombar parcialmente de um objeto. zombar parcialmente de um objeto é zombar do objeto de dívida. Mas quando criamos esse espião realmente fora de um objeto, esses métodos reais dos objetos são chamados, mesmo sendo objeto simulado. Agora, eu tenho na tela uma implementação que será um ótimo exemplo para essa definição e ajudará você a entender exatamente o que é Spice. Você está familiarizado com este projeto na Intel J, não tínhamos criado o aplicativo aqui. E também objeto simulado. O objeto simulado foi injetado no prédio a aplicação, que na verdade era um método concreto. Agora, em nosso método de teste, em primeiro lugar, adicionei o comportamento que o serviço de loja de penhores, que era o objeto marcado no caso de o método celular dele ser chamado com dois duplica qualquer coisa, são argumentos então H2, H3, caneta suja. Agora o que eles fizeram, declarei um objeto do tipo de aplicativo de faturamento e atribuo a ele um espião no objeto do aplicativo de faturamento. Então o que eu fiz, eu chamei neste objeto de pizza o método da célula, largura, os argumentos de 1020. Classe de aplicativo de faturamento morto. O método celular. Eu o implementei para retornar e imprimi-lo na tela, a soma dos dois números que são dados como parâmetros. Depois disso, também criei um objeto do tipo serviço de loja de penhores online 34, e eles são designados para comer o SPI do objeto de serviço da loja de penhores. Esse era, na verdade, o objeto simulado nesta classe de teste. E o que eles fizeram. Além disso, imprimi o método celular desse objeto espião com os 2323 argumentos. Se isso não fosse um espião do serviço de loja de penhores, ele deveria retornar 30 porque é isso que fazemos. Se o método de célula do objeto de serviço da loja de penhores for chamado com duas duplas, então deve, por padrão, retornar 302223 são duas duplas. E quando executamos isso, você pode ver que antes de tudo, este retorna 30. Porque então e 20 é 30. E eu especificamente imprimo estritamente na tela a soma dos dois parâmetros. Além disso, ele retorna 0. E por que isso está retornando 0? Porque o objeto de serviço soco é, na verdade, de um vidro simulado, que era apenas uma interface. E o método da célula não é realmente implementado, então ele retorna o duplo padrão, que é 0. Se isso não fosse um espião, e tivéssemos aqui em vez de SPI para o serviço de loja de penhores. Você pode ver que, por padrão, ele retornará 30. Como você pode ver aqui, porque é isso que o comportamento desta declaração de retorno não precisa fazer. Então. Essa é a diferença entre um objeto marcado com comportamento ADD e um objeto espião não marcado. O espião do objeto simulado chamará o método real desse objeto. Também podemos usar em vez da classe Spy para chamar método real, método em um objeto marcado para chamar o método real. Isso também é uma variante aqui, mas não é recomendado e é recomendável usar um espião para essas marcas parciais. E a principal razão para isso é porque o espião que as galinhas que temos é realmente instanciado. Quando criamos um objeto simulado, o macaco TO cria uma instância de um objeto, que praticamente apenas o esqueleto dele. Portanto, com o mínimo, e pode haver uma chance de que essas dependências necessárias não sejam inicializadas quando o mercado estiver sendo criado com o Mockito. E isso pode levar a resultados ruins no final. E é por isso que o tempero realmente preferido em vez do método código abaixo, método que também está disponível neste contexto. Então, espero que vocês tenham tirado algo desse tutorial e entendam o que são espiões e como eles podem ser úteis para nós. Obrigado novamente por ficar comigo até o final desta palestra. E estou ansioso para ver vocês no próximo.