Arquivo da categoria ‘behavior-driven’

Rodrigo Yoshima

Rails Summit Retrospective

Tive uma dúvida nos últimos tempos.

Fiquei bem surpreso como nos dois últimos eventos de Java falamos muito sobre Ruby e Rails (TDC e JustJava). Digo isso não nas palestras, mas sim nos bate-papos. Eu confesso! Nos últimos eventos gostei mais das conversas nos intervalos do que das palestras.

A minha dúvida era: “Se num evento de Java se fala muito sobre Ruby, o que se fala num evento de Ruby?”. Para minha surpresa, o que se fala muito num evento de Ruby é BUSINESS. Isso mesmo! O Rails Summit da Locaweb teve muito bate papo sobre negócios e como ganhar dinheiro com software. O que mais me chamou a atenção foi uma “certa aversão” ao termo Agile nas conversas dentro e fora das palestras. O Guilherme Chapiewski ficou meio revoltado quando eu disse que logo vão exigir “Scrum Masters Certificados” nas licitações (sim… eu ouví esse papo nas minhas andanças no Planalto Central). O Shoes foi categórico: “Não falo sobre Agile”. Já com o Vinicius Teles, batemos muito papo sobre negócios, produtos, não trocamos uma palavra sequer sobre Agile. Também estavam presentes muitos outros agilistas, railers, gujeiros, alunos da Aspercom e etc…

Leia o restante deste artigo »

Rodrigo Yoshima

Outubro bombando em Eventos

Nos próximos meses temos eventos interessantes, e estarei participando de alguns. Minha agenda é bem agitada como colunista da MundoJava e proprietário-instrutor-consultor da Aspercom. Além disso, a Aspercom também tem projetos na mesma linha que a Improve It. Falar sobre esses projetos é assunto para outro post, até porque preciso de autorização de clientes e parceiros.

Rails Summit da Locaweb

O Fábio Akita (AkitaOnRails) está fazendo um barulho enorme no blog dele e com razão. Faz um bom tempo que não vejo um evento com uma seleção tão interessante. Muita gente de fora e também feras brazucas. O fato da Locaweb ter disponibilizado o Passenger nos seus planos pode sim agitar a adoção do Rails.

468x60summit - 468x60summit

O que me interessa nesse evento: Chad Fowler e sua palestra sobre “A Evolução de um Framework”; Jay Fields que falará sobre “A Imaturidade dos Testes de Desenvolvedores”; Carlos Villela sobre “Uma Web de Documentos”; George Malamidis e a implementação RESTful do Ruby on Rails; David Chelimsky (do RSpec) sobre Behavior Driven Development (uma das minhas linhas de estudo atuais); Vinícius Manhães Teles sobre empreendedorismo com Ruby on Rails.

Link para o evento: http://www.locaweb.com.br/railssummit

Falando em Agile

falandoagile - falandoagile

Neste evento da Caelum também estarei marcando presença, o pessoal da ThoughtWorks vai estar por lá e a palestra do David Anderson promete muito.

Link para o Evento: http://www.caelum.com.br/falando-em-agile/

Com certeza tirarei algumas fotos para postar uma retrospective aqui.

Rodrigo Yoshima

Requisitos Executáveis com FIT

logo - logo
Na edição 29 da revista MundoJava escreví sobre o dia a dia de um agilista. Continuando uma série sobre TDD na Revista MundoJava nesta edição escreví um artigo sobre a ferramenta FIT para automação de testes. O artigo teve participação de Ivan Sanchez e James Shore.

O Ivan Sanchez foi o cara que fez o treinamento CSM junto comigo no início de 2007, e teve o azar de cair no mesmo grupo comigo! O Ivan é um agilista e grande evangelista de Coding Dojos. Atualmente trabalha na Signature Technologies no Reino Unido.

James Shore (Jim) é lider do projeto FIT (criado por Ward Cunningham), atua em projetos ágeis desde 1999 (sim, existem projetos ágeis antes do Manifesto Ágil) e escreveu o livro “The Art of Agile Development“.

Uma das coisas legais de escrever na MundoJava é ter contato com esses caras lá de fora e poder trazer estes conteúdos para nossa comunidade. Escrever com o Scott Ambler e o Jon Kern foi muito legal. Este artigo com o James Shore também foi especial. Infelizmente eu recebo mais não do que sim, mas ainda vou continuar insistindo com os mestres! Ah… vocês querem o trecho grátis do artigo, certo? Então aí vai:

Uma das questões comuns é: Quem escreve os dados de teste? Pela estratégia do FIT, os dados de teste são escritos a “oito mãos”. É comum que tudo inicie com o usuário ou cliente e com o analista de negócios, capturando cenários de teste iniciais que formatam alguns critérios de aceitação. Depois disso, um desenvolvedor pode verificar a formatação das tabelas, referenciar as Fixtures e assim obter o RED do ciclo TDD. Ao mesmo tempo os testers podem participar colocando mais cenários. Logicamente, o FIT é uma ferramenta ágil. É importante uma rica colaboração face a face de todos os envolvidos para que exista sucesso na adoção dessa abordagem.

Uma atenção especial deve ser dada ao trabalho do analista de negócios. Atualmente é comum que esses profissionais capturem requisitos em documentos texto e alguns diagramas. Geralmente este tipo de abordagem é muito pobre para o desenvolvedor, principalmente se não existe uma comunicação rica entre eles. Comunicação com documentos é uma forma muito pobre de comunicação (veja artigo “Modelagem Ágil”, MJ 27). Um modelo de requisitos em texto é muito deficiente na maioria das vezes. Pare para pensar: Não existe teste sobre documentos em texto e nem compilador para diagramas!
Rodrigo Yoshima

O que é o FIT e porque se importar com ele? O FIT é parte do seu arsenal ágil de prevenção de bugs. Diferente da abordagem tradicional para a qualidade, onde focamos em encontrar e remover defeitos, as práticas ágeis focam-se primeiramente em previnir que bugs sejam criados. Isso nos leva a alguns resultados impressionantes. Times ágeis experientes produzem poucos bugs por mês.

As “práticas ágeis de engenharia” pregadas pelo Extreme Programming (XP) são parte da solução. Essas técnicas como Test-Driven Development (TDD), programação aos pares, propriedade coletiva do código, design simples e trabalho energizado previne a maioria dos erros de programação. Elas garantem que o código faz exatamente o que os programadores pretendiam que ele fizesse.
James Shore

FIT ou Framework for Integration Testing é uma ferramenta excepcional no auxílio ao desenvolvimento de um software. O cliente (ou analista de negócio) escreve tabelas mostrando o que o sistema deve fazer através de exemplos. O desenvolvedor escreve o código das fixtures, que são as classes que ligam as tabelas com o sistema que está sendo implementado. A partir daí as tabelas se tornam “executáveis” e as regras definidas podem ser validadas de maneira automatizada.

FitNesse é a implementação mais popular de FIT, que funciona na forma de um wiki. Cada página representa um teste executável e é possível executar múltiplas páginas para validar um sistema como um todo. Além disso, por se tratar de um wiki, favorece a colaboração entre cliente e desenvolvedores, podendo servir como uma ótima base de conhecimento sobre o sistema que está sendo construído.
Ivan Sanchez

O FIT é uma ferramenta muito interessante: Uma coisa que chama a atenção em projetos onde utilizamos o FIT é que produzir as tabelas com os dados de teste é uma atividade de modelagem intensa. Modelar não é fazer diagramas, é muito mais profundo do que isso!

Já nas bancas!

Surgiu uma discussão na UML-BR sobre como modelar um Jogo da Memória. O rumo da conversa foi sobre pensar nas classes e modelar antes, influenciados por um post anterior. A thread sobre o jogo da memória está aqui:

http://br.groups.yahoo.com/group/UML-BR/message/9936

Eu comecei a pensar nesse problema e até pretendí mandar um diagrama de classe demonstrando uma provável solução, porém, este “mini” sistema é muito mais direcionado a comportamento do que a classes propriamente dito.

Atualmente tenho estudado bastante Ruby. Concordo com o Rodrigo Kumpera quando ele diz que Java “educou a grande massa sobre bom desenvolvimento OO” mas “cheira naftalina”. A linguagem continua em evolução, porém, algumas coisas no Java me irritam muito. A maior delas é o turnaround imenso. Volta e meia precisamos reiniciar o servidor. No Ruby as coisas são mais fáceis. A comunidade Ruby faz as coisas serem mais fáceis. Para resolver o problema do Jogo da Memória quis usar o RSpec. Para instalá-lo bastou:

gem install rspec

No Java já me imaginaria instalando uns 20 jars irritantes.

Voltando ao assunto “Jogo da Memoria” iniciei esse desenvolvimento pensando: “O que é necessário para jogar?” Por sorte sou pai de 2 filhas pequenas e tinha um Jogo do Mico aqui. Não é exatamente um Jogo da Memória mas serve pois são cartas aos pares. Com as cartas na mão me lembrei do nosso amigo Kent Beck e a “Spike Solution”: “Eu não preciso de 15 pares para testar o Jogo da Memória. Eu só preciso de 2 pares para ter uma solução plausível que diz que minha aplicação funciona.”

DSC00110 - DSC00110

Uma mesa, um jogador e dois pares de cartas: Tudo que é necessário para um Jogo da Memória completo.

Com essa metáfora e esses “elementos” na mão o próximo passo seria como montar a “partida” focado em comportamento. Pensei no meu próprio comportamento quando montei esse cenário para a foto.

comportamento1 - comportamento1

Este seria o comportamento esperado do jogo logo ao iniciar. Pense no objetivo do jogo. Nós queremos ganhar certo? Logo no ínicio nós precisamos ter um parâmetro palpável para saber se ganhamos ou não. Logicamente no ínicio do jogo ele não está ganho. A implementação desses comportamentos nesse momento está listada abaixo:

implementacao1 - implementacao1

A prática do BDD é extremamente próxima do TDD. BDD não é nada novo. É apenas uma visão unificada de TDD e DDD fornecendo uma Ubiquitous Language para essa abordagem de desenvolvimento.

OK. Neste momento temos um Jogo montado. Um aspecto importante para este jogo é saber comparar cartas. Vamos adicionar este requisito como comportamento.

comportamento2 - comportamento2

Vamos agora implementar isso na classe Carta.

implementacao2 - implementacao2

Cada vez que faço um passo desses eu tenho requisitos (comportamentos) e implementações em paralelo. Minha especificação (jogo_memoria_spec.rb) vai direcionando o desenvolvimento da minha aplicação (jogo_memoria.rb). Cada passo é mensurável e pode ser avaliado como válido. Além disso, minha aplicação possui as características de um design emergente. Dados e comportamentos só são adicionados quando realmente há embasamento em requisitos.

Com a capacidade de saber quando cartas são iguais, o próximo passo seria poder “virar” uma carta e em seguida virar outra carta que não seja par com a primeira. É um critério de falha com relação ao objetivo de ganhar o jogo. O comportamento e a implementação do comportamento estão abaixo:

comportamento3 - comportamento3

implementacao3 - implementacao3

Vamos agora definir o comportamento e a implementação para o sucesso de virar duas cartas encontrando o par:

comportamento4 - comportamento4

Com esses últimos comportamentos seria possível avaliarmos a nossa implementação do Jogo da Memória com 4 cartas. Para efetuar o download da aplicação completa acesse os links abaixo:

jogo_memoria_spec.rb
jogo_memoria.rb

O que eu tenho gostado muito em aplicar técnicas de TDD é ter requisitos executáveis. O BDD só nos traz mais ferramentas conceituais. O BDD tem foco no próprio comportamento e não em testes dos comportamentos. A evolução de ferramentas como o próprio RSpec poderá nos trazer a um mundo novo onde nunca mais teremos documentos de requisitos desatualizados.

Cada dia que passa a especialização e a divisão do trabalho fazem menos sentido no desenvolvimento de software.

(amigos rubistas: não sejam muito rigorosos com meu código, estou aprendendo ainda)