Entendendo BDD com Cucumber – Parte I

Este é o meu primeiro post sobre BDD e Cucumber. Nesse primeiro post não vamos ver nada de automação nem cucumber, mas entender um pouco do contexto que estamos vivendo em teste de software e como são escritos testes no mundo ágil. Vamos entender o conceito de Critério de Aceite e como eles são usados pelo BDD e no final vamos fazer uma comparação entre os testes no modelo tradicional como descritos pela norma IEEE 829 em relação aos critérios de aceite usados pelos times ágeis.

Claro que todos os testes que realizaremos manualmente hoje, serão automatizados no futuro. Para escrever os testes vamos usar um exemplo que já é conhecido por todos, os testes do triângulo de Myers :) (Ok, eu sei que todos já estão de saco cheio desse exemplo, mas ele é simples e bem didático e fácil de entender)

Pra começar, vamos alinhar alguns conceitos e entender um pouco da história dessa sopa de letrinhas. A história descrita abaixo é baseada em uma pesquisa que eu realizei com alguns livros, artigos, wikis e posts de blogs, pois infelizmente não vivi essa fantástica época (provavelmente eu estava assistindo Saint Seya e Pokemon lol), portando está suscetível a algumas falhas. Conforme eu for encontrando as falhas irei corrigindo.

1996 – Test-Driven Development

Em meados de 1996/2000, durante o surgimento da agilidade, começaram a falar sobre testar primeiro e desenvolveu-se o TDD (Test-Driven Development) como a prática de desenvolver os testes de unidade antes do desenvolvimento do código-fonte de produção. Para isso foi elaborado um processo chamado de Red/Green/Refactor, onde o desenvolvedor escreve testes, desenvolve o mínimo para fazer os testes passarem e em seguida refatora o código para melhorar a implementação. Esse conceito foi detalhado em 2002 pelo Kent Beck no livro Test-Driven Development by Example implementando o conceito descrito alguns anos antes por Martin Fowler no clássico Refactoring: Improving the Design of Existing Code (no qual o próprio Kent Beck participou como contributor). Esse modelo, também conhecido como UTDD (Unit Test-Driven Development) foi incorporado ao planejamento do XP (eXtreme Programming) para criar testes ajudando a desenvolver evitando defeitos e ao mesmo tempo criando uma suite de testes de regressão.

Para entender mais sobre TDD leia o livro citado acima (Test-Driven Development by Example do Kent Beck).

~2003 – Acceptance Test-Driven Development

Em paralelo, as empresas de desenvolvimento de software sofriam para aprovar com o cliente quando um software ou mesmo uma funcionalidade estava completa e principalmente se ela estava se comportando como deveria. Nesse ponto a abordagem de User Stories implementa os critérios de aceite (acceptance criteria ou acceptance testing) que é uma abordagem bem parecida com o nosso teste tradicional usando test cases, ou seja, são escritos testes e executados manualmente após a implementação de alguma feature. Notados os problemas que conhecemos bem quando usamos abordagens tradicionais de desenvolvimento de software, surge o ATDD (Acceptance Test-Driven Development), como uma extensão do TDD e do planejamento de testes do XP, mas agora criando testes automatizados (normalmente de unidade) guiados pelos critérios de aceite do cliente, documentados em user stories ou test cases. Essa nova abordagem traz os benefícios do TDD incorporando os critérios do cliente, dessa forma, uma feature só estaria completa quando além das necessidades técnicas, ela também implementasse todos os testes que comprovam que a implementação está se comportando como o esperado. O desenvolvimento agora é guiado pelos testes que devem passar para que a User Story seja completada.

Esse processo é ilustrado pela figura abaixo:

Ciclo de ATDD by Lasse Koskela

~2004 – Acceptance Test-Driven Planning

Mais tarde surge o ATDP (Acceptance Test-Driven Planning) como uma abordagem que dirige o desenvolvimento por testes de aceite escritos pelo cliente. Nessa abordagem os testes devem ser escritos juntamente com o cliente, ou seja, durante a reunião de planejamento da iteração ou antes dela. Dessa forma, tanto a equipe de desenvolvimento quanto o cliente alinhavam os testes ou comportamentos esperados para que uma funcionalidade estivesse completa e toda a iteração deveria atender a esses comportamentos esperados e ao mesmo tempo, não deveriam alterar os comportamentos do que já estivesse implementado. Esse modelo se mostrou muito mais fácil de gerenciar, mas ainda existia um problema de comunicação com o cliente que não conseguia ler os testes de aceite na forma automatizada. Além disso, em alguns casos, os testes podiam ser modificados na story e e seus testes automatizados mantidos como antes, o que também gerava retrabalho.

2006 – Behaviour-Driven Development

Behaviour-Driven Development is about implementing an application by describing its behavior from the perspective of its stakeholders.” – David Chelimsky, The RSpec Book.

Em 2006, Dan North e a ThoughtWorks criaram o JBehave aplicando os conceitos de Behaviour-Driven Development como proposta para resolver esse problema. BDD é baseado principalmente em Domain-Driven Design e Test-Driven Development. Envolve o negócio, teste de software, desenvolvimento e planejamento. Olhando de cima, o BDD é uma abordagem inovadora de teste que junta os dois mundos: Em apenas um repositório, você mantém os testes de aceite automatizados de uma forma simples de ler para o cliente, desenolvedores, QAs e demais membros da equipe e ao mesmo tempo esses testes são automatizados antes do desenvolvimento, formando um conjunto de testes de aceite que guiam o desenvolvimento das histórias e em seguida são usados como testes de regressão. Nessa abordagem, a documentação e o código de desenvolvimento evoluem sempre juntos. Mas na verdade o BDD envolve muito mais do que essa simples definição.

Os três princípios do BDD são:

  1. O suficiente é suficiente: Não devemos automatizar tudo, mas sim tudo o que descreve o comportamento esperado do produto pelo cliente. O suficiente para desenvolver a solução. Mais do que isso é desperdício de esforço.
  2. Entregar valor para os stakeholders: Entregue somente o que tem valor para o cliente, nada mais. Se o que estiver fazendo não agrega valor para o cliente ou não potencializar o valor entregue, pare de fazer isso.
  3. Tudo é comportamento: Tudo que um software faz pode ser descrito como comportamento e explicado para qualquer pessoa que tenha o domínio do negócio. Não importa o nível de teste, o tipo de funcionalidade, sempre será descrito como comportamento.

Por que BDD é diferente de TDD?

Enquanto o TDD foca mais no design do código, o BDD foca no negócio. Usamos TDD para criar um pedaço de uma funcionalidade que descrevemos com um cenário de BDD. Ou seja, descrevemos o que (comportamento) do sistema com cenários de critérios de aceite, mas quando vamos implementar seus detalhes e testar o como ele implementa essa funcionalidade, usamos TDD.

Em uma analogia, podemos dizer que usamos BDD para descrever que um carro deve acelerar e para isso descrevemos que quando acionamos o pedal do acelerador, o carro deve acelerar a tal velocidade, o velocímetro deve aumentar e que o indicador de giro do motor deve exibir o giro, mas quando vamos montar o motor devemos descrever com TDD tudo que está dentro do motor.

Resumindo:

  • TDD (Test-Driven Development): Criar testes de unidade escritos antes da implementação do código-fonte para modelar o design que desejamos usar para cada implementação, ajudando a evitar defeitos durante essa implementação e evitando que implementações futuras possam afetar as implementações já desenvolvidas.
  • ATDD (Acceptance Test-Driven Development): Extensão do TDD onde criamos testes de unidade para cobrir os critérios de aceite usando a prática do TDD, mas agora cobrindo o comportamento descrito em user stories e não somente o design do código.
  • ATDP (Acceptance Test-Driven Planning): Planejamento orientado a testes de aceite, descritos e aprovados sempre pelo cliente, utilizando ATDD como principal prática para escrever testes.
  • BDD (Behavior-Driven Development): Forma de criar comportamentos testáveis e automatizados que agreguem valor para o cliente antes da existência do código-fonte, evitam defeitos baseados em comportamento e geram um conjunto de testes de regressão baseados nesses comportamentos.

Na prática, hoje em dia, em empresas que adotam práticas ágeis o uso do TDD é bem mais mesclado entre TDD, ATDD e ATDP, e as pessoas evitam ficar criando mais nomes e segmentando essas práticas. Normalmente usamos TDD e implementamos os testes que julgarmos necessários para ajudar a ter o melhor produto, portanto quando uma empresa diz que adota o TDD, provavelmente ela adota essa mesclagem de abordagens.

BDD é legal, mas o futuro está acontecendo!

Embora tenha se tornado um assunto mais popular nos últimos meses entre a comunidade de teste do Brasil, o BDD já existe desde 2006, e várias novidades vem acontecendo desde então. Duas afetam o como devemos nos planejar para o futuro diretamente, são elas a especificação por exemplos e a entrega continua.

2010 – Continuous Delivery

Continuous Delivery (CD) is a set of principles and practices in growing use in software development to improve the process of software delivery” – Wikipedia

Em outro lado, baseado em várias das práticas de desenvolvimento ágil, Jez Humble e David Farley escreveram em 2010 o livro Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation, que está mudando a forma como vemos o desenvolvimento de software. Este livro reforça a ideia de um papel chamado DevOps, que é a junção de skills de developer, de QA e de sysadmin em uma disciplina. No futuro teremos posts sobre o devops, sobre continuous delivery, mas se desejar saber agora de uma forma mais completa e direto na fonte pode comprar o livro: Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation

2011 – Specification by Example

Specification by example is a collaborative approach to defining requirements and business-oriented functional tests for software products based on capturing and illustrating requirements using realistic examples instead of abstract statements.” – Wikipedia

Como uma forma mais efetiva de documentar e testar software para desenvolvimento ágil de software, Gojko Adzic escreveu no ano passado (2011) um dos livros “para QAs” mais importantes dos últimos tempos, o livro Specification by Example, que implica na elaboração de documentação 100% viva e está mudando a forma como testamos software. Esse liro aproxima mais do que nunca um QA extremamente técnico de um BA (Business Analyst). Também abordaremos muitos posts sobre SbE no futuro, mas o livro é muito recomendável: Specification by Example

Entendendo critérios de aceite:

Conceitualmente falando, Critérios de Aceite são requisitos necessários para que uma story possa ser considerada completa. Não existem limites de critérios de aceite nem regras de como eles devem ser descritos, o fundamental é que todos eles representem um comportamento testável que agregue valor para o cliente.

Para entendermos BDD é fundamental entender como são estruturados os critérios de aceite, por isso inicialmente vamos ter um exemplo de User Story (História de Usuário). Nesse exemplo, vamos descrever o papel, o objetivo e a razão de uma funcionalidade. Este modelo é amplamente utilizado em empresas de desenvolvimento ágil:

Feature: <description of the feature>

As a <user/actor>
I want <goal to be achieved>
so that <the reason you want to achieve the goal>

Cada Story recebe um ou mais Acceptance Criterias (Critécios de Aceite), o que são um substituto dos test cases tradicionais que muitos testadores estão acostumados. Esses ACs (Acceptance Criteria) normalmente são descritos no verso do card da US, e mais tarde detalhados como descrito abaixo:

Scenario: <description of the test>
Given <a known state>
When <an event occurs>
Then <then this should happen>

O modelo acima traduzido para o português seria algo como:

Funcionalidade: <descrição da funcionalidade>

Como um <usuário/ator>
Eu quero <meta a ser alcançada>
De modo que <a razão para alcançar a meta>

Cenário: <descrição do teste>
Dado
<um estado conhecido>
Quando <um determinado evento ocorre>
Então <isso deve ocorrer>

Como comentei anteriormente, não existe um formado que seja perfeito para todos os casos do universo, mas o formado que usamos acima e vamos usar nessa série de posts, descreve o modelo mais utilizado por várias empresas e pelos principais frameworks/ferramentas do mercado, como o JBehave, Cucumber, Twist, Spinach etc., além de ser bem intuitivo, simples e didático.

Dessa forma, vamos pensar no nosso triangulo e vamos usar a User Storie abaixo para escrever alguns ACs:

  Funcionalidade: Leitor de tipos de Triângulo

  Para conhecer o tipo de um triângulo
  Como um aluno da matemática
  Eu quero informar os tamanhos do lado de um triângulo e saber qual o tipo do triângulo

  NARRATIVA

  Um triângulo com todos os lados iguais é chamado Equilátero
  Um triângulo com dois lados iguais é chamado Isósceles
  Um triângulo com todos os lados diferentes é chamado Escaleno

  FORA DE ESCOPO

  -Validar triângulos inválidos
  -Exibir o triangulo graficamente
  -validação de entrada de dados do usuário

Para saber mais sobre o User Stories e Acceptance Criteria eu recomendo o livro User Stories Applied: For Agile Software Development do Mike Conh e mais sobre Acceptance Criteria do ponto de vista de QAs pode ser encontrado no livro Agile Testing: A Practical Guide for Testers and Agile Teams da Lisa Crispin e Janet Gregory.

A User Story acima é bem simples e resumida, mas dela podemos ver alguns detalhes que nos QAs não estamos acostumados, entre eles, eu destaco os itens fora do escopo. Na maioria das vezes, quando falamos em testes exploratórios, a maioria dos QAs ainda imagina-se testando a aplicação em busca de defeitos sem um roteiro. Sim, isso é teste exploratório, mas quando falamos sem um roteiro, não estamos falando em testes negativos, mas sim em um teste conhecendo as limitações do que foi implementado. Poderíamos pensar em dezenas de testes para validar diferentes tamanhos, dados incorretos, triangulos inválidos entre outros possíveis cenários, mas devemos ter consciência que neste momento devemos testar apenas o que a User Story se propõe, e isso não vai nos tornar piores testers, mas vai ajudar a tornar esse pedacinho de funcionalidade mais confiável para o cliente.

Para entender mais de exploratory testing eu recomendo o livro Exploratory Software Testing: Tips, Tricks, Tours, and Techniques to Guide Test Design do antigo QA Lead do Google e um dos maiores especialistas do nosso tempo, James Whittaker.

Pensando nesse caso, vamos escrever nossos critérios de aceite:

Para esse primeiro exemplo, como pôde ser observado descrevemos a funcionalidade de uma forma bem superficial.

O exemplo acima ressalta algumas das vantagens do uso do BDD, entre elas (e principalmente) é que o teste é auto explicativo, ou seja, qualquer pessoa que saiba ler português sabe o que será testado. Além disso, o teste está junto com o seu requisito, ou seja, o requisito e o teste nasceram juntos e caso um seja alterado o outro será também. Na verdade, neste tipo de abordagem, o teste é o requisito. Para que uma US esteja completa, como citamos anteriormente, o software deve ser aprovado por todos os critérios de aceite.

Importante mencionar que os testes descritos acima são apenas um exemplo, e futuramente vamos implementar técnicas que implementam o princípio DRY (Don’t Repeat Yourself), entre outros conceitos mais avançados das ferramentas de BDD.

Casos de teste X Critérios de Aceite

Muitas pessoas e instituições de teste de software critícam a abordagem de teste baseado em comportamento quando comparado ao mecanismo sistemático de elaboração de casos de teste (como descrito no meu post). Em muitos casos por desconhecer que ambas as abordagens, do ponto de vista de cobertura e conteúdo são muito parecidas.

Para exemplificar que um AC e um Test Case possuem o mesmo conteúdo, vamos fazer um “de/para” de um test case tradicional da IEEE 829 para um acceptance criteria:

De acordo com a IEEE829, um test case deve ter os campos:

  • Identificador do Caso de Teste
  • Itens de teste
  • Especificações de entrada
  • Especificações de Saída
  • Ambiente necessário
  • Exigências especiais
  • Interdependências
Exemplo de caso de teste segundo a IEEE829

Conhecendo as informações requeridas do modelo tradicional (IEE 829) como descrito no conceito e exemplo apresentados acima, podemos considerar a explicação abaixo como um facilitador para quem está acostumado com o modelo IEEE 829:

  • Given (Dado): Representa a situação inicial do teste e pode ser considerado como a pré-condição.
  • When (Quando): Representa uma ação ou evento. Pode ser considerado como um procedimento.
  • Then (Então): Representa uma resposta, comportamento ou resultado esperado.
  • And (E): usado para extender o given, when ou then positivamente.*
  • But (Mas): usado para extender o given, when ou then negativamente.*
Aindapodemos criar tabelas com os dados de entrada e saída como veremos a frente e ter na US informações como a rastreabilidade dos testes e usuário/ator necessário para execução dos testes.

*Para esse primeiro post, vamos manter simples e ignorar as palavras chave And e But.

A IEEE 829 ainda especifica alguns campos relativos a ambiente, rastreabilidade de requisitos, autor do caso de teste, executor do caso de teste, data de criação e atualização, log de execução do caso de teste entre outras informações. Todas essas informações podem ser organizadas em uma simples planilha como a descrita acima, ou em uma ferramenta de gestão de testes como o TestLink, o Quality Manager ou qualquer outra ferramenta do mercado. Para manter esse primeiro post simples e objetivo, não vamos usar recursos técnicos nem ferramentas para realizar o tracking dessas informações, pois veremos isso em posts futuros.

Enquanto isso em um critério de aceite as mesmas informações ficam disperças de outra forma como no exemplo abaixo:
Exemplo de critério de aceite

Podemos notar que as pré-condições e os procedimentos necessários para iniciar o teste estão encapsulados no no passo “Dado que estou na página de consulta de triângulos”, que os procedimentos de teste estão encapsulados no passo “Quando eu informo os lados de um triangulo:”, que os dados de entrada estão dispostos na tabela e os dados de saída e resultado esperado estão encapsulados no passo “Então o sistema informa que o triangulo é ‘Escaleno'”.

Toda as outras informações como autor, datas de criação e atualização, logs da execução e etc., ficam armazenadas por ferramentas de gestão de configuração e integração continua.

Se as duas abordagens tem resultados iguais, porque devo escolher o BDD?

  • BDD usa testes como requisitos;
  • BDD torna os testes mais elegantes;
  • BDD torna os testes mais legíveis e sucintos;
  • BDD torna os testes simples para pessoas de negócios;
  • BDD consome menos tempo para escrever testes;
  • BDD é documentação evolutiva;
  • BDD é documentação executável;
  • Critérios de aceite representam o valor do produto e não valor de documentação;
  • BDD técnicamente é teste de unidade, integração ou sistema, mas com valor de teste de aceite;
  • BDD é teste que evita defeito não que encontra defeitos;

Quando não devo usar BDD?

Na verdade a pergunta correta seria “Como eu não devo usar BDD?”. Todos os tipos de projetos podem usar BDD. Projetos web, desktop, mobile, em processos ágeis, em processos tradicionais, em empresas públicas e privadas, com ou seu QAs/Testadores. Porem, como foi citado anteriormente, o BDD não é uma técnica para automatizar todos os testes, mas sim aqueles que descrevem os comportamentos do sistema e garantir que eles estejam sempre funcionando. Não se deve automatizar todos os cenários possíveis com essa abordagem, pois vai se tornar um processo muito complexo modificar os testes no futuro. Se o projeto requer uma quantidade superior de qualidade, ou seja, não seja necessário que apenas o comportamento do sistema seja testado continuamente, vale a pena apostar em outras ferramentas e técnicas para testar os cenários que o cucumber não cobre por natureza, mas essas ferramentas podem ser complementares.

Referências e Links interessantes:

The RSpec Book: Behaviour-Driven Development with RSpec, Cucumber, and Friends by David Chelimsky, Dave Astels, Zach Dennis, Aslak Hellesøy, Bryan Helmkamp, Dan North (extremamente recomendado)
http://www.slideshare.net/tcmak/atdd-in-practice
http://www.extremeprogramming.org/
http://testobsessed.com/blog/2008/12/08/acceptance-test-driven-development-atdd-an-overview/
http://en.wikipedia.org/wiki/Behavior_Driven_Development
http://behaviour-driven.org/
http://programmers.stackexchange.com/questions/33243/acceptance-test-driven-planning-or-acceptance-test-driven-development
http://www.springerlink.com/content/vcq847l8ker3jc1d/
http://testdrivendeveloper.com/2008/04/02/AcceptanceTestDrivenDevelopmentExplained.aspx
http://www.itester.co.uk/testing/a-brief-history-of-behaviour-driven-development
http://brunograsselli.com.br/2010/01/como-executar-o-cucumber-em-portugues.html
http://www.testexpert.com.br/?q=node/90
http://en.wikipedia.org/wiki/Test_case
http://www.methodsandtools.com/archive/archive.php?id=72
http://www.engineyard.com/blog/2009/cucumber-introduction/
http://behaviordrivendevelopment.wikispaces.com/Overview
http://dannorth.net/whats-in-a-story/
http://neelnarayan.blogspot.com/2010/07/bdd-is-more-than-tdd-done-right.html

The Bug Bang Theory:
Palestra UniBH: Desenvolvimento Dirigido por Testes
Introdução ao TDD co JUnit
Teste de unidade para quem não sabe nada de programação

Camilo Ribeiro

Test Engineer at Klarna
Desenvolvedor, testador e agilista desde 2005, atualmente trabalhando na Suécia.

23 thoughts on “Entendendo BDD com Cucumber – Parte I

  1. Daí Camilo, tudo certo?

    Cara, excelente essa sua retrospectiva histórica sobre Automação de testes!

    Quanto ao exemplo do triangulo, depois que conheci ele na quarta-feira passada, achei sensacional, simples, fácil de explicar e eficaz. Vou adotar(roubar) para as minhas explicações/exemplos também. :-P

    Dois livros que você citou e que estão na minha fila de leitura: Exploratory Software Testing e Specification by Example do Gojko. (acompanho o blog dele há algum tempo e o cara é muito bom)

    Falando em Specification by Example, vocês tão usando aí na TW?

    Abraço e parabéns pelo texto, foi de uma ponta a outra com um grau de detalhes incrível, muito esclarecedor.

    P.S: Só um detalhezinho no texto, no quarto parágrafo tem alguns “Drien” ao invés de “Driven”. :-)

  2. Olá Thiago,

    Muito obrigado pelo comentário e pelos elogios :)

    Fique à vontade para usar esse exemplo, na verdade estamos todos explorando Myers em 1979 com o provável primeiro livro a falar inteiramente sobre teste de software :)

    Sim, o Gojko é fantástico! E sim, vários projetos da TW usam conceitos e práticas como SbE e Continuous Delivery.

    Bug fixed ;) thx!

  3. Olá Camilo!!!

    Realmente ficou excelente o post!!! Já recomendei para o pessoal que esta trabalhando conosco!!!!

    Abraços,

    Wagner Ruiz

  4. Massa cara! Curti muito esse post.

    Legal ver a comparacao de um Test Case antigo/tradicional com um no formato Given/When/Then, e o mais legal de tudo: ele ira’ rodar e te dar feedback :)

    Abraço!

    — Rodrigo Tolledo

  5. Olá Camilo!

    Tenho acompanhado seu blog e gosto muito, comecei este semestre o curso de Análise e Desenvolvimento de Sistemas e a trabalhar em uma empresa esta semana e estou aproveitando muito suas dicas.
    Faz uns 3 dias que estou com um problema, não consigo configurar minha máquina para “brincar” com o Cucumber!
    Como sou novo na área tenho dificuldades, mas tento aprender o máximo possível.
    Gostaria de saber se você dispõe de um tutorial passo a passo para configurar uma rvm do zero com o Cucumber+Rspec+Capybara. Achei vários tutoriais entretanto nada que funcionasse/explicasse realmente aquilo que se está fazendo, eu uso o Ubuntu 12.04

    Abraço e fico no aguardo!

    Antonio

  6. Muito obrigado João!

    Fico feliz que post tenha te ajudado, mesmo que um pouquino.

    Em breve deve sair o segundo post da série. Vou lembrar de te mandar um e-mail lembrando.

    Sinta-se a vontade para sugerir melhorias ou tópicos para posts futuros.

    Abraços,

    Camilo

  7. Olá dr. Rodrigo,

    Muito obrigado pelo comentário.

    Tenho certeza que seu TCC vai ser um material e tanto em português para muita gente que tem dúvidas sobre BDD e cucumber. Lembre-se de compartilhar com a gente :)

    Abraços,

    Camilo

  8. Olá Camilo Ribeiro, tudo bem?
    Me interesso muito sobre BDD e Agilidade.
    Esse post está com qualidade excelente.
    Mas o título “Quando não devo usar BDD?” você quis dizer “Quando devo usar BDD?”
    Pois você continua falando: “Na verdade a pergunta correta seria “Como eu não o devo usar BDD?”.”

    Valeu, sua contribuição me ajudou muito.
    Logo vou publicar o meu trabalho tb.
    Falou. Sucesso.

  9. Ola Camilo,
    Muito bom o seu artigo, me ajudou muito a entender sobre BDD.
    Tinha lido algumas coisas por ai mas nada tão esclarecedor como esse seu post =D
    Estou querendo fazer meu TCC nessa linha, você por acaso teria algum material que pudesse ajudar em um comparativo entre o JBehave e o Cucumber ?
    Desde ja muito obrigado pela contribuição com o post e meus parabéns por ele !

  10. Olá Thiago,

    Muito obrigado pelo comentário :)

    Eu nunca trabalhei com o JBehave na prática, só alguns exercícios.
    Sei que o JBehave foi a primeira ferramenta de BDD, portanto ele não tem algumas features mais novas.

    A comparação que você quer está aqui (muito completa por sinal):
    http://mkolisnyk.blogspot.com.br/2012/06/gherkin-bdd-engines-comparison.html

    Espero que te ajude e que em um futuro não muito distante, compartilhe a sua pesquisa conosco também =)

    Abraços

  11. Parabéns pelo artigo, aguardando ancioso os demais :) Sou tester e estou tentando fazer com que a equipe comece a utilizar o BBB (está dificil). Mas vou fazer a minha parte e ao menos escrever os testes antes da codificação da história, permitindo que neste primeiro momento o desenvolvedor ao menos faça um teste manual em cima dos cenários antes de considerar a história pronta. O exemplo mostrado neste artigo servirá de base :)

  12. Obrigado pela força :D

    Esse fim de semana comprei um livro novo sobre Cucumber chamado “Cucumber Recipes” que tem “receitas” de cucumber para todos os gostos, passando por java, microsoft, ruby e infra-estrutura. Com certeza vai me dar muito insumo para continuar a serie que está meio parada.

    Não desista. Caso precise de ajuda posta aqui ou manda um e-mail.

    Abraços!

  13. Estou usando o cucumber em java +BDD, alguém sabe como auto identar no .feature assim como Ctrl A + Crtl I no .java?.
    Obrigada

  14. Olá Elanor,

    Isso depende do IDE que está usando. No meu caso eu uso um plugin para o VIM[1], então é algo bem configurado pra mim. Você está usando o Eclipse, IntelliJ ou qual IDE?

    Abraços

  15. Para identar no “.feature” no eclipse, utilizando o plugin do cucumber, bastar clicar em Ctrl+Shift+F.

  16. Procurando mais infos sobre Cucumber para trabalhar com SpecFlow olha o que encontro..
    Parabéns pelo post.. e obrigado por agregar mais uma sigla ATDP ao meu vocabulário.

  17. olá Kelly,

    Muito Obrigado pela visita e pelo comentário.

    Sinta-se a vontade para sugerir melhorias. Vou trabalhar na continuação desse post nos próximos dias.

    Abraços.

    Camilo

  18. Camilo,

    Parabéns pela explicação bem direta e simples.
    Estou começando agora nesta fase de Qa e sou totalmente leigo no assunto.
    Você poderia me indicar alguns livros para estudo?

Leave a Reply