06 Jan 10 Cucumber e BDD – Vantagens para a empresa (Argumentos para o gerente, para o arquiteto, para o presidente da empresa, …)

Desenvolvimento Guiado pelo Comportamento (BDD – Behaviour Driven Development)

Desenvolvimento guiado pelo comportamento da aplicação é o que todos deveriam fazer sempre, de forma bastante resumida é definir com o cliente como a aplicação deve se comportar, escrever um teste automatizado para verificar este comportamento e depois escrever código suficiente para fazer o comportamento da aplicação ficar de acordo com o que o cliente deseja.

A diferença básica do Behaviour Driven Development (de agora em diante simplesmente BDD) para o desenvolvimento orientado por testes, é que o BDD coloca em foco o valor para o negócio que o software vai adicionar. Parece ser uma diferença puramente conceitual mas não é, por exemplo:
A tela inicial deve listar todos os clientes
Não é a mesma coisa que
O método HomeController.index precisa popular a variável @clientes

1. O primeiro é inteligivel para um leigo, o segundo é especifico para um sistema e apenas um programador entende
2. O primeiro é um exemplo de uma definição de comportamento de uma tela, uma coisa que um cliente poderia dizer.
3. O segundo é um exemplo de como um programador poderia ler uma linha de código fonte.

Claro que não são só estas diferenças, trabalhando mais com BDD percebe-se que ele poupa muito mais trabalho do que o TDD simples (Não que TDD seja simples de se adotar). BDD tem todas as vantagens de TDD e mais algumas, veja as duas listas abaixo:

Test Driven Development:

1. O código gerado tem menor acomplamento e maior coesão.
2. O código gerado tem uma maior qualidade por ser quase 100% testado.
3. Refatoramentos podem ser feitos sem medo pois qualquer problema sera detectado pelos testes.
4. É possível saber claramente quando uma tarefa foi concluida, pois o teste correspondente esta passando.
5. Testes de regressão automatizados existem sem nenhum esforço adicional.
6. A maior parte dos bugs é encontrada mais cedo o que torna mais barato corrigi-los.

Behavior Driven Development:

1. Todos os anteriores
2. Aumenta a integração entre o cliente, os testadores e os desenvolvedores pois todos falam a mesma lingua.
3. Mesmo quando testadores e desenvolvedores são equipes diferentes eles podem trabalhar juntos para definir o design do que vai ser feito, escrever User Stories é uma ótima forma de fazer isto, pode ser feito com a ajuda do usuário ou pelo menos validada com o usuário que vai entender o que esta escrito.
4. User Stories servem como Test Case, Código do teste automatizado, e Design tudo junto.
5. As User Stories se tornam testes executáveis, o que quer dizer que o usuário pode escrever o código dos testes de aceitação (OK, isto é bem pouco provável, mas ele pode pelo menos ler)

Ou seja, alem de gerar um código com mais qualidade, o BDD poupa trabalho de toda a equipe e o principal, melhora a comunicação, que tanto para quem trabalha com metodologias ágeis quanto para quem não trabalha é extremamente importante e a falta dela é um problema gravíssimo que leva diversos projetos ao fracasso. Na minha opinião, só o fato de melhorar a comunicação já é motivo o suficiente para testar BDD.

Claro que alguns dos benefícios que eu citei dependem do suporte de ferramentas, para ser mais preciso, as User Stories serem o código executável dos testes de aceitação depende de uma ferramenta para ser verdade, e a ferramenta que eu escolhi para isto é o Cucumber, do qual eu vou começar a falar com mais freqüência aqui no blog.

Eu pessoalmente encaro o BDD como uma evolução do TDD, eu sempre tive dificuldades em escrever testes unitários antes do código da aplicação, claro que para bibliotecas é fácil, mas para a interface com o usuário que consome boa parte do código da aplicação é bem complicado escrever testes estilo XUnit, mas quando as user stories se tornaram o código executável dos testes de aceitação da UI (pelo menos os básicos desconsiderando o layout) um novo mundo se abriu para mim e tudo passou a fazer sentido.

Cucumber – Quem disse que pepinos seriam um problema?

_{para quem não percebeu este sub-titulo é uma brincadeira com a tradução da palavra cucumber que quer dizer pepino}

Cucumber é uma ferramenta que torna possível executar histórias em texto puro, ele é uma ferramenta escrita em Ruby que veio para substituir o RSpec Story Runner, e tem diversas vantagens sobre este.

O Cucumber, utiliza Ruby e expressões regulares para definir o que qualquer expressão quer dizer, mas antes de entrar nestes pormenores vamos entender um pouquinho da estrutura básica que o Cucumber define para as User Stories.

Para que seja possível executar uma User Storie utilizando o Cucumber, ela precisa ter uma estrutura básica.

1. Para o cucumber, todas as User Stories referentes a uma funcionalidade do sistema estarão agrupadas em um arquivo com a extensão .feature
2. No início de cada arquivo existe um resumo da funcionalidade com um formato bem simples: um título, qual o problema a ser resolvido, qual ator trabalha nesta história e qual o resultado desejado.
3. Logo depois são definidos os cenários, que são as histórias em si, cada arquivo tem pelo menos um cenário.
4. Cada história, ou cenário é composto por uma descrição ou título, uma ou mais pré condições, uma ou mais ações e uma ou mais verificações.

Esta é uma forma de definir a estrutura básica de um arquivo .feature do Cucumber, claro que explicando desta forma estas definições se encaixam em muita coisa, então vamos ser um pouco mais especificos.

O Cucumber define algumas palavras chave para cada uma destas sessões, estas palavras chave podem ser traduzidas para diversas linguas, o primeiro exemplo eu vou colocar em ingês, depois vou mostrar o equivalente em portugues, mais adiante quando entrarmos na parte de configurações do cucumber vamos ver melhor como selecionar a lingua utilizada, e como customizar isto, mas por enquanto fiquemos com as configurações padrão.

	Feature: Simple math
		In order to avoid silly mistakes
		As a math idiot
		I want to be told the result of simple math operations

		Scenario: adition
			Given I have entered 50 into the calculator
			And I have entered 70 into the calculator
			When I press add
			Then I should see 120 on the screen

		Scenario: subtraction
			Given I have entered 60 into the calculator
			And I have entered 30 into the calculator
			When I press sub
			Then I should see 30 on the screen

Este é o exemplo de uma história bem simples que o cucumber pode interpretar, as palavras chave apresentadas são:

• Feature
• Scenario
• Given
• And
• When
• Then

Estas mesmas palavras podem ser traduzidas para o portugues como:

• Funcionalidade
• Cenário
• Dado
• E
• Quando
• Então

Utilizando estas palavras chave, seria possível escrever esta história assim em portugues:

	Funcionalidade: Matemática Simples
		Para evitar erros idiotas
		Como um completo ignorante em matemática
		Eu quero que operações simples de matemática sejam resolvidas para mim

		Cenário: adição
			Dado que eu digite 50 na calculadora
			E que eu digite 70 na calculadora
			Quando eu precionar "Adicione"
			Então eu devo ver 120 na tela

		Cenário: subtração
			Dado que eu digite 60 na calculadora
			E que eu digite 30 na calculadora
			Quando eu precionar "Subtraia"
			Então eu devo ver 30 na tela

O legal é que esta histórinha poderia ser escrita por um usuário, as únicas regras reais são:

1. Começar as frases com as palavras chave definidas
2. Tentar utilizar as mesmas frases sempre que possível, isto vai facilitar na tradução do dialeto utilizado para Ruby

A estrutura que utilizei na descrição da funcionalidade não esta descrita em palavras chave por que ela não é interpretada pelo cucumber, é apenas uma descrição e o formato pode variar um pouco.

Mas por que utilizar esta ferramenta para testes em vez de qualquer outra?
Por que utilizar o cucumber como ferramenta de testes vai viabilizar uma abordagem BDD no desenvolvimento do seu sistema, e que isto vai te poupar muito dinheiro.

Seguem agora alguns argumentos (fora os que você pode retirar do texto)

• Presidente da empresa
  • Esta metodologia de desenvolvimento em conjunto com as ferramentas corretas vão poupar bastante dinheiro no desenvolvimento de sistemas
• Gerente
  • A integração entre as equipes de desenvolvimento e os clientes vai melhorar muito, isto vai fazer com que os clientes fiquem mais felizes com as entregas, possam acompanhar o progresso do desenvolvimento e entendam se o que esta sendo testado é o que realmente importa para eles melhorando a qualidade do que é entregue
• Arquiteto
  • Esta metodologia vai melhorar o entendimento da equipe sobre o que deve ser desenvolvido
• Desenvolvedores e Testadores
  • É legal trabalhar desta forma, e você vai trabalhar menos no final das contas o que é bom e ermite que você exercite a sua preguiça

Acho que era isto, falei um pouco de BDD, um monte de Cucumber e acho que consegui mostrar a idéia geral, mas isto vai ficar um pouco mais claro nos próximos posts sobre o Cucumber.
PS.: parabéns pela paciência se você leu até aqui

If you enjoyed this post, make sure you subscribe to my RSS feed!

Tags: bdd, cucumber, lcucumber, Ruby