Product Backlog Building

Product Backlog Building [RESUMO].002

Scrum é uma metodologia ágil para gerenciamento de produtos, baseado em desenvolvimento iterativo e incremental. O seu ciclo inicia com uma lista de funcionalidades desejadas para o produto, priorizada pelo cliente, então o time escolhe as funcionalidades que se compromete em desenvolver, geralmente em uma iteração de 2 a 4 semanas.

Podemos notar que esse ciclo é bem definido, tendo como ponto de partida o Product Backlog, mas o Scrum não tem nenhuma definição de como construir um Backlog. Sempre nos deparamos com as perguntas:

1. Como chegar ao Backlog?
2. Como construir algo que tenha valor?
3. Como encontrar a real necessidade do cliente?

Tentando responder essas perguntas, depois de diversas experiências em vários clientes, nasceu o “PBB – Product Backlog Building”. O PBB tem como principal objetivo ajudar na construção de um Backlog de forma compartilhada, construindo um entendimento compartilhado, levando todos os envolvidos a um entendimento alinhado do domínio do negócio, ou seja, todos compreenderem o contexto do negócio.

Product Backlog Building [RESUMO].005

A dinâmica do Product Backlog Building (PBB) consiste em um processo de construção do Product Backlog utilizando o Backlog Canvas como ferramenta. Essa dinâmica leva todos os envolvidos do negócio a uma experiência prática de elaboração e definição de um Product Backlog Efetivo totalmente consistente e alinhado com os valores de negócio do cliente.

Product Backlog Building [RESUMO].006

PBB é representado por um canvas (Backlog Canvas) que tem um fluxo bem simples e de fácil compreensão, principalmente para facilitar o entendimento do cliente, pois sua participação é de suma importância nesse processo de construção. A dinâmica do PBB ajuda a descobrir novos itens para o Product Backlog, com uma abordagem bem alinhada com o negócio do cliente.

Backlog Canvas.001
IDENTIFICAÇÃO: A primeira etapa é identificar o projeto ou produto que será construído.

PROBLEMAS: Nesta etapa o ponto de partida é identificar e compreender o Estado Atual pontuando um conjunto de problemas, neste momento as partes interessadas buscam de forma colaborativa a mesma compreensão do estado atual, pontuando os problemas que desejam que sejam resolvidos. É importante conhecer o problema antes de criar a solução.

EXPECTATIVAS: Nesta etapa é importante identificar o Estado Desejado, alinhando suas expectativas aos PROBLEMAS do estado atual, para que, de uma forma compartilhada, todos os envolvidos possam alinhar suas expectativas.

PARTES INTERESSADAS: Nesta etapa saiba quem são os usuários, papéis e responsáveis envolvidos no negócio. Alinhando seu contexto de negócio, suas atividades de negócio e suas expectativas e objetivos.

ÁREAS DE NEGÓCIO: A partir desse momento, identicado as PARTES INTERESSADAS, identifique as suas ÁREAS DE NEGÓCIOS.

ATIVIDADES DE NEGÓCIO: Em seguida, identifique as ATIVIDADES DE NEGÓCIO de acordo com suas respectivas ÁREAS DE NEGÓCIO já identificadas, as atividades que cada PARTE INTERESSADA realiza dentro do negócio, mapeando na sequência de uso da esquerda para a direita. Descreva a ATIVIDADE DE NEGÓCIO com uma breve descrição da atividade, sempre pontuando o “Problema” e a “Expectativa”.

FUNCIONALIDADES: Finalizando as etapas, para cada passo da ATIVIDADE DE NEGÓCIO, escreva as funcionalidades que satisfaça, podendo representa-las por User Stories ou modelo ARO. Construindo a lista de funcionalidades, podendo organizar(priorizar) verticalmente o que é mais importante.

Essas são as etapas de forma resumida do “PRODUCT BACKLOG BUILDING”. Etapas que compõem o Canvas:

[Identificação > Problemas > Expectativas > Partes Interessadas > Áreas de Negócio > Atividades de Negócio > Funcionalidades]

Product Backlog Building [RESUMO].025 *As três últimas etapas são baseadas no conceito do FBS (Feature Breakdown Structure) do FDD.

 

O fluxo de uma forma linear ajuda a organizar a visão geral do negócio e alinhar o valor de negócio, a compreenção e o que o projeto irá agregar ao final, junto com a ferramenta “Backlog Canvas” que ainda deixa todo o levantamento de requisitos organizado de forma visual.

Product Backlog Building [RESUMO].024

 

Espero que tenham gostado e que seja bastante útil para seus projetos.

 

Product Backlog Building [RESUMO].008

 

 

Referência:

Agile Estimating and Planning – Mike Cohn
Agile Software Requirements (Lean Requirements Practices for Teams, Programs, and the Enterpreise) – Dean Leffingwell
User Stories Applied: For Agile Software Development - Mike Cohn
Discover to Deliver (Agile Product Planning and Analysis) – Ellen Gottesdiener and Mary Gorman
Succeeding with Agile – Mike Cohn

Entrega Contínua com Ruby on Rails, GitHub, Code Climate, Travis CI e Heroku

Não se espante com a quantidade de tecnologias que o título do artigo expõe, pois é apenas a linha de frente de um arsenal de ferramentas que executam nos bastidores de cada plataforma. O que veremos a seguir é apenas um passo a passo de como podemos implementar um ambiente automatizado para publicar uma aplicação na web, de ferramentas muito utilizadas na comunidade Open Source mas que algumas pessoas ainda não conhecem.

Entrega Contínua

No livro Entrega Contínua – Como Entregar Software de Forma Rápida e Confiável, Jez Humble e David Farley falam do objetivo como profissionais de desenvolvimento, que é de entregar software útil e funcional aos usuários o mais rápido o possível. Os autores citam alguns antipadrões comuns de entrega de versão como:

  • Implantar software manualmente
  • Implantar em um ambiente similar ao de produção somente quando o desenvolvimento estiver completo
  • Gerência de configuração manual dos ambientes de produção

Eles descobriram que para alcançar o objetivo da Entrega Contínua – tempo de ciclo curto e alta qualidade – precisamos entregar versões frequentes e automatizadas de nosso software. A entrega rápida também é importante porque permite que você descubra quais correções e funcionalidades implementadas de fato são úteis. Para mais detalhes, acesso o recurso Entrega Contínua.

Ferramentas

Ruby on Rails é um framework para desenvolvimento de aplicações para a web. Consiste em desenvolvermos a aplicação nas convenções que ele nos dá. Mas, para isso você tem que dominar a linguagem por trás da cortina, Ruby. Não bastando, terá também que obter conhecimento de HTML, CSS e JavaScript. Conhecimentos de banco de dados também são fundamentais.

GitHub é uma rede social para código-fonte, onde você e seu time podem hospedar seus projetos. Códigos Open Source podem ser hospedados de graça. Para projetos privados você terá que pagar um de seus planos. Caso você tenha um projeto privado e queira hospedar de graça (com algumas limitações), recomendo o Bitbucket. Mas se você não domina os comandos básicos do gerenciador de controle de versão Git, é de fundamental importância o seu aprendizado.

O Code Climate é uma plataforma que automatiza a revisão de código-fonte. Através de um conjunto de ferramentas, é feita uma análise estática do código da aplicação para gerar relatórios de pontos onde deve-se melhorar a escrita do código. Ele detecta duplicação, más práticas, nível de complexidade, vulnerabilidades, cobertura de testes entre outros. Ele utiliza a métrica GPA como forma de indicar a qualidade geral do código da aplicação.

Travis CI é um serviço de Integração Contínua na nuvem. Ele é integrado com o GitHub e oferece suporte para várias linguagens.

Heroku é uma plataforma como serviço (PaaS), dando a possibilidade de publicar sua aplicação com um simples git push. Criando sua conta, você pode hospedar suas aplicações nas linguagens suportadas.

Implementação

Com o domínio em programação na linguagem Ruby e conhecimentos do framework Rails, você deve criar testes para sua aplicação, pois não existe Integração Contínua sem testes automatizados. Utilize o framework de testes que achar melhor. Entre eles, o UnitTest e RSpec.

De posse das configurações básicas do Git em seu computador e de uma conta no GitHub você deve realizar o push de sua aplicação para o repositório remoto.

Agora vamos visualizar alguns screenshots para guiá-lo melhor:

Configurando o Code Climate

1. Clique no botão “Login” para acessar o Code Climate.
01_code_climate_home

2. Clique no link “Log in with GitHub” para acessar o Code Climate com sua conta do GitHub.
02_code_climate_login

3. Clique no botão “Add Open Source Repo” para adicionar um repositório público hospedado no GitHub. Perceba que se você possuir uma conta privada no GitHub e também pagar um dos planos do Code Climate, também poderá configurar seus repositórios privados.
03_code_climate_adicionar_repositorio_-_dashboard

4. Na caixa “GitHub repo name”, informe o caminho do repositório público e depois clique no botão “Import Repo from GitHub”.
04_code_climate_importar_repositorio

5. Aguarde enquanto o Code Climate gera as métricas do projeto.
05_code_climate_gerando_analise_do_repositorio

6. O Code Climate gera vários resultados para que você possa analisar a qualidade do código de sua aplicação. Observe a graduação de cores do quadro “Classes by Rating”. A faixa verde mostra o grau de qualidade de seu código, as faixas amarelas, laranjas e vermelhas mostram que você deve agir na melhoria do código. Você pode ver mais detalhas na aba “Issues”.
06_code_climate_repositorio_adicionado

7. Na aba “Settings”, opção “Test Coverage” você pode configurar sua aplicação para quando os testes forem executados no servidor de Integração Contínua, também gerar o relatório de métricas de qualidade do Code Climate.

07_code_climate_cobertura_de_testes

8. Ainda na aba “Settings”, você pode acessar a opção “Badges” para optar pelo formato de sinalização do Code Climate no arquivo README do seu projeto.

08_code_climate_badges

Configurando o Travis CI

1. Também será utilizado sua conta do GitHub, então acesse-o clicando no link no canto direito superior chamado “Sign in with GitHub”.

09_travis_login

2. Ao lado da aba “Recent” clique no botão com sinal de “+” para adicionar um repositório do GitHub

10_travis_adicionar_repositorio

3. Escolha sua conta ou projetos que você participa. Ative a integração com o Travis CI simplemente clicando no botão “ON” ao lado do nome do repositório.

11_travis_escolher_o_repositorio

4. Na tela anterior, perceba que existe um ícone de uma ferramenta. É nele que você pode acessar mais detalhes da configuração da integração do Travis CI com seu reposítório.

12_travis_yml

5. Para poder obter o “Badge” do Travis CI e adicioná-lo no arquivo README de seu projeto, vá para o início do seu projeto no Travis CI e clique no “Badge” que fica no canto direito superior, como mostrado na tela abaixo:

13_travis_badges

6. A documentação do Travis CI é muito abrangente podendo ser acessada por esse link. Dê uma atenção especial aos GUIDES.

14_travis_guides

7. Em REFERENCE, você encontrará tópicos avançados e como o Travis CI funciona por dentro.

15_travis_reference

8. Em INTEGRATIONS, você pode estudar como integrar o Travis com outras ferramentas. Leia o conteúdo do link “Code Climate” para entender melhor como foi realizada a integração exemplificada no artigo.

16_travis_integrations

9. Em DEPLOYMENT, você encontrará como integrar o Travis CI com vários sistemas de publicação de aplicações em nuvem. Leia o link “Heroku” para compreender a integração exemplificada no artigo.

17_travis_deployment

10. Abaixo, temos o momento da finalização da execução dos testes em RSpec no Travis CI. Perceba na linha 2975 a geração do relatório de métricas de qualidade no Code Climate. Você receberá um e-mail quando os testes não forem realizados com sucesso, podendo agir em cima disso. Outros e-mails também podem ser cadastrados para serem avisados também.

18_travis_CI_with_codeclimate_and_heroku

11. A partir da linha 2982, temos o momento da publicação da aplicação no Heroku. Essas telas podem ser acompanhadas na interface do Travis CI. Toda vez que for realizado um push no repositório do projeto no GitHub, você poderá acompanhar o processo em tempo real.

19_travis_CI_deploy_in_heroku

12. A cada atualização do projeto no GitHub, você poderá acompanhar no Code Climate a evolução da qualidade do código.

20_code_climate_PC_now

Arquivos importantes para configurar

1. Vamos dar atenção especial para os arquivos .travis.yml e README.md do projeto.

21_github

2. O arquivo .travis.yml é onde vamos configurar o ambiente do Travis CI (clique no arquivo e depois no botão Raw para vê-lo como na imagem abaixo). É configurado a linguagem e versão. Serviço de banco de dados utilizado. Quais comandos serão instalados e executados antes da bateria de testes. Da linha 12 à 14 é configurado a integração com o Code Climate. Da linha 15 à 19 é configurado como o Travis CI vai publicar sua aplicação após os testes serem executados com sucesso. Mais detalhes sobre a configuração do arquivo, leia aqui.

22_github_travis_yml

3. O arquivo README.md é onde são adicionadas instruções de como configurar o projeto.

23_readme_badges

4. No exemplo da tela anterior, clique no arquivo e depois no botão Raw para vê-lo como na imagem abaixo. Você perceberá que o conteúdo do arquivo possui trechos do “Badges” copiados do Code Climate e Travis CI. Simples assim.

24_readme_badges_raw

Heroku

1. Como dito antes, o Heroku tem suporte para uma gama de linguagens e através de seus plugins, pode-se utilizar vários serviços.

25_heroku_devcenter

2. O Heroku já configurado, você pode monitorar as publicações realizadas pelo Travis CI pela aba “Activity”. E a partir de então, publicar sua aplicação com um simples git push para seu repositório hospedado no GitHub.

26_heroku_builds

Considerações finais

Foi um tutorial curto e de nível intermediário para quem já conhece um pouco das ferramentas citadas e deseja melhorar o controle da qualidade do código e diminuir o números de tarefas na hora de publicar uma aplicação. Caso você deseje outros artigos aprofundando melhor um dos temas e ferramentas citadas no artigo, deixe um comentário.

Você pode ver o resultado a partir dos links abaixo:

https://github.com/tasafo/palestras-coletivas

https://codeclimate.com/github/tasafo/palestras-coletivas

https://travis-ci.org/tasafo/palestras-coletivas

http://palestrascoletivas.com/

Espero que tenham gostado e até a próxima!

Gestão Visual

Um imagem em uma cartolina, com alguns post-its em sua empresa pode ser mais eficiente do que qualquer software que gere “n’s” relatórios com gráficos complexos que nem todo mundo sabe interpretar.

mulher-post-it-33278

O termo “Gestão Visual” é um sistema com diferentes técnicas de planejamento e melhoria contínua, que nos permite com um simples olhar, saber a situação atual dos projetos apoiando a alta gestão e integrando de uma forma colaborativa e transparente. No Kaizen é uma parte fundamental do famoso sucesso do Sistema de Produção ‘Just in Time’ da Toyota.

A “Gestão Visual” , vem nos permitir saber como andam as coisas na empresa, sem precisar perguntar para alguém ou mesmo consultar um computador. A informação está à alguns metros de distância, podendo estar em um simples post-it.

Segue algumas ferramentas que irão nos ajudar:

- Canvas;

- Kanban;

- Roadmap;

- Gráficos estatísticos;

- Diagramas de fluxo (Fluxogramas, Organogramas, Mapas de Fluxo de Valor e Mapas de Processo);

- Etc.

É importante ressaltar que não basta colocar um quadro de tarefas, uma cartolina colorida com informações dos projetos nas paredes da empresa. É preciso sim, que a equipe tenha o entendimento de cada recurso visual e que as equipes em conjunto com a gestão interajam em um fluxo contínuo de aprendizado e melhoria.

12-canvas-parede

Canvas

No canvas você vai direcionar para o equipe a visão de negócio do seu projeto. Existem vários modelos de canvas e você pode criar o seu de acordo com a necessidade da empresa.

Kanban

Kanban

No kanban você terá o fluxo de trabalho em tarefas, tornando transparente para a equipe e para a empresa a situação atual do projeto. Para o kanban também existem variações.

Roadmap

Roadmap

Com o Roadmap é possível você comunicar e planejar a visão de futuro para o produto que está sendo desenvolvido, nele você tem a visão geral do projeto com seus marcos de entrega, podemos chamar de linha de vida do projeto. A tomada de decisão da equipe com a gestão deve ser baseada no roadmap, o que antes ficava apenas no antigo gantt chart e visível apenas para a gerencia. Hoje fica transparente para toda a empresa.

Burndown

Burndown

Burndown normalmente é usando no uso do SCRUM com Kanban, com ele é possível analisar o progresso da equipe. O gráfico representa a quantidade de trabalho que falta ser feito no eixo vertical (y) versus o tempo no eixo horizontal (x).

Aqui apresentado são só alguns exemplos, mas no mundo da Gestão Visual a sua criatividade é que manda. Quanto mais transparente for o seu e o trabalho da equipe para a empresa, pode ter certeza que o feedback será mais frenético. Os problemas serão mais visíveis e as tomadas de decisões em conjunto com essas ferramentas tornará os times e a empresa mais integrada.

Recomendo:

- Video: A importância da Gestão Visual(Rodrigo de Toledo e Daniel Teixeira) https://www.youtube.com/watch?v=2CqzbVMeJdw (Palestra A Importância da Gestão Visual e como incluir um deficiente visual na gestão visual feita no Agile Brazil 2012)

- Video: Inclusão do deficiente visual na gestão visual(Daniel Teixeira)   https://www.youtube.com/watch?v=3fp7V-e62R8 (O vídeo expõem um caso no TRE-RJ, onde durante a adoção de métodos ágeis encontraram um obstáculo diferente do que se costuma encontrar. Carlos é um deficiente visual e trabalha como desenvolvedor, e aqui está uma parte da história de como estão conseguindo modificar as noções de gestão visual.)

#tasafoemacao com Manoel Pimentel: ESCALANDO A GESTÃO ÁGIL COM SAFE (SCALED AGILE FRAMEWORK)

Galera,
 
Convidamos toda a Comunidade a estar presente em mais um #tasafoemacao com Manoel Pimentel:
Tema:ESCALANDO A GESTÃO ÁGIL COM SAFE (SCALED AGILE FRAMEWORK)“.
Data: 09 de outubro 2014
Hora: 19:00hs
Local: Auditório – CESUPA – Centro Universitário do Pará – Endereço: Av. Alcindo Cacela, nº 1523., Umarizal, Belém, Pará, Brasil
Garanta sua vaga fazendo sua inscrição no Palestras Coletivas:
Lotação: 100 pessoas.
Totalmente Gratuito.
 
Escalando a Gestão Ágil com SAFe(Scaled Agile Frameworks)
Ao longo dos anos, a adoção de métodos ágeis avançou de forma concreta dentro das organizações.  Cada vez mais as empresas estão usando Agile em mais times, mais projetos, mais produtos e, envolvendo diferentes áreas da organização.  Todo esse avanço gerou um importante amadurecimento na forma de adotar Ágil. Esse amadurecimento também é norteado pelo objetivo de fazer todo o ciclo de desenvolvimento ágil cada vez mais conectado com as visões e anseios estratégicos da organização.
 
Dessa forma, é importante entender que para fazer Agile rodar em grandes empresas, será preciso responder perguntas como:
  • Como rodar ágil em contextos envolvendo vários times (ágeis e não-ágeis)?
  • Como sincronizar o trabalho desses times?
  • Como coordenar o resultado do trabalho de times distribuídos geograficamente?
  • Como priorizar demandas em produtos robustos e dinâmicos?
  • Como ser ágil e estar em conformidade com modelos de governança?
Por todo esse cenário, é vital lançar um olhar além e estender o raio de soluções a serem combinadas para fazer uma adoção ágil em larga escala.  Para fazer uso dessa visão pragmática, é importante entender:  a essência do pensamento Lean, os princípios do Product Development Flow, como organizar de maneira ágil um programa organizacional e, como usar de maneira sincronizada e cadenciado os benefícios do Scrum e do XP (Extreme Programming). Para encapsular essa abordagem, uma solução que tem sido praticada por grandes empresas é o SAFe (Scaled Agile Framework(SAFe).  SAFe É um modelo baseado em Scrum, XP, Lean e muita experiência de campo, para a implementação de práticas ágeis em grande escala. Ele reconhece o que tipicamente tem funcionado bem no trabalho de times ágeis, na forma de fazer gestão de programa e na maneira ágil tratar um portifólio de demandas organizacionais.  
 
Essa palestra visa apresentar uma visão inicial dessas soluções, explicar como o SAFe organiza esse trabalho em grande escala e principalmente, promover um espaço para um rico debate sobre como usar essa visão para resolver problemas reais das organizações.
 
Palestrante:
Manoel Pimentel Medeiros – É Agile Coach/Trainer na Adaptworks Treinamentos e Presidente da Agile Alliance Brazil. Trabalha há mais de 18 anos na área de TI, onde possui uma profunda experiência em ajudar, como coach ou trainner, a transição/experimentação Ágil (Scrum, XP, FDD, Lean, SAFe) em grandes e complexas organizações (por exemplo: Sicoob, Bancoob, Stefanini, Oi, GVT, XP, Petrobras, ITA, Itaú, Localiza). Manoel é um dos pioneiros no movimento Ágil no Brasil. Ajudou na tradução oficial do Manifesto Ágil para o Português. É membro ativo da organização do Agile Brazil (inclusive sendo chairman da edição 2013).  Ele também é o fundador da Revisa e Blog Visão Ágil. Já escreveu para portais internacionais como InfoQ, AgileJournal, ScrumAlliance, AgileAlliance e revistas como SQL Magazine, JavaMagazine, Mundo J e outras.  Revisou e Escreveu o prefácio do Livro Agile Project Management (Editora AltaBooks) em Português e do Livro  Scrum – Gestão Ágil para Projetos de Sucesso (Editora Casa do Código). Também é um co-autores do livro Métodos Ágeis para o Desenvolvimento de Software (Editora Bookman). É o mais ativo licensed trainer de Management 3.0 no Brasil, tendo inclusive, contribuído para formação e licenciamento de outros grandes facilitadores do cenário nacional. Também é detentor das certificações SPC (Scaled Agile Academy), CAC (Alpha Coach – WorthEthic), CSM, CSPO e  CSP (ScrumAlliance).

 

Nos vemos lá! ;)

#tasafoEmbarcAÇÃO no Barco Hacker!

O Ta safo! recebeu o convite e irá embarcar em mais uma expedição de um projeto sensacional, o Barco Hacker! Iniciativa tocada pela galera da Casa da Cultura Digital de Belém.

É juntar a fome com a vontade de comer, queríamos muito realizar um lance desses. A programação está só o creme e será uma excelente oportunidade de conversar com uma galera de diferentes segmentos e falar um pouco de nossa experiência de alguns anos pelo Tá safo!, através de um debate sobre: “Os desafios do empreendedorismo em comunidades”.

O evento será realizado no dia 19 de setembro a partir das 18hs com a saída do barco do Píer do Hotel Good Mar, Rua Professor Nelson Ribeiro, 132, Bairro do Telégrafo.

A programação completa, inscrições e mais informações estão no link https://doity.com.br/barcohacker. Até lá, marujos e marujas!

PS.: Quem não sabe nadar, não precisa levar bóia de braço. Terá colete salva-vidas no barco : P

E obrigado Breno Peck pela foto do barco no veropa.

Tá safo! no Agilidade@Recife 2014

AR2014-ChamadaMail

Tenho a satisfação de participar da organização, e levar junto a bandeira do Tá safo!, do evento que a cada ano leva para Recife palestras e workshops de qualidade sobre a temática da gestão e desenvolvimento ágil de software. Também terei a oportunidade de palestrar mais uma vez, agora para falar um pouco sobre Técnicas e ferramentas para manter a sanidade em uma startup. Que venha mais um Agilidade@Recife! Segue o anúncio do evento:

No próximo dia 02 de outubro, das 8h às 18h, no Auditório do Banco do Brasil (Av. Rio Branco, s/n), vai acontecer o Agilidade@Recife. O evento, que conta com o apoio do Softex Recife e do Porto Digital, é um conjunto de palestras e workshops com o objetivo de criar um ambiente colaborativo para que a comunidade de software da região compartilhe e agregue conhecimento de valor durante todo o dia de encontro, sobre temas relacionados aos métodos ágeis de desenvolvimento de software.

Nesta sétima edição do evento, o Agilidade@Recife pretende reunir novamente desenvolvedores, líderes, gerentes, executivos, pesquisadores, estudantes e outros interessados na adoção de métodos ágeis no desenvolvimento e gestão de produtos de software. Serão 6 palestras, 2 sessões práticas e um momento para open spaces (dinâmica onde os próprios participantes discutem temas de interesse comum).

A programação do evento conta com palestrantes conhecidos nacionalmente quando o assunto é agilidade, como Alisson Vale, Alexandre Magno, Marcos Garrido, Juliano Ribeiro e Dairton Bassi, entre outros. Empresas como Globo.com, Instituto Nokia de Tecnologia, Liferay do Brasil e TV Globo também estarão marcando presença no evento, narrando suas experiências na área.

As inscrições estão abertas e devem ser realizadas através do acesso ao link: http://www.eventick.com.br/agilidaderecife2014. Para mais informações acesse o site do evento: http://agilidaderecife.com.br/ ou envie um e-mail para agilidaderecife@gmail.com.

Mocks e Stubs com Rspec

mock-vs-stubs-clerb-presentation-1-728

Mocks e stubs são conceitos, muitas vezes de difícil compreensão, principalmente para desenvolvedores iniciantes em testes automatizados. Eu mesmo levei um tempinho para compreendê-los e nem sei se entendi muito bem. Por trás disso existe uma nomenclatura um tanto confusa e que não ajuda muito na compreensão dos conceitos. Vamos analisar como o Rspec trabalha com eles utilizando a biblioteca rspec-mocks.

Muitas vezes quando estamos escrevendo nossos testes, precisamos utilizar de objetos falsos. Em determinados cenários, o objeto real pode não estar disponível ou é necessário utilizar algum recurso externo que pode deixar o teste lento. Algumas vezes não precisamos testar o estado do objeto mas sim seu comportamento. Chamamos esses objetos falsos de Test Doubles ou Dublês de teste. Mocks e stubs são dois dos tipos especializados de doubles e são os mais utilizados.

Stubs

Simulam implementações dos objetos reais através de métodos que retornam valores pré-determinados. São métodos pré-configurados com as informações necessárias para a execução dos testes. Abaixo temos um exemplo de declaração de um test double.

  double = double('user', name: 'Tyrion Lanister')

O primeiro parâmetro é uma descrição do dublê que é usada na documentação e nas mensagens de falha. O segundo é o método stub setado com um valor qualquer. Vamos a um exemplo melhor. Queremos testar o método calculate_total_price da classe Order.


class Order
  attr_reader :total

  def calculate_total_price itens
    @total = 0
    itens.each { |item| @total += item.price }
  end

end

Podemos testar esse método sem instanciar o objeto real Item, através de stubs.


describe Order, "#calculate_total_price" do

  let(:itens) { [double(price: 10.0), double(price: 45.5)] }

  it "calculates the total price" do
    order = Order.new
    order.calculate_total_price(itens)

    expect(order.total).to eq(55.5)
  end

end

Na linha 3 setamos um array de doubles ao invés de uma array de objetos da classe Item. O teste irá passar. Isso é muito útil em testes  de unidade,, pois não precisamos acessar o banco de dados para pegar os dados do objeto Item que poderia ser um modelo do Active Record.

Mocks

São doubles pré-programados que irão criar expectativas que deverão ser satisfeitas pelos testes. Podemos usá-los quando queremos testar a chamada de uma api externa, por exemplo. Vamos dar uma olhada no exemplo abaixo.


class Westeros

  def geolocate(place)
    Geocoder.coordinates(place)
  end

end

O método geolocate da classe Westeros tem uma chamada da bilblioteca geocoder que retorna as coordenadas geográficas de um dado endereço. Precisamos testar se o método coordinates de Geocoder irá mesmo retornar as coordenadas? Acho que não. Os desenvolvedores da gem já fizeram isso. Precisamos mesmo é garantir que o método geolocate de Westeros irá chamar coordinates de Geocoder com o parâmetro correto. Para isso vamos usar um mock.


describe Westeros, "#geolocate" do

  it "retuns coordinates" do
    place = 'Ponta Tempestade, Westeros'
    westeros = Westeros.new

    expect(Geocoder).to receive(:coordinates).with(place)
    westeros.geolocate(place)
  end

end

Na linha 7 definimos as expectativas. Geocoder deve executar o método coordinates com place como argumento. O teste passa. Dessa forma testamos a interface de geocoder e não seu funcionamento interno. Um detalhe a parte é a dsl do rspec que deixa a leitura muito simples e agradável proporcionando um modo bastante elegante de se escrever testes.

conclusão

O rspec possui muitas outras inúmeras funcionalidades no que diz respeito a test doubles e testes regulares. A prática e a experiência irão melhorar ainda mais o entendimento dos conceitos de mocks e stubs, assim como os conceitos de testes automatizados. Existem uma infinidade de artigos sobre o assunto na internet. Vale a pena dar uma pesquisada no assunto.

Referências

https://github.com/rspec/rspec-mocks

http://www.infoq.com/br/articles/mocks-Arent-Stubs