Cucumber Best Practices

Cucumber
Best practices
Karoline Leite

Karoline Leite
➔ Qualidade e Testes
Desde 2008
➔ Engineering team leader
Creditas
➔ Founder & Organizer
Test Girls

BDD is a collaborative
approach to software
development that bridges
the communication gap
between business and IT.

BDD helps teams communicate
requirements with more
precision, discover defects
early and produce software that
remains maintainable over time.

Boa prática
Automação de
testes é um
sub-produto do
BDD
O melhor drive é
prevenir
desperdício o
quanto antes
BDD não é sobre
teste de software

maintainable softwaresafe discovery
los three
amigos
discovery
workshops
specification
by example

Boa prática
Não se empolgue.
Respeite a pirâmide
de testes

Cucumber can be used to
implement automated
tests based on scenarios
described in your Gherkin
feature files.

Imperativo: Muitos detalhes, passo a passo
Declarativo: Conciso, direto ao ponto, poucos passos
Nível de abstração

Imperativo
Dado que eu abra o browser
E navegue para o site https://store.ministryoftesting.com
E clique no campo ‘Search’
Quando eu digitar ‘MUG’
E clicar em buscar
Então verei a página de busca mostrando os detalhes das canecas

Declarativo
Dado que eu esteja no e-commerce do Ministry of Testing
Quando eu fizer uma busca por caneca

Imperativo vs Declarativo

Boa prática
Menos é mais.
Menos passos,
menos
manutenção.
Detalhes da
implementação,
como IDs não
fazem sentido.
Foco deve ser no
comportamento.
Não tem certo ou
errado.
Experimente e
aprenda em
conjunto com seu
time.

Data Tables
Dado o valor dos itens que comprei
| 3 |
| 6 |
| 233 |
Quando a conta for somada
Então o total cobrado deve ser 238

Então("verei a página de busca mostrando os detalhes das canecas") do |table|
data = table.raw
end
Data Tables
data => [["posicao", "nome", "preco"], ["1", "Bug Mug", "£12.49"],
["2", "Mug - White", "£12.49"]]

Esquema do Cenário
O cenário é o mesmo, mas os dados mudam!
São necessários inputs diferentes.

Esquema do Cenário
Cenário 1 - Somar
Dado que eu acesse a calculadora
Quando eu adicionar o valor 1
E apertar o botão de somar
E eu adicionar o valor 1
Então será exibido 2 como resultado

Esquema do Cenário
Cenário 2 - Subtrair
E apertar o botão de subtrair

Esquema do Cenário
Cenário 3 - Multiplicar
E apertar o botão de multiplicar

Esquema do Cenário
Cenário 4 - Dividir
E apertar o botão de dividir

Esquema do Cenário
Quando eu adicionar o valor <first_value>
E apertar o botão de <operation>
E eu adicionar o valor <second_value>
Então será exibido <result> como resultado
Exemplos:
| first_value | second_value| operation | result |
| 1 | 1 | sum | 2 |
| 2 | 1 | subtraction | 1 |
| 4 | 3 | multiplication| 12 |
| 4 | 2 | divide | 2 |

Boa prática
Menos é mais.
Você realmente
precisa testar
com tantos dados
assim?
Quaisquer tipo de
tabela é difícil de
ler. Use com
parcimônia.
Não tenha receio
de reescrever se
perceber que a
tabela está ficando
grande.

Tags
Tags are a great way to organise your features and
scenarios.
Referenciar para execução de um grupo de cenários
“Escopar” os hooks a grupos de cenarios

Tags
@calculator @fast @ready
Cenário: Fazer soma na calculadora web
E apertar o botão de somar

$ cucumber features/ --tags @calculator
Tags

Tags
@calculator
@wip and not @slow
@smoke and @fast
@calculator or @spreadsheet

Tags são herdadas pelos elementos filhos.
Tags que são colocadas na Funcionalidade serão
herdadas pelos Cenários, Esquemas de Cenário e
Exemplos.
Tags que são colocadas no Esquema do Cenário serão
herdadas pelos Exemplos.
Tags
Herança de tags

@calculadora
Funcionalidade: Calculadora online
@website_search @gui
Cenário: Buscar caneca no site
Tags
Herança de tags

Tags
“Escopar” os hooks a grupos de cenarios?

Boa prática
Crie um sistema
de tags relevante
e use bastante.
Crie um glossário
de tags e
explique-o no
README.md do
projeto.

Hooks
Hooks are blocks of code that can run at various points
in the Cucumber execution cycle.
Before
After
Around
After|BeforeStep

Hooks
Before do
# Do something before each scenario
end

Hooks
After do |scenario|
if scenario.failed?
# tire um printscreen
end
end

Hooks
Around('@fast') do |scenario, block|
Timeout.timeout(0.5) do
block.call
end
end

Boa prática
Separe arquivos
diferentes por
tipo de hook.
after_hooks.rb
before_hooks.rb
Não dê muita
responsabilidade
para os hooks. Eles
são invisíveis na
execução.

Nested Steps
Invocar um ou mais steps dentro de outro é um recurso
interessante para reaproveitar código.

Nested Steps
Dado("que a usuária {string} exista") do |user|
###
end
Dado("que eu faça login como {string}") do |user|
###
end

Nested Steps
Dado("que {string} esteja logada") do |user|
end
steps %{
que a usuária #{user} exista
que eu faça login como #{user}
}

Boa prática
Use com cuidado.
O acoplamento
fica muito forte
entre os steps.
Nested steps é
um ótimo recurso
para um baixo
nível de
reaproveitamento
e legibilidade.

Reports
$ cucumber --format html --out reports.html

Reports
After do |scenario|
if scenario.failed?
print_name = "#{scenario.name}.png"
Capybara.page.save_screenshot("reports/#{print_name}")
embed("reports/#{print_name}", "image/png","#{scenario.name}")
end
end

Boa prática
Os reports são
uma ótima forma
de compartilhar
os resultados dos
testes. Faça deles
seus aliados.

Retry
Se você tem um cenário flaky, o ideal é investigar a causa
e corrigir o mais rápido possível.
Mas quando não for possível, é necessário lidar com ele
sem impactar sua suíte toda.

Retry
$ cucumber feature --retry 2
4 scenarios (2 failed, 1 flaky, 1 passed)

Boa prática
Quanto mais
tentativas você
colocar, mais o
resultado do teste
vai demorar em
caso de falhas.
Configure seu CI
para avisar
quando flaky
cenários
ocorrerem.

World object
In Ruby, Cucumber runs scenarios in a World.
You can add any behaviour to the World, like helper
methods, or logging, etc.

World object
module CPFHelper
def cpf_generator
# implemente aqui
end
end
World(CPFHelper)

Boa prática
Organize os
helpers em
arquivos e
módulos com
responsabilidades
claras.
Usar helpers ajuda
a manter o
desacoplado,
organizado e
reutilizável.

Page Objects
class Home < SitePrism::Page
set_url '/index.htm'
set_url_matcher(/google.com/?/)
element :search_field, 'input[name="q"]'
element :search_button, 'button[name="btnK"]'
end

Page Objects
The public methods represent the services that the page offers
Try not to expose the internals of the page
Generally don't make assertions
Methods return other PageObjects
Need not represent an entire page
Different results for the same action are modelled as different methods

Boa prática
Não faça
assertions nas
nas suas
PageObjects. Use
expectations a
seu favor.
Não retorne
PageObjects nos
métodos. O
Cucumber não vai
bem com esse
acoplamento.

Page Objects
def result_verify
# implementação, retorna true ou false
end
end

expect(@home.result_verify).to be true
Page Objects

def result_verify
# implementação, retorna true ou false
end
end
Page Objects

expect(@home.element.text).to eq(expected_text)
Page Objects

def search_item(name)
search_field.set(name)
search_button.click
return SearchResultPage.new
end
end
Page Objects

Dado("que eu faça uma busca por {string}") do |name|
page = Home.new
@next_page = page.search_item(name)
end
Page Objects

API Testing
Sua API também tem comportamento
É possível e faz sentido

Boa prática
É muito mais
tentador, mas
foque no
comportamento
da sua API, não na
implementação.
Organize os
payloads em
arquivos
separados dos
steps.
Crie seu API
objects para lidar
com cada
endpoint.

API Testing
Dado que eu me autentique na API do MoT
Quando eu fizer um post no endpoint “event/create”
Então o evento será criado
E o status retornado será 200

API Testing
Dado que eu me autentique na API do MoT
Quando eu enviar a criação de um novo evento
Então o evento será criado com sucesso

API Testing
Quando(“eu enviar a criação de um novo evento”) do
body = {
"id": "4",
"createdAt": "2019-03-18T08:14:59.675Z",
"name": "Handcrafted",
"local": "local 4"
}
end

API Testing
…
url = ‘https://mot-sp/events/create’
end

API Testing
…
...
response = HTTParty.post(url, :body => body)
end

API Testing
class MinistryOfTestingEventsAPI
include HTTParty
base_uri “https://mot-sp/events”
def create(body)
self.class.post(‘/create’, :body => body)
end
end

API Testing
→ create_body.json
{
"id": "4",
"createdAt": "2019-03-18T08:14:59.675Z",
"name": "Handcrafted",
"local": "local 4"
}

API Testing
body = File.read(‘create_body.json’)
api = MinistryOfTestingEventsAPI.new
response = api.create(body)
end

Dicas de ouro
Experimente
novas ideias e
abordagens.
Refatore seu
código sempre.
Comece simples
e pratique.
Compartilhe seus
aprendizados e
dúvidas com seu
time e com sua
comunidade.

THANKS!
@karolxavierleite
Twitter
@karolineleite
Blog
http://blog.howtotest.com.br/

Cucumber Best Practices

Mais conteúdo relacionado

Mais procurados (18)

Semelhante a Cucumber Best Practices (20)

Último (6)

Cucumber Best Practices