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!!

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.

  1. 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.

  1. Mockito.when(alugaCarro.getNomeCliente()).thenReturn(“Camilo “);
  2. 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().

  1. String verdadeiroResultado = car.getAlugaCarro().getNomeCliente() + car.getAlugaCarro().getModeloCarro();
  2. 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!

MundoJ Ed. 49 – Artigo Criação de mocks com Mockito

olá Pessoal,

Mais uma edição da MundoJ de nro 49 e  estou completando meu terceiro artigo com eles.Porém,este é o meu primeiro artigo com outro colunista (ótima experiência escrever em par). Junto com o  Alexandre Gazola  estamos falando um pouco sobre o Mockito e como usar a API para mockar seus objetos durante o desenvolvimento dos seus unit testes.  Não posso deixar de agradecer ao Eduardo Guerra o qual tive o prazer de conhecer no AgileVale 2011. Ao colega colunista Alexandre Gazola, foi um prazer ter escrito esse artigo com ele. Enfim espero que gostem do artigo! não esqueçam de comentar lá no GUJ.

Um pouco sobre o artigo

Para quem nunca trabalhou com mocks ou quem já trabalha, mas não com Mockito API, neste artigo há duas oportunidade: A primeira é de aprender mocks para quem é iniciante e nunca brincou antes. E a segunda de conhecer mais uma API Mock que tem sido bem aceita pela comunidade, quem sabe você pode encontrar vantagens no Mockito e migrar pra ele?!

Para saber mais, só comprando a edição. 🙂

abracos, see ya!!