mockito – Blog do Camilo

Fazendo Mocks com DAO Mockito

Olá Pessoal,

O post de hoje veremos como usar Mockito para coberir classes e metodos DAO. Eu particularmente gosto de usar BDUnit para testes funcionais assim, mas há quem não gosta. Para não dizer que temos apenas uma solução resolvi escrever esse post.

Lets go..

Starting..

É comum achar que não é possível chamar o método real usando mock, mas analisando a documentação vamos encontrar um cara que permite chamar o método real, usando o mesmo contexto de mock,. Isso permite manter todo seu test com mock e ainda cobrir o que é de fato necessário.

No padrão de uso da mock, o código a seguir não rola cobertura, uma vez que estamos usando a mock, então o método real não é chamado:

@Test

            public void testBuscaEmailCadastrado() {

                        user.setEmail(“camilo@”);

                      when(usuarioDaoMock.buscaUsuarioPorEmail(user)).thenReturn(user);

  assertNotNull(usuarioDaoMock.buscaUsuarioPorEmail(user));

            }

Como podemos ver na imagem acima, vermelho significa que não tem cobertura naquele código, uma vez que não há test case chamando ele direto.

E como resolver isso?

Para resolver é muito simples. Porém, antes de apresentar a solução vamos a outro fato tradicional, testar métodos do tipo void. Sabemos que com assert não é possível testar um método void, uma vez que este retorna “nada”. Mas com mock podemos chamar um método void e testá-lo, afetando assim a cobertura. Vejamos como:

O método doCallRealMethod() permite chamar o método real da mock, independente do tipo deste método. Sendo assim, void agora pode ser chamado e verificado no seu test case. É comum ver programadores tendo que converter um determinado método do tipo void para return alguma coisa só para satisfazer o test case. Sem o uso de mock (mockito) temos que fazer isso, porque não temos nenhum assert para verificar um tipo void que não retorna “nada”.

Observe na imagem a seguir o resultado, agora está cobrindo o DAO:

Note: segundo a documentação, o uso doCallRealMethod() é algo que deve ser feito cuidadosamente, pois significa que há algum tipo de complexidade no seu código, mas também não deixam de falar que há casos raros onde é possível usar the partial mock warning (é o nome que se dá quando chamamos um método real usando mock).

O code:

1 Mockito.doCallRealMethod().when(usuarioDaoMock).buscaUsuarioPorEmail(user);

2 assertEquals(usuarioDaoMock.buscaUsuarioPorEmail(user).getEmail(),user.getEmail());

A leitura do code: “chame o método real quando o método buscaUsuarioPorEmail for chamado pela usuariodaomock e passe o valor user para ele”.

Assim o mockito vai lá na classe que possui o método real e chama ele de fato, como vimos na imagem anterior, onde o código passa a ser coberto.

Um possível Problema

O único problema é que precisamos ter o banco de dados rodando, ou seja, UP para as funções que precisa consultar. Pode parecer óbvio, mas nem tanto, porque quando usamos a mock apenas, esta simula a chamada e o valor esperando independente do banco estar ON/OFF.

Resultado com o banco OFF é o seguinte:

org.hibernate.exception.JDBCConnectionException: Cannot open connection

Mas não esqueçam que ainda temos a vantagem de testar métodos do tipo void, fazendo a cobertura passar por ele. No contexto acima, na maioria das vezes vamos ter um BD ON, pois queremos ver se o nosso CRUD/DAO está fazendo o que de fato esperamos que ele faça, que é a comunicação com o BD, porém daí já estaríamos caminhando mais para tests funcionais que tests cases de fato.

Na imagem a seguir temos a cobertura em todo DAO. Observe que foi implementado um novo método que busca no banco um email e este não existe, daí verificamos se de fato o código entra no catch e este está coberto.

Cobertura antes

Cobertura depois

Mas, uma solução também é usar o banco em memoria como HSQLDB assim você poderá executar seus testes contra o banco automaticamente, ou seja, você não precisar iniciar ou parar o banco.

Vou ficando por aqui.

Abracos, see ya!!

Lançamento livro: TDD na Prática

Olá Pessoal!

É com muita felicidade que venho compartilhar com vocês mais esse “filho”. Eu não sei nem por onde começar de fato. Mas que tal pelo inicio?

Bom, a seguir falo um pouco da história dele (como todo livro meu sempre tem uma história real por trás), porque escrevi, quem pode ler, sorteio etc Vou buscar ser bem breve..

Lets go…

Agradecimentos

Fazer esta parte aqui nunca é fácil, pois são várias pessoas que contribuem para uma obra como esta: amigos, colegas de trabalho, familiares, amigo virtual, etc. E lembrar de cada um não é uma tarefa fácil. Sendo assim, estarei destacando aqueles que vieram em memória no momento que escrevo este trecho. Aqueles que contribuíram e acabei esquecendo, peço que me perdoem.

Primeiro, não poderia esquecer o meu colega de trabalho Gustavo Knuppe. Apesar dele não saber que estava escrevendo este livro, foi responsável por muitas mudanças que fiz na forma de abordar o assunto de TDD, principalmente em um artigo, no qual Knuppe foi o revisor, e nesse processo sugiram várias e boas sugestões no artigo produzido que aproveitei para utilizar neste projeto.

Um amigo que não poderia deixar de fora é o Alberto Leal. Eu diria que meu contato com mundo Agile começou devido a uma apresentação sobre refactoring que o Leal fez em alguns minutos via MSN e depois desse dia fui me envolvendo mais e mais com a técnica e quando conheci TDD e liguei o passado com o presente vi que ter conhecido refactoring com o Alberto fez uma diferença grande. Obrigado meu amigo!

À minha namorada Ellis Ribeiro, que teve a paciência e dedicação em revisar a parte ortográfica e dar sugestões de melhoria na estrutura do livro 🙂

Como tudo começou… (Era uma vez….)

Bem, primeiro nunca imaginei que um dia eu escreveria um livro sobre TDD, independente de que foco este teria. Até porque eu não sabia nada do assunto até inicio de 2010, apenas ouvia. Tinha tentado usar algumas vezes antes e fracassei em todas elas. Nunca entendia de fato como fazer os unit tests, muito menos escreve-los primeiro, mas fiquei com aquilo na cabeça. Todos (Kent Beck, Martin Fowler, Guilherme Silveira, etc) falam e conseguem, daí eu me perguntava: “o que eu estou fazendo de errado? Não vou desistir de entender direito.” Dai passou o tempo, tive que voltar a estudar devido a um projeto que precisei trabalhar em 2010 e tinha que escrever unit tests para as coisas darem certo e então fui estudando, começei a ler e pesquisar com mais detalhe. Lembro que o primeiro post que li sobre o assunto foi do Guilherme Chapiewski. Fui navegando para outros blogs, tentando entender a mecânica e praticar. Comecei a pegar o ritmo, mas confesso que naquele momento não sabia que eu fazia TDD na veia, era complicado, pra mim era código com um framework que eu testava o que escrevi. Mas cada vez que programava gostava do resultado, ficava viciado, daí decidi me aprofundar mais no assunto, e fui buscar referências “for dummy”, tanto em português quanto em inglês. Achei? Não, pois identifiquei os seguintes problemas nas obras publicadas sobre o assunto na época:

1. Era necessário ter uma certa experiência (nem que fosse muuuito básica) com a mecânica de unit test;

2. Os livros eram longos e poucos práticos para iniciantes, com exemplos esquisitos que ao término da leitura sentia falta de algo mais concreto para praticar e dizer: ‘entendi de fato com a mão na massa’. Enfim, faltava uma direção melhor para iniciantes.

E foi quando despertou de sair anotando tudo que ia aprendendo, tanto aquilo que deu certo quanto o que deu errado também. Meses depois (no final de 2010), por “ironia” do destino caiu no meu caminho o meu primeiro projeto, o qual usariamos TDD. Mesmo sendo pequeno ajudou muito, digo que foi onde tudo começou de fato, com erros e acertos, mas foi gratificante o resultado. Dai fui para um outro mais arrojado, de 1 ano, e TDD foi a base para podermos entregar o código com qualidade, menos bug, menor custo de manutenção e respeitando os prazos. Tudo isso me fez refletir. Um dia parei e olhei para tras e perguntei: “O que aprendi até hoje? Que tal criar um livro sobre o assunto? Aliás, usar minhas anotações, experiência adquirida, para ajudar quem está querendo entrar nesse mundo?” Observei nos fóruns e comunidades Java que muitos tinham vontade de aprender TDD, outros tinham tentado e fracassado, alguns nem sabiam por onde começar.

Enfim, todos os problemas que passei eram bem recorrente para todo iniciante. E foi aí que nasceu o meu livro “TDD na Prática”. Essa é a história dele.

Quem pode ler?

Essa é uma pergunta muito comum: “será que devo comprar?” Eu digo sempre o seguinte: compre o livro se você:

1. Conhece bem o básico do Java e Orientação a objetos. Olha o que eu estou falando, conhece bem JAVA e não JEE. Iniciantes ainda fazem confusão com as siglas do Java (não deveria, pois a primeira lição é saber as diferenças);

2. Sabe o que é unit tests ou tem ideia de para que serve;

3. Sabe a diferença entre unit test x Junit;

4. Quer de fato aprender TDD e saber que, no inicio, será um caminho duro, sofrido, pois não é só sentar na máquina e sair codificando. É uma forma diferente de pensar, codificar, resolver problemas, que no resultado final isso é transparente para quem olha sua aplicação e diz: “Essa eu digo 100% que foi feito com TDD, mas essa não”. A olho nú não é possível dizer isso.

5. Gosta de desafios e quebrar a cabeça;

Se você se encaixa nos pontos acima, pode adquirir um exemplar, caso contrário, eu diria que não compre :).

Como o livro está estruturado?

Bem, para quem conhece meus livros sabe que sou bem informal na escrita e gosto de dar a sensação ao leitor que estamos mais batendo um papo que lendo um livro em si. Com esse não será diferente, pois é meu jeito natural de escrever. Mas o que eu coloquei no livro?

Bom, quando começei a escrever a primeira pessoa que eu pude me espelhar era eu mesmo, aquele cara que não sabia:

– nada de TDD na prática, só ouvia falar;
– conceitos de Agile, muito abstrato ou quase nenhum;
– tanta sigla, termos TDD, Mocks, Mockito, Junit, refactoring que na prática, juntando tudo no “liquificador”, nunca sabia se o resultado final era de fato o esperado;
– e um cara que não sabia programar usando unit test; Alias, mal entendia uma classe que tinha métodos com as anotações @Test. Me perguntava “pra que realmente isso serve? como pode agregar valor na aplicação?” Só ouvia as pessoas falarem: “É bom”. “Funciona”. “Usa isso que vai ser show”, “Seus problemas acabaram, use unit test”. Mas no fundo não entendia como, e tive que aprender isso sozinho.

Então o livro segue uma ordem que, a depender em que nível você está, pode ir lendo sequencialmente. Eu diria que se é bem iniciante mesmo, vá na ordem sequencial, mas se você já sabe mocks, usar o JUnit, etc, pode pular alguns e ir para o qual lhe interessa de imediato.

Coloquei exercícios para serem feitos com o objetivo de forçar o leitor a exercitar o que aprendeu sobre TDD de formas diferentes. Vamos começando em um nível com a minha ajuda, mas depois deixo você ir sozinho, tomando suas decisões de quais testes escrever. Isso ajuda a ganhar confiança naquilo que está fazendo, o que no inicio com TDD todos se sentem desconfortável, inseguros e se perguntando: “será que estou fazendo a coisa certa? É isso mesmo?”. Enfim, espere exercícios um pouco diferentes do que você está acostumado a fazer no dia-dia. Também compartilho com o leitor como eu faço TDD e a gente vai vendo o que da certo e não da. Em alguns exercícios há respostas, para depois o leitor comparar e ver como resolvi. Não quer dizer que o seu tem que ser igual ao meu, cada um resolve de uma forma. O objetivo é que você tenha feito realizando os testes primeiro. Mas há outros que não temos a resposta. Fiz esses para que você possa olhar para o problema e garantir que atendeu ao requisito, ou seja, resolveu de fato usando TDD sem ter outra solução para preparar. Isso ajuda a ter mais confiança no que você entrega, já que todo “TDDista” sempre vai ouvir a seguinte frase: “Isso não funciona”, “Isso é coisa de nerd”. “Só funciona no mundo do Kent Beck e Martin Fowler”. Mas acostume-se com esses e outros comentários, faz parte do dia a dia, e o melhor de tudo: não se irrite. Há um capítulo que explico o Junit, Mocks, refactoring, falo rapidamente sobre Agile e Scrum.

Onde adquirir um exemplar?

Acredito que, dentro de uma semana no máximo, o livro estará disponível nas melhores livrarias, como: Saraiva, Cultura, Fnac, etc. E nas lojas virtuais: livrosdeprogramacao.com, submarino.com.br, americanas.com.br etc.

No site da editora você pode comprar: www.lcm.com.br.

Formato do livro:

O livro será disponibilizado no formato impresso (R$ 36,80) e e-book(R$ 27,80). A versão ebook só será vendida pelo site da editora.

SlideShare

Disponibilizei no slideshare alguns capítulos do livro.

Sorteio

Você tem até 02/12/2012 para realizar o seu cadastro. No dia 03/12/2012 divulgarei o resultado.

Regras:

– Não é permitido realizar 2 cadastros. E-mails duplicados e a pessoa não estará mais participando do sorteio. Então façam apenas 1 cadastro por e-mail. Lembrando que deve ser um e-mail válido, pois o contato para confirmação dos dados será feito pelo e-mail cadastrado, e o ganhador tem até 48hrs para responder, a partir da data de recebimento. Caso contrário, um novo sorteio será feito;
– O livro será enviado para o endereço informado no cadastro. Então coloque o endereço completo + ponto de referência.

Atualização:

O ganhador poderá escolher se deseja a versão impressa ou e-book.

Resultado

O ganhador foi: Rafael Oliveira

note: Um e-mail foi enviado para o ganhador o mesmo tem até 48hrs para confirmar o recebimento e dados de entrega. Caso não seja respondido em 48hrs a partir da data de envio, um novo sorteio será realizado.

Bom, vou ficando por aqui.

Demorou, mas chegou. 🙂

See ya!!

Pré-Lançamento: Livro TDD na Prática

Olá pessoal,

É com muita felicidade que escrevo este post. Realmente só quem é “pai” sabe o que eu estou sentido. Como vocês já podem imaginar está vindo ai mais um filho para se juntar aos seus irmãos “Guia do exame SCJP” e “Guia Prático JEE”. É ele o “TDD na Prática”. O livro está previsto para ser publicado até o final de junho/2012. Ainda não recebi a versão final do livro, mas assim que receber estarei disponibilizando alguns capítulos. A seguir faço uma pequena apresentação sobre o meu filhão.

lets go…

Sumario Tdd na Prática

Sobre o livro

O livro vem com um objetivo simples: “Descomplicar o que parece ser complicado”, em outras palavras O objetivo é ensinar como praticar TDD usando a linguagem de programação Java. Para muitos iniciantes em TDD, no primeiro momento parece que estamos fazendo tudo errado e que escrever os testes antes do código funcional não é nada legal. E que para superar os primeiros obstáculos, só o conhecimento técnico não é suficiente. Quando comecei com TDD passei por vários obstáculos e um deles foi encontrar livros práticos, ou seja, aqueles que eu pudesse colocar a mão na massa de verdade, ter problemas para resolver usando a técnica, etc. Os disponíveis eram bastante teórico, deixando a parte prática sobre minha responsabilidade que, como iniciante, era difícil saber por onde começar. Esses livros foram importantes para entendimento e formação da minha base teórica sobre o assunto, mas eu percebi que uma coisa era eu ter lido e outra era praticar e me ver com o Eclipse aberto e sem saber o que fazer de verdade, ou pior, me perguntar: ‘como resolver um problema usando TDD e não cair na tentação de escrever os testes por último?’. Quem não tem cão caça com gato. Tive que criar meu próprio caminho prático, onde comecei a desenvolver novas aplicações usando a técnica (venci pela persistência), em seguida surgiu a oportunidade de ir para um projeto novo na empresa que trabalhava e lá tive o espaço para desenvolver usando TDD por quase 2 anos, e nesse meio surgiu a ideia desse livro: “por que não criar um livro prático sobre TDD com base na minha experiência?”. E foi assim que comecei a escrever o livro no final de 2010, tendo como referência o Kent Beck.

O que você vai encontrar no livro:

Desenvolver aplicações Java usando a técnica de TDD;
Exercícios Práticos;
O uso de objetos mocks com Mockito;
Praticar algumas técnicas de Refactoring ;
Entender os valores do mundo Agile;
Por que TDD?
Junit;

E como sempre, dei preferência em usar uma linguagem informal e fazendo o uso bastante da primeira pessoa. O motivo é que durante seus estudos quero que tenha a sensação de estar batendo um papo comigo ao invés de estar lendo algo mais formal.

Meu desafio

Quando eu decidi escrever esse projeto foi porque me sentir desafiado (assim como os outros já publicados). É isso mesmo. Ao olhar o que tinha em mãos (anotações) mais a experiência e sofrimento com o “mundo TDD” e decepções que passei eu disse: “preciso escrever um livro sobre o assunto”. Daí reparei que escrever um livro com um assunto abstrato não seria uma tarefa fácil, uma vez que TDD, refactoring são técnicas que não se aplicam somente à linguagem Java. E daí eu comecei a entender melhor o livro do Kent Beck (TDD by example) e Martin Fowler (o de Refactoring) o quanto eles são “chatos” e sem sabor para quem é bem iniciante. E eu disse: “preciso fazer algo que empolgue o iniciante, ou seja, algo com sabor, mas que eu não venha perder o eixo principal da técnica”. E daí passei dias pensando, escrevendo, apagando, anotando, dormindo sem respostas e fui vendo como vencer esse desafio de ensinar TDD sem ferir os conceitos da técnica. Isso era o que me tirava o sossego todos os dias e não sei se consegui atingir. Acredito que sim, mas só terei a certeza quando você me escrever dizendo o que achou J. (aguardem até o lançamento…)

Quem pode ler?

O publico alvo são estudantes da tecnologia Java que querem aprender usar TDD desde o principio e tem simpatia com o mundo Agile.Se você ainda está dando os primeiros passos com Java e gosta de ser desafiado, este livro é para você. Indiretamente o livro acaba revisando alguns conceitos básicos do Java nada fora do normal, porém agora o desafio é você fazer as coisas mais simples escrevendo seu teste primeiro. Como eu já passei por isso, sei o quanto difícil é escrever os testes primeiro antes do código funcional e quando eu falo mais simples, não necessariamente é mais fácil. Se você está bem no inicio do Java, ainda dando “Hello World”, eu diria que o livro não vai ajudar muito nos seus estudos com Java, talvez atrapalhe. A minha sugestão é: aprenda primeiro os fundamentos da linguagem e Orientação à Objetos e depois retorne à todo vapor para ler o livro. Enquanto isso coloque na prateleira e não compre o exemplar.

Pensei em escrever este livro quando, ao iniciar meus estudos com Java, não encontrei um material do qual pudesse desde “pequeno” ir sendo educado com boas práticas, e fui aprendendo no dia-dia, além dos sofrimentos que tive até adquirir uma nova cultura. Se você é aquele iniciante que está a fim de colocar em prática toda essência do Java e ao mesmo tempo ir entendendo o que só ouve falar de TDD, Refactoring, JUnit, este livro é para você.

Eu particularmente diria que este é um tipo de livro que gostaria de ler depois de ter lido Head First Java da Kathy Sierra.

Agradecimentos

Fazer essa parte aqui nunca é fácil, pois são várias pessoas que contribuem para uma obra como essa: amigos, colegas de trabalho, familiares, “amigo virtual” etc. E lembrar todos não é uma tarefa fácil. Sendo assim, estarei destacando aqueles que vieram em memória no momento que escrevo este trecho. Aqueles que contribuíram e acabei esquecendo, peço que perdoem.

Não poderia esquecer o meu colega de trabalho Gustavo Knuppe, apesar dele não saber que estava escrevendo este livro, foi responsável em muitas mudanças que fiz na forma de abordar o assunto de TDD.Principalmente em um artigo sobre TDD, o qual Knuppe foi o revisor, e nesse processo, sugiram várias e boas sugestões no artigo produzido e aproveitei para utilizar neste projeto. Um amigo que não poderia deixar de fora é o Alberto Leal. Eu diria que meu contato com mundo Agile começou devido a uma apresentação sobre refactoring que o Leal fez em alguns minutos via MSN e depois desse dia fui me envolvendo mais e mais com a técnica e quando conheci TDD e liguei o passado com o presente vi que ter conhecido refactoring com o Alberto fez uma diferença e grande. Obrigado meu amigo!

Outra pessoa é meu amigo Edson Gonçalves, sempre digo que se me tornei um escritor é porque fui “batizado” por esse grande escritor e amigo, o qual já temos um laço de amizade verdadeira por mais de quatro anos. Dedicar este livro para um grande amigo como você é o mínimo que posso fazer. Nos momentos mais difíceis você sempre estava ali comigo me dando força. Abraços e tudo de bom para você meu grande amigo.

Formatos

Será vendido no formato impresso e e-book.

Enfim, pessoal essa foi a pequena apresentação do meu próximo livro. Espero que vocês gostem e curtam. Quem quiser divulgar nas comunidades eu não me importo 🙂

Abraços, qualquer dúvida só mandar.

See ya!!!

Criando Mocks com Mockito

olá Pessoal,

No post de hoje vamos ver como usar o API Mockito para criação de objetos mocks. No ultimo post vimos o que são mocks, mas eu já tinha falado rapidamente do Mockito. Usarei o mesmo exemplo visto no post passado, porém agora teremos mocks in action.

Lets go…

Usando JUnit com o Mockito

Para não ter que repetir o código anterior, neste post adicionei apenas a classe que tem o unit test. Então, vou considerar que você viu o nosso post sobre Mocks.

Agora precisamos testar a classe AlugaCarro e ver se de fato ela está retornando um objeto que possui as informações que esperamos que tenha.

Classe de teste

publicclass CarroAlugadoTest {

@Mock

private AlugaCarro alugaCarro;//my interface

public CarroAlugadoTest() {

alugaCarro = Mockito.mock(Cliente.class);

}

@Test

publicvoid alugaCarroParaCliente(){

//o caraquerecebeoscarrosalugados

CarroAlugado car = new CarroAlugado(alugaCarro);

String resultadoEsperado = “Camilo Golf”;

* aqui o clientecamiloestáreservando o carro golf

Mockito.when(alugaCarro.getNomeCliente()).thenReturn(“Camilo “);

Mockito.when(alugaCarro.getModeloCarro()).thenReturn(“Golf”);

String verdadeiroResultado = car.getAlugaCarro().getNomeCliente() + car.getAlugaCarro().getModeloCarro();

Mockito.verify(alugaCarro).getNomeCliente();

assertEquals(resultadoEsperado,verdadeiroResultado);

}

Explicado partes importantes do código

Passo 1

Precisamos fazer a mock,ou seja, “mockar” uma classe/interface, há várias formas de fazer isso, usaremos o modo mais simples, que é usar annotations @Mock na variável que vai ser o objeto e “instanciar” ela no construtor, pois quando a classe for carregada a variável será “mockada”.

@Mock

private AlugaCarro alugaCarro;

public CarroAlugadoTest() {

alugaCarro = Mockito.mock(Cliente.class);

}

Passo 2

Criamos um teste onde vamos verificar se um carro foi alugado para o cliente.

Primeiro passo foi passar o objeto “mockado” que representa “o cliente” para a classe CarroAlugado, pois é isso que ela espera receber, um objeto que alugou um carro.

CarroAlugado car = new CarroAlugado(alugaCarro);

Em seguida vamos configurar os valores para o método que recebe o nome do cliente e o que recebe o nome do carro alugado. Porém, aqui usaremos API Mockito. Essa linha de código será executada quando o método for invocado.

Mockito.when(alugaCarro.getNomeCliente()).thenReturn(“Camilo “);
Mockito.when(alugaCarro.getModeloCarro()).thenReturn(“Golf”);

A leitura poderia ser algo do tipo: “quando o metodo getNomeCliente() for chamado, então configure o valor dele para “camilo”.

Na linha seguinte, observe que chamamos os métodos, que acreditamos estarem com um valor. E ai o mockito entra in action, quando um objeto, chama um daqueles métodos, ele configura os valores que estão no thenReturn().

String verdadeiroResultado = car.getAlugaCarro().getNomeCliente() + car.getAlugaCarro().getModeloCarro();
Mockito.verify(alugaCarro).getNomeCliente();

O método verify() apenas verifica se o método foi chamado, no API Docs do Mockito, há outras pessoas de verificação, como por exemplo:

verificar se o metodo getNomeCliente() foi chamado pelo menos 1 vez, ou mais vezes;
verificar se nunca foi chamado.

O assertEquals é somente para verificar se estamos recebendo o valor esperado.

Outro teste que foi implementado:

@Test

publicvoid verificaSeUmMetodoNuncaFoiExecutado(){

CarroAlugado carroAlugado = new CarroAlugado(alugaCarro);

Mockito.when(alugaCarro.getModeloCarro()).thenReturn(“Civic”);

//verificase o metodo getNomeCliente() nuncafoiexecutado

String modeloCarro = carroAlugado.getAlugaCarro().getModeloCarro();

Mockito.verify(alugaCarro, Mockito.never()).getNomeCliente();

}

Um video

Um video do Vinicius mostra a diferença entre mock & Stubs que achei muito bom.

http://viniciusquaiato.com/blog/diferenca-entre-mocks-e-stubs/

Conclusão

Uma outra dica é você gastar um bom tempo ali na documentação do Mockito, ela é bastante rica e de fácil leitura. A API não é tão grande e muito menos complexa, basta um pouco de pratica e sabendo como usar cada recurso, tá feito.

Vou ficando por aqui e espero que tenham gostado do post.

Abracos, see ya!

Mock com Mockito

Olá Pessoal,

Hoje vou apresentar o Mockito que é uma API de Mock, que tem ganhando espaço a cada dia. No post, vou falar pra que serve aos Mocks, o que evitamos e farei “reutilização da informação” sobre o que são mocks. E para deixar tudo claro nada melhor que um exemplo feijão com arroz, para que você possa entender como usar. No próximo post veremos na pratica a criação de Mocks com Mockito.

Lets go…

Pra que serve o mockito?

Mockito é uma API desenvolvida pela Google, com o objetivo de simular um objeto real para uma classe especifica. Isso pode ajudar nos testes de unidade quando precisamos verificar a comunicação entre os objetos.

Por que usar Mock?

Usamos Mock quando temos classes que possuem dependencias, porém queremos testar apenas se uma classe está retornando o que estamos esperando.

E o que evitamos usando mock?

Evitamos de ter que criar objetos para todas as dependencias de uma classe. Ou seja, com o mockito vamos “enganar” a execução do programa, dizendo pra ele que o objeto a ser passado é de fato o objeto que ele espera.

Na pratica

Antes de apresentar os códigos, vamos precisar pegar o conceito do “negócio” e saber como os códigos trabalham.

O cenário é o seguinte:

Class Cliente : um cliente ele possui alguns atributos como id, nome.
Classe CarroAlugado: esta classe tem como objetivo de informar/representar qual carro está alugado e para quem está alugado (cliente). Então aqui já podemos ver que essa classe depende de um objeto da classe Cliente. Pois, um objeto da classe cliente que terá essas informações.
Interface AlugarCarro: temos uma interface que aluga carro, como o procedimento de alugar carro é sempre o mesmo, de ter o nome de quem está alugando + o carro que foi alugado. Então se um cliente quiser alugar um carro terá que assinar um contrato com essa interface e informar pra ela o nome dele e o carro que deseja alugar.

E onde Mocks entram nessa história?

Mocs vão entrar no momento que vamos simular que um cliente c “Zezinhi” alugou um carro “Ferrari” e vamos ver se de fato a classe tem essa reserva feita.

Os códigos a seguir:

public interface AlugaCarro {

public void setNomeCliente(String nomeCliente);

public void setModeloCarro(String nomeCarro);

public String getNomeCliente();

public String getModeloCarro();

}

Classe Cliente implementando a Interface, pois um cliente está querendo alugar um carro.

public class Cliente implements AlugaCarro {

private String nomeCliente;

private String modeloCarro;

@Override

public void setNomeCliente(String nomeCliente) {

this.nomeCliente = nomeCliente;

}

@Override

public void setModeloCarro(String nomeCarro) {

modeloCarro = nomeCarro;

}

@Override

public String getNomeCliente() {

// TODO Auto-generated method stub

return nomeCliente;

}

@Override

public String getModeloCarro() {

// TODO Auto-generated method stub

return modeloCarro;

}

A classe CarroAlugado quer receber um objeto que foi instanciado contendo nome do cliente e o nome do carro alugado, e retornar esse objeto. Que nada mais é o Cliente que alugou o carro. Lembre-se o Cliente implements AlugaCarro, então temos o relacionamento HAS-A.

public class CarroAlugado {

private AlugaCarro alugaCarro;

public CarroAlugado(AlugaCarro alugaCarro) {

this.alugaCarro = alugaCarro;

}

public AlugaCarro getAlugaCarro() {

return alugaCarro; }

public void setAlugaCarro(AlugaCarro alugaCarro) {

this.alugaCarro = alugaCarro;

}

Na edição 49 da revista MundoJ tem um artigo que escrevi junto com o Alexandre Gazola sobre o assunto. E lá detalhamos mais, eu sou suspeito de recomendar essa edição :).
vou ficando por aqui, espero que tenham gostado do post.

abracos, see ya!!