Antes de tudo é bom entender o que é o tal Test Driven Development, de onde vieram boa parte das idéias por trás do BDD.

Test Driven Development prega o desenvolvimento através de pequenas iterações onde existe primeiro a escrita de casos testes que definem o que precisa ser implementado e depois a produção de código necessário para que estes casos de testes sejam atendidos. Não vou explicar pq TDD é legal, uma busca rápida no google vai lhe dar muitos argumentos.

O BDD evolui a idéia do TDD no sentido que começamos o desenvolvimento do sistema com foco no comportamento esperado pelo cliente e expressamos esse comportamento através de uma linguagem mais adequada e mais próxima da natural. Isso ajuda bastante ao discutirmos requisitos com o cliente e no próprio entendimento pela equipe: nossa documentação é nosso código.

Quando construímos nossa User Story e fizemos o Cucumber rodá-la, mesmo com tudo pendente, fizemos isso para guiar nosso desenvolvimento olhando de fora para dentro: o que nosso cliente e espera (User Story), como ele espera (AcceptanceCriterias).

A partir de agora criaremos código para atender as essas expectativas e somente isso.

Por enquanto todos os nossos passos contidos no arquivo features/step_definitions/gerenciar_pessoas_steps.rb estão marcados como pendentes através do método pending

Comecemos então pelo primeiro passo:

Dado que estou na listagem de pessoas

A primeiro momento poderíamos implementar esse passo de forma específica no arquivo features/step_definitions/gerenciar_pessoas_steps.rb

Mas vamos a uma reflexão: geralmente iniciamos os cenários partindo de um determinado ponto do sistema, seria muito interessante definir esse passo de forma genérica, assim poderíamos escrever novos cenários com passos similares, por exemplo:

Dado que eu estou em listagem de cidades

sem a necessidade de implementar um novo passo. Para isso iremos mover o pedaço de código relativo ao passo acima para um novo arquivo features/step_definitions/passos_compartilhados.rb e nele iremos generalizar o passo parametrizando-o

Onde visit é um método do webrat para “visitar” a página especificada e path_to é um helper do Cucumber para definirmos rotas em nossos passos.

Executemos o cucumber novamente:

cucumber features –language pt

Na saída do comando verificamos que não foi possível encontrar um mapeamento para “listagem de pessoas”. Faremos esse mapeamento no arquivo features/support/paths.rb

Vamos executar o cucumber novamente e verificar a saída:

Agora temos outro relato: não existe o método pessoas_path por simplesmente ainda não termos um Controller chamado pessoas. O próximo passo de bebê seria adicionar um controller para pessoas e definir a rota. De toda forma como esse é um simples crud criaremos logo um scaffold através do gerador do rspec, executamos a migration de criação da tabela de passoas e preparamos o banco de teste:

script/generate rspec_scaffold pessoa nome:string endereco:string email:string rake db:migrate rake db:test:prepare

Executamos novamente o cucumber e agora temos o primeiro passo “verde”

Temos um outro passo pendente que também pode (e deve) ser generalizado, tiramos o seguinte trecho de código do arquivo features/step_definitions/gerenciar_pessoas_steps.rb e o levamos para features/step_definitions/passos_compartilhados.rb

e o alteramos para

Executamos novamente o cucumber

Precisamos agora de um link chamado “Nova pessoa” na nossa listagem. O script de geração de scaffold já gerou um link só que com o nome em inglês: “New pessoa”. Vamos no arquivo app/views/pessoas/index.html.erb e renomeamos:

<%= link_to ‘Nova pessoa’, new_pessoa_path %>

para

<%= link_to ‘Nova pessoa’, new_pessoa_path %>

Rodando o cucumber mais uma vez:
O negócio tá melhorando, já temos 2 passos “verdes”, partimos agora para os próximos passos:

E defino nome com o valor “Fulano de Tal”
E defino endereco com o valor “Rua Sicrano, 32″
E defino email com o valor “fulano@exemplo.com.br”

Como vocês podem ver, os três passos tem a mesma estrutura, vamos generalizá-lo também. Remova o seguinte trecho de código do arquivo features/step_definitions/gerenciar_pessoas_steps.rb

e adicione o código abaixo no features/step_definitions/passos_compartilhados_steps.rb

Ao ver o saida do cucumber uma alegria: só faltam dois passos!

Salvar o registro é um passo que pode existir em vários cenários, não é algo específico deste. Moveremos então o trecho de código abaixo de features/step_definitions/gerenciar_pessoas_steps.rb para features/step_definitions/passos_compartilhados.rb

E o alteramos para:

Rodamos o cucumber novamente
Percebemos a necessidade de alterar a descrição do botão no arquivo app/views/pessoas/new.html.erb

<%= f.submit ‘Create’ %>

para

<%= f.submit ‘Salvar’ %>

Agora sim, estamos quase lá:
Esvaziamos agora o arquivo features/step_definitions/gerenciar_pessoas_steps.rb pois o último passo também é algo genérico, pode ser aproveitado em outros cenários e funcionalidades. No futuro talvez adicionemos um passo específico da funcionalidade a medida que alteramos nossa User Story. Movemos a definição do último passo para features/step_definitions/passos_compartilhados.rb

Ao rodar o cucumber novamente vemos a necessidade de mudar a mensagem de retorno do método create do nosso controller

Fazemos isso:

Finalizamos assim a implementação da funcionalidade.

Talvez você tenha achado um tanto chato fazer passo por passo código que poderia ser previsto, mas a idéia em TDD é justamente essa: passos de bebê.

No próximo post trataremos da utilização do webrat em modo selenium.

Críticas e comentários são bem-vindos! Até mais!

Cenários (Scenarios),  são perspectivas de utilização que validam um ou mais critérios de aceitação (Acceptance Criterias).

No BDD definimos Cenários seguindo o modelo:

Dado [pré-condição]
Quando [evento]
Então [pós-condição]

Em Dado definimos tudo o que precisamos antes para Quando o evento ocorrer Então verificarmos o resultado.

Exemplo em uma User Story Completa:

    Funcionalidade: Gerenciar Pessoas
     Como um usuário do sistema
     Eu quero gerenciar o cadastro de pessoas
     Para utilizar este cadastro em outros pontos do sistema

    Cenário: Adicionar Pessoa Válida
         Dado que estou em listagem de pessoas
         E vou para "Nova pessoa"
         E defino nome com o valor "Fulano de Tal"
        E defino endereco com o valor "Rua Sicrano, 32"
        E defino email com o valor "fulano@exemplo.com.br"
        Quando salvar o registro
        Então preciso ver "Pessoa Cadastrada com Sucesso."

Ok, ok, até agora você leu bastante mas não botou a mão na massa, que tal tornamos a User Story acima executável utilizando o Cucumber?

Mas primeiro, o que é o Cucumber?

O Cucumber é uma reescrita do Story Runner do RSpec com suporte a internacionalização, ajudantes para o Webrat e um monte de outros recursos legais.

Um Story Runner como o próprio nome já diz serve para executar User Stories, algo que converge para a tal documentação executável.

Criando o Projeto de Exemplo

Obs.: Meu ambiente de desenvolvimento roda Ubuntu 9.04, talvez seja necessário adaptar alguns destes passos ao seu próprio ambiente.

rails exemplobdd

cd exemplobdd

Para instalar o cucumber e suas dependências vamos alterar o arquivo de configuração do ambiente de teste adicionando as gems necessárias.

Para instalar o Cucumber e suas dependências agora é só rodar:

rake gems:install RAILS_ENV=test

Com o Cucumber instalado precisamos agora “inicializá-lo” no nosso projeto.

script/generate cucumber

Após o comando acima estará criada no nosso projeto uma estrutura de pastas onde colocaremos nossas User Stories e passos para atender aos Cenários. Dentro da pasta features crie o arquivo gerenciar_pessoas.feature

Nossa feature criada, agora executamos

cucumber features –language pt

E obtemos a seguinte saída:
Criamos nossa feature mas ainda não definimos os passos do Cenário.

1 scenario (1 undefined) 7 steps (7 undefined)

O Cucumber é um cara legal e já nos dá uma sugestão de como defini-los, faremos agora um CTRL+C e CTRL+V da sugestão para dentro do arquivo features/step_definitions/gerenciar_pessoas_steps.rb

Ao executar o cucumber novamente

cucumber features –language pt

vemos agora que apesar de nossos passos estarem definidos ainda estão todos marcados como pendente, o primeiro passo acusa isso e os subsequentes não são executados.

1 scenario (1 pending)
7 steps (6 skipped, 1 pending)

No próximo post trataremos do conceito de TDD, passos compartilhados no Cucumber e utilização do Webrat para testes funcionais. Quem viver verá!

O objetivo é dar ao TDD e o DDD (Domain Driven Design) uma visão integrada, fazendo o relacionamento entre essas duas abordagem ficar mais evidente de forma que o desenvolvimento seja focado em entregar algo de valor para o negócio de forma priorizada e verificável.

Para que esse objetivo seja alcançado é definido um vocabulário comum (Ubiquitous Language para pessoas familiarizadas com o conceito de DDD) que une quem entende de tecnologia com as pessoas que entendem do negócio. A idéia é que gerentes, usuários, analistas, desenvolvedores, testadores, enfim, todos envolvidos no projeto se expressem nos mesmos termos sobre o sistema em desenvolvimento.

O BDD apresenta um framework baseado em três princípios:

1. A área de negócios e a de tecnologia precisam se referir a mesma parte do sistema da mesma forma
- Tudo é comportamento

2. Toda parte do sistema precisa ter um valor identificável e verificável para o negócio
- Valor de negócio

3. Analisar, projetar e planejar tudo de cima a baixo tem retorno decrescente.
- O suficiente é suficiente

Se você está achando que BDD é apenas um novo nome para uma série de boas práticas existentes, você não está de todo errado. O objetivo do BDD é juntar todas essas boas práticas existentes sob uma só bandeira com uma terminologia consistente e sem ambiguidades.

User Story (História do Usuário)

“Uma User Story descreve funcionalmente o que será valioso para os usuários e aos compradores de um software.” Mike Cohn

Uma User Story precisa ser

I ndependente
N egóciável
V aliosa ao comprador
E stimável
S mall (pequena)
T estável

Story Card

No processo do BDD um especialista no assunto tratado(geralmente um usuário comum) trabalha com um analista de negócios para identificar um requisito de negócio. Este requisito é expresso utilizando um cartão.

A idéia da User Story ser escrita em um cartão ao invés de outra mídia permite nos manter no princípio Small (que a Story seja pequena). Se uma User Story ultrapassar os limites de um cartão talvez já seja hora de desmembrá-la.

Na escrita da User Story utilizamos o seguinte modelo:

Como um [pessoa ou papel desempenhado]

Eu quero [funcionalidade]

Para [benefício ou valor dessa funcionalidade ao negócio]

No cartão definimos também os critérios para a sua aceitação (Acceptance Criterias). Uma User Story só estará pronta quando todos seus critérios de aceitação forem atendidos.

Exemplo de Story Card:

Como um autor
Eu quero adicionar e gerenciar posts
Para blogar

Nota: Um post precisa ter nome, conteudo e status
Nota: O status de um post pode ser PUBLICADO ou NAO_PUBLICADO
Nota: Um post é criado com o status inicial NAO_PUBLICADO

No nosso próximo post veremos o conceito de Cenário de utilização e tornaremos uma User Story executável em projeto Rails através do Cucumber

Fontes:
http://behaviour-driven.org/
http://www.milfont.org/tech/2009/03/29/palestra-behaviour-driven-development/
User Stories Applied - Mike Cohn

Agora com a poeira baixando pretendo voltar a escrever aqui sobre as tecnologias que estou utilizando: Ruby, Rails, BDD, TDD, rSpec, Cucumber, Selenium, WebRat são as keywords

O Chucre passou um "overview" sobre a linguagem, apresentando seus pontos fortes e casos de sucesso na utilização da tecnologia, além disso falou sobre algumas novidades advindas no PHP 6.

Eu trabalhei a palestra  Depuração em PHP com XDebug e Firephp que já havia apresentando no encontro de Iguatu e no último encontro do CEPUG em Fortaleza.

Como havia bastante gente na platéia que ainda não conhecia o PHP e outros tantos ainda iniciantes em programaçao resolvi deixar a palestra um pouco mais leve :D, segue abaixo os slides:

Além das palestras sobre PHP na sua Semana de Tecnologia, a FJN apresentou também uma Formação em PHP que irá iniciar em janeiro de 2009, sendo que eu e o Fernando Chucre iremos lecionar parte dela.

Uma iniciativa realmente pioneira no interior do estado e que com certeza contribuirá bastante para o crescimento da comunidade em volta da tecnologia. Quem tiver interesse em participar pode obter mais detalhes aqui.

Fotos podem ser encontradas aqui.

O evento aconteceu na Fortes Informática e contou também com a palestra do Eric Saboia com uma abordagem comparativa entre os principais Frameworks PHP.

Meus parabéns a comunidade PHP cearense que a cada evento vem se mostrando sólida e com vontade de aprender, espero que todos tenham gostado como eu gostei.

Agradeço ao Fernando Chucre que vem batalhando para organizar a comunidade e a todos os outros que compareceram ao evento.

Keep PHP’ing!!

Fotos

Flickr do Silveira Neto

Material

Outra coisa que posso destacar sobre é o evento é que os participantes se sentiram muito provocados e com certeza teremos mais eventos acontecendo na região. O pontapé para uma comunidade de desenvolvedores ativa no Centro-Sul do Ceará está dado!

Agradeço demais o Fernando Chucre, Christiano Milfont e o Silveira Neto que se dispuseram a atravessar 400 Km para apoiar esse evento, ao SENAC por acreditar na idéia e nos dar apoio incondicional, aos patrocinadores e principalmente a todos que se fizeram presente e tornaram esse evento o grande momento que foi.

Material

Fotos

Picasa do Milfont

Flickr do Silveira

Flickr do Jefferson

Percebe-se uma deficiência muito grande no mercado de TI na região em que vivo e este evento além de seu cunho técnico tem um objetivo muito ambicioso que é reunir estudantes e profissionais poucos e dispersos e criar uma verdadeira comunidade de desenvolvedores se articulando para trazer (e ir para) eventos, buscar cursos de nível superior na área de ti, compartilhar experiências, enfim:  ao invés da atitude cômoda de reclamar das circunstâncias ou ir buscá-las fora, iremos tentar criá-las por aqui.

Mais informações sobre o evento aqui.

Tecnologia como fator de transformação social: Eu acredito nisso!

Em algumas aulas de programação tenho feito uma experiência com meus alunos: fazendo com que pratiquem programação em par, uma prática de XP. Pesquisando sobre quem mais andava utilizando essa técnica no processo de aprendizagem achei esse estudo fantástico sobre tema. Além de tudo eles produziram um video super legal apresentando a programação em par para os estudantes que pretendo legendar para usar em sala (com certeza postarei isso por aqui).

Segue os passos para a Instalação:

• Baixe e Instale o TortoiseSVN  (Sem mistérios aqui, apenas o esquema Next->Next->Finish)
• Baixe o código fonte do Add-In e este arquivo de recurso e coloque-os em uma mesma pasta.
• No Delphi crie um novo projeto do tipo Package ( no D7 é File->New->Other->Package)
• Clique no botão Add é adicione a unit tsvnWizard.pas que você baixou
• Compile e depois Install

No Delphi aparecerá um novo menu com as ações do TortoiseSVN.

É isso!