Cucumber é uma ferramenta que suporta Behavior Driven Development (BDD), traduzindo ao pé da letra significa: “desenvolvimento orientado por comportamento”, simples assim,ou seja, BDD nada mais é do que descrever os COMPORTAMENTOS de um sistema utilizando linguagem Gherkin.
O que é Gherkin ?
Gherkin é uma linguagem natural que tanto o cucumber quanto todos os interessados(usuários, desenvolvedores, testadores, etc…) entendem, dessa forma, todas as necessidades reais do usuário e projeto são descritas, gerando uma documentação viva e valor pro negócio.
Não altere a estrutura padrão
Como já sabemos, o cucumber utiliza linguagem gherkin, que é uma linguagem natural e de fácil entendimento, porém possui algumas palavras “chaves” e são elas:
Dado (Given)
O “Dado” seria básicamente as pré-condições do cenário.
Quando (When)
O “Quando” serve descrever as ações chave que o usuário executa, resumidamente seria qualquer ação de interação do usuário com o sistema.
Então (Then)
O “Então” visa mostrar as saídas, os resultados das ações executadas, seriam basicamente os resultados esperados.
Exemplo:
Dado número A
Quando somar A+B
Então resultado deve ser C
Portanto mantenha sempre esse padrão: Dado, Quando, Então. NÃO altere isso e NÃO repita essas palavras no mesmo cenário, para não repetir essas palavras, caímos no segundo tópico das melhores práticas.
Faça uso do “E” e “Mas”
E (And)
O “E” visa complementar qualquer uma das palavras chaves citadas anteriormente, por exemplo:
Dado número A
E número B
Quando somar A+B
E dividir por C
Então resultado deve ser D
Mas (But)
O “Mas” seria a forma negativa do “Então”, basicamente, quando o resultado esperado for que o usuário NÃO DEVE receber.
Dado número A
E número B
Quando somar A+B
E dividir por C
Então resultado deve ser exibido
Mas não deve ser igual a D
Use “Contexto” e ganhe tempo
Uma regra básica que serve para a vida, se você está fazendo o mesmo trabalho duas vezes, de duas uma, ou você não fez direito, ou algo de errado não está certo.
No cucumber é para isso que existe o contexto(background), para remover aquilo que está sendo repetido em todos os cenários e centralizar em um único lugar, no caso o contexto. Vamos dar um exemplo para ficar bem mais fácil e compreensível.
Reparem que no exemplo acima, a seguinte linha está sendo repetida em todos os cenários:
Dado que eu esteja logado
Vamos ao “Contexto”
Viu como diminuímos o retrabalho? Mais fácil do que fazer regime!
O “Contexto” é bom quando usado para coisas simples, não é recomendável utilizar para cenários mais complexos complexas.
O “Contexto” é executado antes de cada um dos cenários, mas após qualquer um dos Hooks.
Use tags
#VemNeMimSextaFeira, é praticamente a mesma coisa, só que no lugar da hashtag, utiliza o @. Com isso você consegue filtrar e executar cenários específicos, por exemplo:
@validar_login @crítico @wip @cadastrar_cliente
Pode utilizar mais de uma tag por funcionalidade
Seja mais comportamental do que procedural
Não escreva todos os passo a passo de cada cenário, basta descrever o comportamento. exemplo:
Dado que o usuário esteja na tela de login
Quando preencher o campo usuário
E preencher o campo senha
E clicar no botão entrar
Então o sistema deve logar
e exibir dashboard
Pode isso Arnaldo ? Poder pode, mas não é recomendável, o mais correto seria:
Dado que o usuário esteja na tela de login
Quando informar os dados válidos
Então o sistema realizar o login
E o sistema exibir mensagem de “Bem Vindo”
Sempre descreva na terceira pessoa
Pare de utilizar “eu” nas descrições dos cenários, procure utilizar sempre na terceira pessoa. Reparem no cenário abaixo:
Dado que eu esteja…
Quando eu adiciono…
Não, não é assim! utilize na terceira pessoa.
Dado que o usuário ou o cliente esteja logado
Quando usuário ou cliente adicionar um produto no carrinho
Melhorou ?
Utilize Scenario Outline
Quando os cenários têm validações e resultados parecidos, podemos utilizar os Scenarios Outline, ou Esquemas de cenário. Vamos ao exemplo:
Cenário: mostrar o resultado quando executar uma operação de adição
Dado que o usuário esteja na calculadora
Quando pressionar o número 4
E pressionar o número 2
E escolher adição
Então o sistema devera mostrar o resultado igual à 6
Cenário: mostrar o resultado quando executar uma operação de subtração
Dado que o usuário esteja na calculadora
Quando pressionar o número 4
E pressionar o número 2
E escolher subtração
Então o sistema devera mostrar o resultado igual à 2
Cenário: mostrar o resultado quando executar uma operação de multiplicação
Dado que o usuário esteja na calculadora
Quando pressionar o número 4
E pressionar o número 2
E escolher multiplicação
Então o sistema devera mostrar o resultado igual à 8
Repare que são praticamente as mesmas validações, para facilitar tanto na implementação e na manutenção, existe no cucumber os scenarios outline. E ficaria da seguinte maneira:
Cenário: mostrar o resultado quando executar uma operação na calculadora Dado que o usuário esteja na calculadora Quando pressionar o <número1> E pressionar o <número2> E escolher a <operação> Então o sistema devera mostrar o <resultado>
Exemplo:
| numero1 | numbero2 | operação | resultado|
| 4 | 2 | soma | 6 |
| 4 | 2 | subtração | 2 |
| 4 | 2 | multiplicação | 8 |
| 4 | 2 | divisão | 2 |A primeira linha da tabela representa as variáveis escritas assim <variável> nos cenários e as outras linhas são os exemplos para execução dos testes com seus respectivos resultados esperados.
Viu como fica mais fácil de escrever e manter os cenários? Além de serem mais legíveis também.
Organize Diretórios
Existem outras formas de organizar os diretórios dentro do projeto. Porém uma boa prática é criar uma pasta Features e dentro dela criar as seguintes subpastas: pages, onde vão ficar todos os objetos de cada pagina(não precisa se preocupar com isso agora), specifications, onde vão ficar todos os comportamentos do sistema escrito em cucumber, step_definitions, onde vão ficar todos os passo a passo gerados a partir das nossa especificações e support, onde vão ficar algumas configurações, conforme exemplo abaixo:
