Cucumber e BDD ? Vantagens para a empresa (Argumentos para o gerente, para o arquiteto, para o presidente da empresa, ?)
Rodrigo Ribeiro
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
- O primeiro é inteligivel para um leigo, o segundo é especifico para um sistema e apenas um programador entende
- O primeiro é um exemplo de uma definição de comportamento de uma tela, uma coisa que um cliente poderia dizer.
- 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:
- O código gerado tem menor acomplamento e maior coesão.
- O código gerado tem uma maior qualidade por ser quase 100% testado.
- Refatoramentos podem ser feitos sem medo pois qualquer problema sera detectado pelos testes.
- É possível saber claramente quando uma tarefa foi concluida, pois o teste correspondente esta passando.
- Testes de regressão automatizados existem sem nenhum esforço adicional.
- A maior parte dos bugs é encontrada mais cedo o que torna mais barato corrigi-los.
Behavior Driven Development:
- Todos os anteriores
- Aumenta a integração entre o cliente, os testadores e os desenvolvedores pois todos falam a mesma lingua.
- 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.
- User Stories servem como Test Case, Código do teste automatizado, e Design tudo junto.
- 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 gravissimo 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 beneficios 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.
- Para o cucumber, todas as User Stories referentes a uma funcionalidade do sistema estarão agrupadas em um arquivo com a extensão .feature
- 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.
- Logo depois são definidos os cenários, que são as histórias em si, cada arquivo tem pelo menos um cenário.
- 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:
- Começar as frases com as palavras chave definidas
- 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
- É 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
Post de: Blog do Urubatan
Quer comprar meu livro Desenvolvimento Fácil e Rápido de Aplicações web com 30% de desconto? É só acessar o meu blog e pegar o código :D
Cucumber e BDD – Vantagens para a empresa (Argumentos para o gerente, para o arquiteto, para o presidente da empresa, …)
--
Atenciosamente,
Rodrigo Ribeiro
Test Analyst (Basix QA)
[55 11] 8172-7400 (Mobile)
[55 11] 3588-2190 (Basix)
rodrigo...@voicetechnology.com.br
Rodrigo Ribeiro
Algumas observações sobre BDD
Ultimamente estive pesquisando sobre o assunto BDD (Behaviour-Driven Development) e também praticado com alguns exemplos reais, e devo dizer que consegui tirar algumas conclusões bem interessantes sobre o assunto, nas quais gostaria de expor aqui. Vamos a elas:
BDD não é uma evolução de TDD
BDD é uma abordagem de testes, assim como TDD (Test-Driven Development), a diferença principal entre ambas, é que o BDD é mais focado no comportamento, e o TDD é focado em partes isoladas.
Eu já li em alguns lugares, que BDD é uma evolução do TDD e uma das conclusões que eu cheguei é que isso não faz sentido, pois as duas abordagens podem ser muito bem complementares e atuarem juntas em um mesmo projeto. Dependendo do custo x benefício, e aí eu envolvo a questão do tempo, acharia super válido um projeto pensar nas duas abordagens e nos benefícos que o uso das mesmas podem vir a trazer.
Como dizer que BDD é uma evolução do TDD se a maneira com as duas lidam com testes é diferente? BDD é baseado no conceito de testes de aceitação e estórias, uma estória é a sua funcionalidade e a mesma é constituida de cenários, que são as etapas que constituem uma estória. Os cenários por sua vez, são constituídos de passos, que no caso representam a sequência para um cenário ser satisfeito.
Quem já fez algum teste com BDD, deve ter percebido que um cenário pode não envolver vários métodos da sua aplicação, com isso consequentemente esses métodos não seriam testados. Na minha opinião, esse é mais que um motivo que aponta que TDD não deve ser desconsiderado em seu projeto, mesmo que ele use BDD.
BDD ajuda você, BDD ajuda seu cliente
Outro ponto que pude observar, é que usando BDD a possibilidade de um cliente participar de um projeto é imensa, mesmo que você não use alguma metodologia ágil (falarei sobre isso a seguir). E por que ele pode participar? É simples, pois é ele quem pode escrever os testes. Se ainda assim não for o seu cliente o responsável por escrever os testes, será quem irá validá-los, ou seja, você pode escrever os testes e pedir para que ele aprove ou não. Isso é muito importante, pois nesse caso os testes em BDD seriam o contrato entre você o seu cliente, entre o que você está entregando e o que ele está esperando.
BDD favorece o sucesso do uso de metodologias ágeis
Sem dúvida nenhuma um dos pontos fortes do uso de BDD é que suas características se encaixam muito bem em equipes que fazem o uso de metodologia ágil. E são vários pontos que favorecem.
Uma delas é a já citada participação do cliente, pois um dos requisitos para o sucesso do uso de metodologias ágeis é a participação e contribuição efetiva do cliente e no caso do uso de BDD ele pode participar diretamente, uma vez que é ele quem é o responsável (PO) por criar as estórias (ítens do backlog) e criar os testes de aceitação para as mesmas, onde tudo isso é usado no BDD.
Os artefatos que constituem BDD são muito, mais muito semelhantes aos artefatos presentes em ágil.
Em BDD se usa estórias e testes de aceitação, além de BDD favorecer a construção de aplicativos de forma evolutiva (sprints) e tudo isso casa perfeitamente com os requesitos das metodologias ágeis.
Favorece a escrita de testes antes da implementação
Uma boa prática na criação de testes, independente se você usa BDD ou TDD, é que os testes sejam criados antes de tudo. Ok, eu concordo, mas devo dizer que com TDD isso não é muito nítido, pois na maioria dos casos, principalmente no começo, as pessoas tendem a implementar os códigos e depois escreverem os testes para validá-los. Já com BDD, a primeira coisa que você precisa ter em mãos antes de implementar os testes são as estórias e os cenários, não tem como fugir disso, o que torna muito mais nítido que em primeiro lugar vem os testes e depois as implementações.
Torna mais nítido o que sua aplicação deve fazer
Com BDD é muito mais fácil isolar as funcionalidade da sua aplicação, já que o que é testado é exatamente isso, dessa forma fica fácil identificar os componentes que envolvem determinada funcionalidade, torna mais nítido qual é o papel daquela funcionalidade, além do que consegue dar um sentido melhor para a sua aplicação de maneira geral.
Com BDD, você consegue ainda uma visão de workflow da sua aplicação, ou seja, uma visão macro, o que favorece dar manutenção a mesma. Percebo também, que BDD favorece um bom design de código, evitando assim problemas de desenvolvimento como códigos com alto-acoplamento.
Torna os testes mais humanos
A essência do BDD são os problemas e não parte isoladas da aplicação e essa maneira de lidar com testes favorece o entendimento por parte de nós, humanos.
Testes de interface com o Selenium, tornam-se mais compreensíveis num contexto que envolva BDD, como em um teste de login, por exemplo.
Conclusão
Na minha opinião, está mais do que clara a vantagem no uso de BDD, entretanto ele não substitui o uso de TDD, pois a abordagem de ambas são diferentes e complementares.
No próximo tópico, irei mostrar um cenário de testes com o framework JBehave, um framework BDD para Java.
Fabrício Ferrari de Campos
Na minha opinião BDD não é uma abordagem de testes, e sim de desenvolvimento, até porque o próprio nome já sugere isso. :)
Mas é possível usar BDD em Teste de Software (seria o BDT!? rs), e neste caso, seria numa situação em que o desenvolvimento já está sendo feito sem BDD, pois houve alguma dificuldade de implantar o BDD em dev. (por exemplo, devido ao cliente), ou as pessoas não tinham conhecimento sobre a técnica, etc. Até porque os testes feitos com BDD representam os testes de aceitação, já produzidos em um processo de Teste de Software.
Agora sobre TDD X BDD, concordo com o autor, um não exclui o outro, eu entendo que BDD foca na validação do sistema (estamos construindo o produto certo?), enquanto TDD foca na verificação do sistema (estamos construindo certo o produto?). Ou seja focos diferentes.
E vcs o q acham? Alguém já praticou BDD ou TDD? Como foi a experiência?
Abraços!
--
Atenciosamente,
Fabrício Ferrari de Campos, CBTS, CTFL
Blog: qualidadebr.wordpress.com
Twitter: twitter.com/FabricioFFC
Rodrigo Ribeiro
Quem sabe mais para frente eu esteja estudando mais material e tendo experiências práticas sobre o assunto.
Logo, ainda não tive experiência/prática com TDD/BDD... Sou um imaturo ainda (como diria Carlos Brando), mas tempo e oportunidades não faltarão (rs).
É isso aí. Até a próxima!
--
Você está recebendo esta mensagem porque se inscreveu no grupo "Ensinar" dos Grupos do Google.
Para postar neste grupo, envie um e-mail para ens...@googlegroups.com.
Para cancelar a inscrição nesse grupo, envie um e-mail para ensinar+u...@googlegroups.com.
Para obter mais opções, visite esse grupo em http://groups.google.com/group/ensinar?hl=pt-BR.