Cucumber: um breve review

Cucumber – Um breve review
Felipe Haack Schmitz, Henrique Becker e La´ıs de Figueiredo Berlatto
Universidade de Passo Fundo – Curso de Ciência da Computação
Disciplina de Qualidade e Teste de Software

2
0.1 Resumo
Introduz-se a ferramenta Cucumber, explicando-se a ligação da ferramenta com a técnica de
programação BDD. A relação do BDD com a ferramenta é demonstrada, tanto em termos do
design da mesma, quanto históricos. É feita uma revisão das várias linguagens e ambientes
suportados pela ferramente, sem, no entanto, o objetivo de ser um revisão exaustiva. O funci-
onamento básico da ferramenta é descrito, e apresenta-se um relatório da instalação e uso da
mesma, em um ambiente definido, para uma aplicação escolhida. Por fim, nas considerações
finais, é levanta-se a hipótese que a principal desvantagem encontrada na ferramenta possa
vir a ser considerada, também, a sua maior vantagem.
0.2 Introdução
Cucumber (pepino, em inglês) é uma ferramenta[1] e um framework[2] para automação de
testes de aceitação, fundamentada na técnica de programação BDD (Behavior Driven Deve-
lopment, em inglês, ou desenvolvimento orientado ao comportamento, em uma tradução li-
vre). O conceito desta ferramenta e a sua criação estão intrinsecamente ligados a essa técnica
de programação (“Embora Cucumber possa ser vista como uma ferramenta ‘para teste’, o
objetivo da ferramenta é dar suporte ao BDD”[1]), faz-se necessário, portanto, uma breve
descrição dessa técnica.
O BDD pode ser visto como uma evolução da técnica de programação TDD[3] (Test
Driven Development, em inglês, ou desenvolvimento orientado a testes, em uma tradução
livre), e compartilha com essa técnica a caracter´ıstica principal de se escrever testes antes de
escrever a implementação do que está sendo testado, para então desenvolvê-la até que o teste
passe. Outra forma de se ver o BDD é como uma nova compreensão sobre o processo de
TDD que estabelece que o teste não é o ponto central real da técnica, mas sim a descoberta e
compreensão, através da definição dos testes, do comportamento que está se querendo obter
com um código[4].
O processo de BDD incrementa o TDD de forma a resolver algumas questões em aberto1
com as seguintes práticas: cada funcionalidade deve ser claramente compreendida por am-
bas partes (desenvolvedores e clientes), para isso se deve usar uma linguagem para os ca-
sos de teste compreens´ıvel a ambas partes, uma vez que os casos de teste são na realidade
especificações de comportamento; cada funcionalidade deve possuir um valor claro e veri-
ficável para o negócio, de modo a priorizar o mais importante e evitar o que pode não vir
a ser necessário; deve-se planejar a frente o m´ınimo poss´ıvel, escrevendo testes para o me-
nor e mais prioritário subconjunto de funcionalidades poss´ıvel e o desenvolvendo antes de
adicionar mais funcionalidades[3].
1
Não se entrará em detalhes sobre estas questões, para mais informações leia http://en.wikipedia.
org/w/index.php?title=Behavior_Driven_Development&oldid=498181922

3
0.3 A ferramenta Cucumber
Cucumber foi, originalmente, escrito em Ruby e sua implementação de referência (e mais uti-
lizada) ainda o é[5], mas ela possui uma série de implementações em outras linguagens, como
veremos em uma das próximas seções. Independentemente disso, porém, o Cucumber pode
ser usado com diversas bibliotecas que simulam ou fazem interfaces com navegadores[1],
sendo poss´ıvel, desta forma, testar sites e aplicações web em, teoricamente, qualquer lingua-
gem com qualquer de suas implementações.
Cucumber funciona basicamente através da leitura de arquivos com a extensão feature,
os quais descrevem em linguagem natural uma funcionalidade e casos de teste (chamados
cenários) para a mesma. Como os testes estão escritos em uma linguagem natural, e não de
programação, Cucumber precisa pesquisar pelo código associado aos “passos” que formam
o cenário em arquivos fonte auxiliares. A linguagem em que o código estará depende da
implementação do Cucumber (na de referência é Ruby). O “passo” (step, no original, em
inglês) é o nome dado a cada linha em linguagem natural (nos arquivos feature) com uma
porção espec´ıfica de código associada a ela, em um arquivo fonte auxiliar, a essa porção de
código é dado o nome de “definição do passo” (step definition, no original, em inglês)[6].
O uso do Cucumber pode ou não implicar na programação em Ruby (ou na linguagem
da implementação utilizada). Caso se utilize uma biblioteca de definições de passo pronta é
poss´ıvel somente escrever os arquivos feature a fim de utilizar o Cucumber. Esse comporta-
mento, no entanto, foi criticado[7] causando repercursões no uso dessas bibliotecas.
A interpretação dos arquivos feature é feita pelo Gherkin. Gherkin é o nome dado a lin-
guagem usada nos arquivos feature para o uso de linguagem natural, que consiste em alguma
poucas palavras-chave fixas e regras de identação, e é, também, o nome do interpretador dessa
linguagem2
. Algumas implementações (em especial a de referência) fazem uso do Guerkin,
outros reimplementam sua funcionalidade em sua linguagem[5]. Gherkin é considerada uma
linguagem de dom´ınio espec´ıfico, leg´ıvel para todos os envolvidos no negócio (o termo usado
no original, em inglês, é Business Readable, Domain Specific Language)[8].
O arquivo feature do Cucumber é considerado uma “especificação executável” e, também,
uma “documentação viva”[9, p.1]. Ambos termos estão ligados ao fato destes arquivos ser-
virem de documentação, testes automatizados e suporte ao desenvolvimento em um único
formato[10]. Uma especificação do comportamento do sistema que cresce com ele, e pode
ser usada para verificar sua conformidade de forma automatizada.
0.4 Histórico
A história do desenvolvimento do Cucumber é intrinsecamente ligada a criação do BDD
como já foi dito na introdução a ferramenta. Dan North, criador do BDD, iniciou, em final de
2003, a escrita de uma ferramenta para Java com o intuito de substituir o framework JUnit,
com uma alternativa ligada ao BDD, chamada JBehave[11]. Em março de 2006 um artigo
2
A implementação do Gherkin usada pela implementação de referência do Cucumber se encontra em:
https://www.ruby-toolbox.com/projects/gherkin

4
introduzindo BDD foi publicado por ele na revista “Better Software”3
. No final deste artigo
ele fala que Dave Astels estava promovendo a criação de uma versão do JBehave (que era
para Java) para Ruby, o RBehave, na qual ele estava também envolvido.
O RBehave é integrado ao RSpec em torno de outubro de 2007, de forma que David
Chelimsky adiciona suporte a texto plano, evitando que as histórias tenham de ser escritas
em códigos-fonte em Ruby. O RSpec foi inspirado pelo Cucumber[12] e é hoje a ferramenta
mais popular dentro da categoria “Testing Frameworks” segundo o site “The Ruby Toolbox”4
,
Cucumber é mostrada como a ferramenta mais popular dentro da categoria “Acceptance Test
Frameworks”.
Em abril de 2008, Aslak Hellesøy começa o projeto Cucumber a fim de corrigir alguns
problemas no “RSpec Story Runner”[10]. Outros programadores citados na página oficial
do projeto5
também contribu´ıram a partir dali com melhoramentos pontuais e a manutenção
do projeto Cucumber. Em julho de 2011, o blog do site BestVendor6
divulgou uma pesquisa
feita com 550 empregados em novas empresas, sendo metade delas na área de tecnologia, nela
Cucumber aparece como a quinta ferramenta mais usada na seção “Frameworks de teste” com
9%, enquanto RSpec aparece em primeiro lugar com 18%[13].
0.5 Ambientes e linguagens suportados
A primeira (e a principal atualmente) implementação do Cucumber foi escrita em Ruby. Isso
significa que Cucumber executa sobre qualquer plataforma que possua suporte à linguagem
Ruby. A seção de downloads do site oficial da linguagem Ruby7
aponta os métodos para
sua instalação nas seguintes plataformas: Linux (Debian e Arch possuem pacotes prontos),
MacOS (Tiger, Lion, Leopard e para Snow Leopard), Solaris (8 ao 10) e OpenIndiana e
Windows. Além disso é poss´ıvel executar Ruby em qualquer plataforma que tenha uma
JVM com suporte a JRuby. Algumas versões do Cucumber portadas para outras linguagens
apresentadas nesta seção também podem extender as plataformas nas quais se pode fazer
uso do Cucumber. Os fontes da implementação de referência da linguagem estão escritos
em C, e teoricamente também seria poss´ıvel executá-lo sobre plataformas que possuam um
compilador C para sua arquitetura.
Cucumber não tem nenhuma IDE padrão[9], embora possam ser encontrados plugins para
várias IDE’s genéricas. Algumas das IDE’s que possuem suporte ou plugin para o Cucumber
são: Eclipse8
, NetBeans9
, Visual Studio10
, Vim11
e Emacs12
.
3
O artigo encontra-se dispon´ıvel, também, no seguinte endereço: http://dannorth.net/
introducing-bdd/
4
Cujo o endereço é: https://www.ruby-toolbox.com/
5
O endereço da página oficial do projeto Cucumber é: http://cukes.info/
6
Cujo o endereço é: http://blog.bestvendor.com/
7
A página oficial da linguagem Ruby se encontra no seguinte endereço: http://www.ruby-lang.
org/en/downloads/
8
Dispon´ıvel em: http://github.com/QuBiT/cucumber-eclipse-plugin
9
Dispon´ıvel em: http://www.pmamediagroup.com/2009/04/
what-netbeans-651-can-now-recognize-my-cucumber-feature-files/
10
Dispon´ıvel em: http://github.com/henritersteeg/cuke4vs
11
Dispon´ıvel em: http://www.vim.org/scripts/script.php?script_id=2973
12
Dispon´ıvel em: https://github.com/michaelklishin/cucumber.el

5
Cucumber (em pelo menos sua principal implementação) se integra com várias bibliote-
cas, as quais lhe permitem controlar um navegador. Desta forma é poss´ıvel testar aplicações
Web escritas em qualquer linguagem, com uma boa variedade de opções de biblioteca e
navegadors. Algumas das opções de bibliotecas são: Webrat, Capybara, Watir WebDriver,
Celerity e Selenium WebDriver13
, alguns dos navegadores suportados por elas são: Internet
Explorer, Opera, Mozilla Firefox, Chrome, e navegadores próprios sem interface com e sem
suporte a Javascript.
Observa-se que, no caso da implementação principal ao menos, as definições dos passos
ainda terão de ser escritas em Ruby para os casos descritos acima. No entanto, Cucumber
também foi portado para ser capaz de interagir com várias outras linguagens, e escrever
as definições de passos nelas. Há, por exemplo, o Cucumber-JVM, o qual possui suporte
nativo, não só a Java como, também, Scala, Groovy, Clojure, Ioke, e suporte através de
interpretadores a JavaScript (pelo interpretador Rhino), Python (pelo interpretador Jython) e
Ruby (pelo interpretador JRuby). Ele é o sucessor do Cuke4Duke que era a implementação
principal do Cucumber (em Ruby), rodando através do JRuby[14][15]. Pode-se executar o
Cucumber-JVM através da linha de comando ou do JUnit (e por consequencia através de
qualquer coisa que use o JUnit).
Algumas outras linguagens suportadas são C++14
, Haskell15
, Lua16
, Ada17
, PHP18
, .NET19
,
Perl20
, Objective-C (permitindo assim testar aplicações para o iPhone, mas não no iPhone,
com Cucumber21
), entre outras, não sendo viável uma lista exaustiva.
Observa-se também, que uma busca no GitHub22
(atualmente o site mais popular para
hospedagem de código aberto[16], e onde está hospedado o projeto Cucumber original), em
22 de junho de 2012, por repositórios com a palavra chave “cucumber” na descrição ou nome
do projeto, retornaria 1185 resultados categorizados em 27 linguagens. Não foi viável para
escrita deste trabalho a verificação de quantos desses projetos são relacionados à ferramenta
Cucumber e seu grau de relevância. Uma rápida observação dos cem primeiros resultados
indicou que poucos destes repositórios não estavam relacionados a ferramenta.
Outros suportes a interações da ferramente com aplicações encontradas, mas que não
caem exatamente na categoria linguagens ou ambientes suportados foram: o uso do Cu-
cumber como shell script[17], a interação de Cucumber com o Excel[18], e com interfaces
WPF[19].
13
Para uma lista mais completa favor acessar: https://github.com/cucumber/cucumber/wiki/
14
Através do projeto cucumber-cpp, https://github.com/cucumber/cucumber-cpp/
15
Através do projeto haskell-cucumber, https://github.com/sakari/haskell-cucumber
16
Através do projeto calabash, https://github.com/pib/calabash/tree/
2c837819bd3d5c9fa618a06f898c5fc80c2bf480
17
Através do projeto XReq, http://xreq.forge.open-do.org/
18
Através do projeto Cuke4PHP, https://github.com/olbrich/cuke4php/wiki
19
Pelo projeto IronRuby, https://github.com/cucumber/cucumber/wiki/
IronRuby-and-.NET
20
Para a qual constam algumas implementações no GitHub, https://github.com/search?q=
cucumber&repo=&langOverride=&start_value=1&type=Repositories&language=
Perl
21
Projeto iCuke, https://github.com/unboxed/icuke
22
Essa busca pode ser re-executada per meio do seguinte endereço: https://github.com/search?
langOverride=&language=&q=cucumber&repo=&start_value=5&type=Repositories

6
0.6 Funcionamento básico
Começaremos a explanação sobre o funcionamento do Cucumber pelo arquivo feature, e seu
formato, que é a principal entrada da ferramenta. Cada arquivo de feature tem por objetivo
descrever uma funcionalidade, para quem ela tem valor, e porque tem valor. Arquivos do
tipo feature são divididos em duas seções, a feature (funcionalidade) em si, e os scenario
(cenários)[6].
Excerto de código 1 A seção feature do arquivo addition.feature
Feature: Addition
In order to avoid silly mistakes
As a math idiot
I want to be told the sum of two numbers
A seção feature é formada pelo nome da funcionalidade e uma história. O nome da
funcionalidade pode ser usado para se referir a esta posteriormente, e a história não tem de
seguir obrigatoriamente nenhum formato, nem tem alguma utilidade para ferramenta. Ela
que dá uma descrição informal da funcionalidade e explicita para quem ela é importante e
motivo. A história está relacionada à filosofia do BDD, em espec´ıfico, com um de seus três
principios básicos, o de que qualquer funcionalidade deve ter um valor claro e verificável
para o negócio[3]. Como foi dito, ela não possui nenhum formato obrigatório, no entanto,
a convenção usada nos exemplos proporcionados nos exemplos do repositório que contêm a
ferramenta e em sua Wiki é “In order ...As a ...I want ...” (Para ...Como um ...Eu quero
...). Outra convenção é “As a ...I want ...so that ...” (Como um ...eu quero ...de modo
que ...), introduzida por Dan North (criador do BDD), em março de 2006, em um artigo de
introdução ao BDD[11].
Excerto de código 2 Uma seção scenario do arquivo addition.feature
Scenario: Add two numbers
Given I have entered 50 into the calculator
And I have entered 70 into the calculator
When I press add
Then the result should be 120 on the screen
Um arquivo feature possui uma seção feature e um número qualquer de seções scenario.
Os cenários são basicamente casos de teste em alto n´ıvel, a intenção deles é formar a descrição
do comportamento da funcionalidade. Um cenário é formado pelo seu nome e pelos seus
passos. Os passos são cada linha dentro da definição de um cenário[6]. Há três principais
palavras chave que iniciam um passo, elas são: Given (Dado que), When (Quando), e Then
(Então). Given é usado para inicializar o ambiente daquele cenário. When é usado para
descrever as ações que devem ser executadas durante o teste. Then verifica se o teste deu o
resultado esperado. Elas normalmente são dadas na ordem que foi apresentada. A palavra
chave And (e), também pode ser usada para adicionar mais um passo, ela terá o mesmo
significado da palavra-chave do passo imediatamente anterior[2].

7
Excerto de código 3 O fonte addition steps.rb que define os passos utilizados anteriormente
Before do
@calc = Calculadora.new
end
After do
end
Given /I have entered (.+) into the calculator/ do |n|
@calc.push n.to_i
end
When ’I press add’ do
@result = @calc.soma
end
Then /the result should be (.+) on the screen/ do |result|
@result.should == result.to_i
end
A definição dos passos descritos nos arquivos feature é feita em códigos-fonte da lingua-
gem utilizada pela implementação do Cucumber. A sintaxe exata para definição do passo
varia para cada implementação do Cucumber em uma diferente linguagem. Aqui foi apre-
sentada a sintaxe em Ruby. As definições de passo usualmente consistem na palavra-chave
correspondente e uma expressão regular que casa com o texto correspondente, escrito após a
palavra-chave, no arquivo feature.
Uma expressão regular é uma forma de denotar padrões23
em cadeias de caracteres. O
excerto “(.+)”, por exemplo, pode ser decomposto em três componentes, o “.”, o “+” e os
parentêses envolvendo-os. O “.” casa com um caracter qualquer, e o “+” muda o significado
do s´ımbolo anterior (o “.” neste caso) para casar com uma ou mais ocorrências do mesmo
(neste caso um ou mais caracteres). Os parênteses informam que a porção de texto que for
casada com a expressão dentro deles deve ser capturada como argumento (no caso do exemplo
isso significa que a sequência de d´ıgitos naquela posição da cadeia definirá o valor de n, ou
result).
O uso de uma expressão regular, como pode ser visto acima, só é necessário caso seja
necessário capturar uma determinada porção váriavel do texto como argumento para o código
da definição do passo.
As seções “Before do ...end” (Antes faça ...fim) e “After do ...end” (Depois faça
...fim) são “hooks” (ganchos), elas permitem definir um bloco de código para ser execu-
tado antes e depois, respectivamente, de cada cenário.
A convenção de organização dos arquivos do Cucumber é a seguinte: a pasta base se
23
O artigo da wikipedia em inglês possui uma boa introdução a espressões regulares: http://en.
wikipedia.org/wiki/Regex

8
chama “features”, dentro dela deve haver os arquivos feature e a pasta “step definitions”,
que contêm os códigos-fonte que definem os passos. Pode haver, também, dentro da pasta
“features”, a pasta “support”, nela devem estar quaisquer inicializações globais comuns para
mais de um arquivo de funcionalidade, o nome convencional ao fonte principal desta pasta é
“env”[20].
A sa´ıda do Cucumber é normalmente o texto dos arquivos feature de entrada, colorindo
cada passo conforme seu estado, e mais um pequeno resumo dos resultados dos testes. Caso
você execute o Cucumber sem ter definido os passos ele lhe sugerirá os cabeçalhos das
definições para preenchimento dos blocos de código. Há vários estados que um passo pode
assumir, os mais comuns são passed (passou), failed (falhou), undefined (não definido) e skip-
ped (ignorado), cujas cores padrão são respectivamente verde, vermelho, amarelo e ciano. O
significado de cada estado, passed, failed, undefined e skipped, são, repectivamente, o passo
ocorreu sem erro, o passo causou um erro ao executar, não foi encontrada uma definição para
o passo, e o passo foi ignorado porque o anterior falhou.
0.7 Passos para instalação
Nesta seção descrevem-se os passos usados para instalação do Cucumber e de algumas bibli-
otecas relacionadas. Estes passos são necessários para a reprodução dos exemplos de caso de
teste apresentados em uma das próximas seções. Esses passos e os casos de teste foram exe-
cutados sobre uma máquina com a distribuição Ubuntu 12.04 (precise) 64-bit, com o kernel
3.2.0-23-generic.
Instalou-se o gerenciador de pacotes padrão do Ruby, RubyGems, na versão 1.8, que era
uma das dispon´ıveis no gerenciador de pacotes da distribuição. A partir do RubyGems, então,
se instalou o Cucumber, o RSpec e o Watir. O RSpec é um framework de BDD para Ruby
e o Watir é uma biblioteca que permite o controle, por meio de código Ruby, de diversos
navegadores. Executou-se o de uso do Cucumber com o Watir da pasta de exemplos do
repositório do Cucumber para verificar a instalação. Para que este funcionasse corretamente
foi necessário fazer duas pequenas modificações nos fontes do exemplo.
Excerto de código 4 Comandos usados para instalação do Cucumber e demais gemas
$ sudo apt-get install rubygems
$ export PATH=/var/lib/gems/1.8/bin:$PATH
$ sudo gem install cucumber
$ sudo gem install rspec
$ sudo gem install watir-webdriver
0.8 Caso exemplo de uso da ferramenta
Demonstrar-se-á, nesta seção, um exemplo do uso da ferramenta Cucumber, para o teste de
uma aplicação Web, no ambiente descrito na seção anterior. O software a ser testado é uma
simples aplicação Web, desenvolvida pelos autores, que permite fazer a média aritmética de

9
Excerto de código 5 Versão final do arquivo env.rb do exemplo com o Watir, adaptado para
usar a versão instalada do Watir
begin require ’rspec/expectations’; rescue LoadError;
require ’spec/expectations’; end
require ’watir-webdriver’
Browser = Watir::Browser
browser = Browser.new
Before do
@browser = browser
end
# "after all"
at_exit do
browser.close
end
Excerto de código 6 A linha comentada e adicionada, respectivamente, ao arquivo se-
arch steps.rb, devido à mudança do nome do botão do Google
# @browser.button(:name, ’btnG’).click
@browser.button(:name, ’btnI’).click

10
Figura 1: Sa´ıda do Cucumber sobre o exemplo
um conjunto qualquer de valores. A funcionalidade a ser testada é a única da aplicação que é
o cálculo da média aritmética.
Excerto de código 7 O conteúdo do arquivo arithmetic mean.feature
Feature: Arithmetic mean
The user inform two numbers positive
And He want to know
The their arithmetic mean
Scenario: Arithmetic mean
Given I have the number 20
And I have the number 30
When I ask for the arithmetic mean
Then I should be given the value 25
Scenario: Input error
Given I have the number 1
And I have the number a
When I ask for the arithmetic mean
Then I should be given the value Expressão inválida!
Foi usado o mesmo código do arquivo env.rb para definição do browser usado pelo exem-
plo do Watir, descrito no excerto 5. A organização dos arquivos seguiu a convenção do
Cucumber explicada na seção “Funcionamento básico”. A linha de comando utilizada para
executar o Cucumber é a demonstrada no excerto 9, ela foi chamada de dentro da pasta fea-
tures, e teve a sa´ıda apresentada na figura 1.
A execução dos testes faz o navegador Mozilla Firefox abrir, carregar a página com a
aplicação Web, preencher o campo, clicar o botão e checar o resultado contra o especificado
no cenário. As pausas de dois segundos foram feitas para que o processo de teste pudesse ser
observado. Nem as pausas, nem o uso de um navegador interface seriam usados em um teste
automatizado, salvo a poss´ıvel necessidade de testar a compatibilidade com o browser em es-
pec´ıfico ou o acompanhamento humano do teste. Uma screenshot da aplicação é apresentada
na figura 2.

11
Excerto de código 8 O fonte arithmetic mean steps.rb que define os passos utilizados ante-
riormente
numbers = []
Given /I have the number (.+)/ do |numero|
numbers << numero
end
When /I ask for the arithmetic mean/ do
@browser.goto ’http://inf.upf.br/˜106396’
sleep 5
@browser.button(:id, ’clean’).click
sleep 5
expressao = ""
for i in 0..numbers.length-1
if i < numbers.length-1
expressao = expressao + numbers[i] + ", "
else
expressao = expressao + numbers[i]
end
end
@browser.text_field(:id, ’dados’).set(expressao)
sleep 5
@browser.button(:id, ’calc’).click
sleep 5
end
Then /I should be given the value (.+)/ do |resultado|
resultado.should == @browser.text_field(:id, ’resultado’).value
sleep 5
numbers.clear
end
Excerto de código 9 Linha de comando utilizada para executar o Cucumber sobre o exemplo
$ cucumber -r features/step_definitions/arithmetic_mean_steps.rb
-r features/support/env.rb

12
Figura 2: Captura da execução do navegador durante o teste
0.9 Considerações Finais
Cucumber é uma ferramenta que suporta uma ampla variedade de linguagens e ambientes,
não sendo isso razão para não adotá-la. Cucumber, no entanto, como foi visto, é intrinse-
camente ligado à filosofia do BDD, sendo uma ferramenta que dificilmente seria adotada
por um grupo que não tivesse conhecimento de, ou pretendesse utilizar-se, dessa técnica de
programação. Não é somente a história do BDD que é ligada ao Cucumber, mas o BDD
também influenciou por completo a concepção da ferramenta.
A compreensão do funcionamento da ferramenta, principalmente em relação ao sistema
de passos em linguagem natural e as definições dos passos em código, pode ser confusa em
princ´ıpio. Essa confusão pode ser creditada a aparente falta de motivos para esta organização.
Essa separação leva a ter de se manter dois artefatos sincronizados, ao invés de só um código
de testes, logo deve haver um vantagem nela. A primeira vantagem que poderia ser inferida é
que, a partir de um determinado momento, se passaria a usar somente as definições de passos
já prontos, e se manteria somente um artefato o qual pode ser lido também pelos clientes do
negócio. Essa assunção, no entanto, é invalidada pelas cr´ıticas de que o uso de biblioteca
de passos prontos levava à escrita de cenários dif´ıceis de ler, tediosos e em baixo n´ıvel de
abstração[7], as quais tiveram respaldo da comunidade.
Podemos compreender essa decisão do design da ferramenta se considerarmos que a des-
vantagem de ter de dar manutenção a esses dois artefatos sincronizados é, também, uma van-
tagem. Se cada modificação na especificação do comportamento da ferramenta (o arquivo
feature) quebra os testes e força a observar o seu código, e cada alteração do código leva a
reflexão se o passo ainda é refletido por aquela nova definição, se ganha uma especificação
que é técnica e não-técnica simultaneamente e que liga forçosamente ambos os lados. Dessa
forma, a especificação do comportamento do sistema é unificada, e a mudança dos pontos
de vista de cada um dos lados (desenvolvedores e clientes) passa a forçar a observação desta
pelo outro.

Referências Bibliográficas
[1] TEAM, C. Cucumber Wiki. 2012. [Online; acessado em 25/06/2012]. Dispon´ıvel em:
<https://github.com/cucumber/cucumber/wiki/>.
[2] ASTELS, D. Introduction to BDD with Cucumber. 2009. [Online; acessado em
25/06/2012]. Dispon´ıvel em: <http://www.engineyard.com/blog/2009/
cucumber-introduction/>.
[3] AL., D. N. et. Behavior-Driven Development. 2009. [Online; acessado em 25/06/2012].
Dispon´ıvel em: <http://behaviour-driven.org/>.
[4] RIMMER, C. et al. Introduction – Behavior-Driven Development. 2010. [Online;
acessado em 25/06/2012]. Dispon´ıvel em: <http://behaviour-driven.org/
Introduction>.
[5] LAWRENCE, R. Cucumber. 2011. [Online; acessado em 25/06/2012]. Dispon´ıvel em:
<http://www.methodsandtools.com/tools/cucumber.php>.
[6] HELLESøY, A.; SCOTT, A.; SEDEñO, D. Feature Introduction - Cucumber Wiki.
2012. [Online; acessado em 25/06/2012]. Dispon´ıvel em: <https://github.com/
cucumber/cucumber/wiki/Feature-Introduction>.
[7] HELLESøY, A. The training wheels came off. 2011. [Online; acessado em 25/06/2012].
Dispon´ıvel em: <http://aslakhellesoy.com/post/11055981222/
the-training-wheels-came-off>.
[8] HELLESøY, A. et al. Gherkin - Cucumber Wiki. 2011. [Online; acessado em
25/06/2012]. Dispon´ıvel em: <https://github.com/cucumber/cucumber/
wiki/Gherkin>.
[9] FLORINIER, D. de; ADZIC, G. The Secret Ninja Cucumber Scrolls: Strictly Confiden-
tial. 2010. Dispon´ıvel em: <http://cuke4ninja.com/>.
[10] TEAM, C. Cucumber – Making BDD Fun. 2012. [Online; acessado em 25/06/2012].
Dispon´ıvel em: <http://cukes.info/>.
[11] NORTH, D. Introducing BDD. 2006. [Online; acessado em 25/06/2012]. Dispon´ıvel
em: <http://dannorth.net/introducing-bdd/>.
13

14
[12] GIBBS, E. JBehave and RSpec History. 2007. [Online; acessado em
25/06/2012]. Dispon´ıvel em: <http://edgibbs.com/2007/12/02/
jbehave-and-rspec-history/>.
[13] VENDOR, B. The Startup’s Toolkit. 2011. [Online; acessado em
25/06/2012]. Dispon´ıvel em: <http://blog.bestvendor.com/2011/07/
survey-results-the-startups-toolkit/>.
[14] HELLESøY, A. Cucumber-JVM 1.0.0. 3 2012. [Online; acessado em 25/06/2012].
Dispon´ıvel em: <http://aslakhellesoy.com/post/20006051268/
cucumber-jvm-1-0-0>.
[15] TEAM, C.-J. Cucumber JVM – Github. 2012. [Online; acessado em 25/06/2012]. Dis-
pon´ıvel em: <https://github.com/cucumber/cucumber-jvm>.
[16] FINLEY, K. Github Has Surpassed Sourceforge and Google Code in Popularity. 6 2011.
[Online; acessado em 25/06/2012]. Dispon´ıvel em: <http://www.readwriteweb.
com/hack/2011/06/github-has-passed-sourceforge.php>.
[17] HOLMWOOD, L. Using Cucumber as a scripting language. 11 2009.
[18] DOMOKOS, A. Testing Excel with Cucumber. 3 2010. [Online; acessado
em 25/06/2012]. Dispon´ıvel em: <http://www.adomokos.com/2010/03/
testing-excel-with-cucumber.html>.
[19] HALL, B. Testing a WPF UI using Ruby, Cucumber and WiP-
Flash.dll. 3 2010. [Online; acessado em 25/06/2012]. Dispon´ıvel
em: <http://codebetter.com/benhall/2010/03/16/
testing-a-wpf-ui-using-ruby-cucumber-and-wipflash-dll/>.
[20] GROUP, A. T. S. Cucumber Test Engine (Ruby). 10 2009. [Online; acessado
em 25/06/2012]. Dispon´ıvel em: <http://autotestgroup.com/en/blog/77.
html>.

Cucumber: um breve review

Mais conteúdo relacionado

Mais procurados (17)

Semelhante a Cucumber: um breve review (20)

Mais de Laís Berlatto (19)

Último (19)

Cucumber: um breve review