Promoção compre 2 e leve 3:TDD, SCJP e JEE

 
olá Pessoal, 
O post de hoje é uma promoção exclusiva para os leitores daqui do blog, para não falar muito aqui, confira a seguir:
Promoção compre 2 e leve 3
Pensando em investir em sua carreira, aprimorar seu conhecimento e economizar?
Conversando com a editora consegui essa promoção relâmpago. Se você queria comprar os meus livros, mas a grana estava curta, então aproveite!! Essa é a oportunidade de comprar 2 livros e o terceiro sair de graça. É uma promoção exclusiva para os meus leitores e seguidores. Abaixo falo com mais detalhes e mostro que o terceiro sai de graça mesmo.
 
Como funciona ?
 
É muito simples, veja os passos:
 
1. Você preenche a solicitação no formulário no final post com os seus dados, já incluindo o endereço de entrega; 
 
2. Em até 2 dias úteis você recebe um e-mail com os dados para pagamento; 
 
3. Envia o comprovante de pagamento; 
 
4. Despachamos o livro em até 1 dia útil; 
 
 
O prazo de entrega e Frete
 
Depende da sua localidade. O produto será enviado como PAC e pode levar até 15 dias.
 
 
Simulação – Promoção de verdade 
 
É promoção de verdade!! Veja que o terceiro livro sai de graça. A seguir uma simulação considerando os valores de venda do livro no site da editora (em outros sites o valor pode sofrer variação para mais).
 
1.Guia do Exame SCJP – R$ 39,20 
 
2.JEE com Frameworks – R$ 47,20
 
3.TDD na Prática – R$ 36,80 
 
Total: R$ 123,20 + Frete 
 
 
Na promoção de hoje você paga:
 
1.Guia do Exame SCJP – R$ 39,20 
 
2.JEE com Frameworks – Grátis
 
3.TDD na Prática – R$ 36,80 
 
Total: R$ 76.00
 
Frete : R$ 15.00 
 
Valor Total Investimento: R$ 91,00 
 
Iai vai ficar parado? A promoção é ate o dia 14/07/2013. 
Abracos, vou ficando por aqui.
see ya!!

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

Série Agile:Como escrever boas user stories?

Olá Pessoal,

Mais um post, da série Agile e veremos como escrever boas user stories. Este é um ponto importante, pois uma boa user story deve ser entendida tanto pelo team técnico quanto pelo cliente/PO.

Lets…

Sabemos que escrever as user stories, é “trabalho” do PO, mas em teoria, porque na prática quem vai escrever ou é o ScrumMaster ou o time. Nem sempre dá para seguir o que temos na literatura de acordo com a realidade do mercado. Mas o objetivo deste post não é esse e sim tentar responder: “as use stories do seu projeto são boas?” Ou seja, para seu cliente, ela é valiosa? Ele olha para ela e sabe de fato o que significa que será feito?

Lendo o livro JR The samurai Agile (o qual em breve vou publicar um review), em um dos seus capítulos ele aborda sobre o assunto e vi que já cometi alguns erros quando precisei escrever algumas user stories alguns meses atrás em um projeto pessoal. Um dos problemas foi não ter percebido o quanto estava técnico alguns pontos na user story. E o JR fez uma pergunta interessante: “Se seu cliente estivesse com fome e apenas as duas opções abaixo ele teria para escolher, o que é mais claro para ele? “

1. Estória: Ernie’s Tech Diner

  • C++     3 days
  • Connection pooling    2 days
  • Model-View_presenter pattern          5 days

2.Estória: Sam’s Business Pancake House

  • Create user account 3 days
  • Notify subscribers of new listings 2 days
  • Cancel subscription 1 day

Com certeza a estória dois faz mais sentido para o negócio do cliente. Os termos são simples e fáceis de serem entendidos. E o mais comum: quando somos muito técnico é escrever como na primeira estória e SM deve ficar atento com isso caso todo o time esteja participando da escrita das US. E em outro exemplo o JR trouxe que podemos ser técnicos e o cliente entender. A estória abaixo não perde seu valor: 

Add database connection pooling: é dificil para o cliente entender

Mas…

Reduce page load time from 10 secs to 2 secs.

Parece que faz mais sentido para o cliente e você já sabe o que acontece nos bastidores para atingir o objetivo da user story (US).

Enfim, qualquer US deve ser do tipo INVEST, ou seja, independente, negociável, valiosa, estimável, small (pequena) e testável.

  • Independente: sua história não pode depender de outras histórias, caso isso aconteça é preciso quebrá-la.
  • Negociável: é que ela pode ser alterada e adaptada e não fechada.
  • Testável: que seja possível criar testes que valide aquela história. Algo como:

Login with expired:

Testable:

            – redireciona logins expirados

            – mostra mensagens de erros apropriadas

  • Small & Estimatable: não tem que ser grande e sim pequena para que possa ser estimável, quanto maior, mais difícil é estimar.

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

See ya!

Série Agile: O tester

Olá Pessoal,

No post de hoje vou falar o que os Testers fazem enquanto o time desenvolve. No post anterior falei sobre o conceito de Done, e um dos tópicos para considerar um item concluído tinha que ser qualificado por um tester. Mas, o que o tester faz enquanto não tem nada pronto para ser qualificado? É isso que vamos ver no post de hoje.

Lets go…

E o que o tester faz enquanto o team desenvolve? Vai para Praia?

Antes de mais nada queria reforçar o que eu acredito: todo projeto agile deveria ter no minimo 1 Tester. Falo isso porque vejo alguns comentários na comunidade, às vezes, que com Agile não precisa mais dos Testers. Não sei de onde tiraram isso. Os Testers são membros do time e eles são tão importantes quanto os demais membros (infelizmente há ainda pessoas que olham assim dev X testers), são profissionais que tem uma habilidade de qualificar se aquilo que você fez de fato atende ao requisito do cliente, do contrário ele vai encontrar falhas e vai te direcionar onde resolver. Quando um  Tester pega um bug, não quer dizer que você, Desenvolvedor, é ruim ou no pior, um animal de quatro patas. Não é isso. Eles apenas dizem: “olha, faltou isso”. Porém alguns desenvolvedores não olham assim e se sentem ofendidos. Há vários fatores que contribuem para um bug no sistema, não é apenas questão técnica. Mas isso não entra nesse post, pois é uma longa história :). Mas de fato, o que os Testers fazem enquanto os desenvolvedores ainda estão trabalhando nos itens do Sprint? Vão à praia e voltam daqui uns dias?

Se isso fosse verdade, eu queria ser Tester \o/, mas a resposta é: Não. Eles não vão à praia. Aqui temos uma pilha de trabalho para eles:

  • Montar os use cases de cada item (ou itens) do Sprint backlog etc;
  • Preparar o ambiente de teste (homologação);
  • Interagir com o team, tirando dúvidas dos itens;
  • Sincronizar informações com o product owner.

Tudo isso consome tempo e é bom ter tudo pronto antes do primeiro item ficar pronto. Os Testers participam das reuniões diárias (afinal de contas ele é membro do time), do planning, então nada melhor que já ir montando os testes seguindo a ordem de prioridade dos itens que foi definido pelo PO.

É preciso adicionar um item no quadro de task para o Tester e ir acompanhando as atividades dele durante as daily meeting?

Não ou Sim. Eu acredito que não, na primeira Sprint eu não faria isso e talvez na próxima sim, como tudo é um aprendizado, vamos ver o que podemos aprender no Sprint 1 com esta abordagem. O motivo de não querer adotar um item exclusivo para o tester é por realmente não achar necessário, exceto se o PO colocasse isso no product backlog, onde acredito que ele não fará isso, porque o PO não está muito interessado no “como” será feito ou qualificado, desde que atenda aos critérios de qualidade e requisitos de negócios estabelecido por ele.  Uma forma seria adicionar uma task a cada item do tipo “preparação para teste” e em uma das daily meeting o desenvolvedor iria dizer: “olha, hoje termino o desenvolvimento e amanhã já tenho o item pronto para ser qualificado”. Então o tester já pegaria a task, colocaria  na coluna de “in progress” e dizendo “tá,eu vou começar a preparar o ambiente hoje e amanhã as X horas posso iniciar a validação”.  Essa foi uma abordagem que achei válida e bem prática até o momento, pois consegui manter a iteratividade entre tester e desenvolvedores em um projeto que participei no mês passado.

E você, como lida com esse cenário? Compartilhe sua experiência :).

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

Abraços, see ya!

Série Agile: Conceito de Done

Olá Pessoal,

No post desta semana vamos ver o que colocar no conceito de Done do seu projeto Scrum. Claro que não há uma regra universal para o que deve ser colocado, pois isso vai variar de projeto para projeto. Vou abordar uns que considero mais tradicionais.

                                               O que colocar no conceito Done no projeto Scrum?

É algo que parece ser fácil de definir, mas não é como parece. Alguns projetos levam em consideração apenas o foi acordado entre o Product Owner e o ScrumMaster para adotar o conceito de Done, outros buscam um concenso com o team; qual a melhor? Não há melhor ou pior e sim aquele que se adapta ao projeto (eu particularmente preferia discutir com o meu team o que vamos considerar como Done). Claro que  a contribuição do Product Owner é importante também, porém evitaria de deixar a discussão apenas entre PO & SM. Mas seria algo como:

  • Todas as tarefas devem estar cumpridas: parece ser óbvio, mas nem é. Algo bem comum é: terminei todo o desenvolvimento, mas o build não está ok, então você precisa arrumar o build para poder concluir seu ítem. Não importa quem quebrou, mas precisa estar fixed, é esperado que quem provocou  a situação que arrume, caso esta pessoa esteja disponível.
  • Código refatorado (refactoring): sabemos que a primeira vez que vimos o código, apenas fizemos ele para que as coisas pudessem funcionar, então ter um código bem refatorado é required (se você usa TDD terá menos trabalho);
  • Pair Review: o código deve ter sido revisado por dois outros membros da equipe; (usar uma ferramenta com o review board)
  • Build passando;
  • Unit Tests passando e cobertura > 80% ;
  • Design atualizado;
  • Qualificado pelo Tester: Ou seja, teste funcional feito de preferência por um tester, pois eles são bons em encontrar bugs no menor tempo possível.

 Uma experiência que quero compartilhar com vocês é sobre o ponto de refactoring acima. É muito importante colocar ele no conceito de Done. O motivo? Quantos desenvolvedores você conhece que faz refactoring (de verdade e não apenas o rename)? Acredito você não consegue fechar uma “mão” com o  resultado, mas não só por isso. O cliente não está disposto a pagar pelo refactoring, não se esqueça disso, pois para o cliente, algo dado como Done já possui certos padrões de qualidade e refactoring na visão do cliente não agrega valor ao produto, caso for feito à parte, consumindo mais horas. E eu tenho que concordar com ele, realmente já deveríamos entregar isso quando concluímos o item do backlog, afinal de contas nós que estimamos o tempo que levaria para entregar o item e nesse momento eu deveria colocar quanto tempo levaria no refactoring. Para o cliente, não importa o como você vai fazer, desde que tenha qualidade e atenda ao que ele pediu. Então, o melhor lugar para colocar o refactoring seria no conceito de Done, assim todo desenvolvedor terá que garantir que isso foi feito, enviar o peer review, etc. Outro item que gostaria de citar da lista é o “qualificado pelo tester”, parece estranho, pois em projetos ágeis cada membro é responsável por testar e garantir que está funcionando. Bem, não podemos seguir tudo ao pé da letra ou interpretar com uma única linha de raciocínio. Em um projeto meu, seria bom e interessante eu ter um tester para ir qualificando os itens que fossem ficando prontos e no final do Sprint todos os itens deveriam passar por ele. Mas por que isso? Para garantir que de fato está funcionado. Apesar do desenvolvedor já ter testado, eu considero que não é uma tarefa fácil nós pegarmos os nossos próprios bugs, sempre vamos testar pelo “caminho da felicidade”. Os testes de fato são bons, vão testar cobrindo vários cenários com base no escopo, testar em ambiente e formas diferentes e ver o resultado esperado. Então, ter isso no conceito de Done ajuda a encontrar possíveis bugs mais cedo e ajuda aumentar a qualidade do produto.

Vou ficando por aqui. No próximo post falarei mais sobre o papel do Tester. Agora eu fiquei curioso. E você, o que coloca no seu “conceito de done” ?

Compartilhe…

Abracos, see ya!