BDD com Cucumber + Java +
Selenium
Sandy Maciel
AGENDA
● BDD
● Cucumber + Selenium + Java
● Exemplo
O QUE É BDD?
Behavior Driven Development
3 Princípios do BDD
1 - O SUFICIENTE É SUFICIENTE.
2 - ENTREGAR VALOR PARA OS STAKEHOLDERS.
3 - TUDO É COMPORTAMENTO.
Com isso, esse artefato pode ser utilizado como
documentação, automatização de testes e auxílio aos
desenvolvedores. Tanto os desenvolvedores quanto os
analistas de testes, bem como o próprio cliente, podem
escrever os casos de teste/critérios de aceitação, visto
que eles serão escritos em linguagem natural.
Critérios de Aceitação
vs
Casos de Teste Behavior Driven Development
Acceptance Criteria
User Story
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
Critério de Aceitação
● 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.*
Vantagens do 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 tecnicamente é teste de unidade, integração ou sistema, mas com
valor de teste de aceite;
● BDD é teste que evita defeito não que encontra defeitos;
CUCUMBER +
JAVA +
SELENIUM
Com ele, as funcionalidades do sistema são escritas
em arquivos de texto e em uma linguagem de domínio
específico chamada Gherkin, muito semelhante à
linguagem natural, mas que contém algumas palavras
chaves.
CUCUMBER
VISÃO DO GERAL
DO CUCUMBER
Os testes de BDD são compostos, basicamente, por
arquivos que especificam as funcionalidades (“features”)
e por arquivos de definição de passos (“steps”). Os
arquivos com as funcionalidades são compostos por
cenários, que exemplificam uma ou mais regras de
negócio do sistema.
EXEMPLO
Veja os passos para a utilização desse framework:
1. Descreva um comportamento em um texto simples;
2. Escreva uma definição dos passos em Java ou em outras linguagens;
3. Execute e veja os passos falhar;
4. Escreva o código para fazer os passos passar;
5. Se necessário, refatorar o código ou o comportamento descrito.
Vantagens sobre o Selenium + Testlink
1 - O que está sendo testado está claro e em um único lugar.
2 - Facilidade na manutenção tanto do critério de aceitação quanto do
código de teste.
Obrigada.

Bdd com cucumber + java + selenium

  • 1.
    BDD com Cucumber+ Java + Selenium Sandy Maciel
  • 2.
    AGENDA ● BDD ● Cucumber+ Selenium + Java ● Exemplo
  • 3.
    O QUE ÉBDD? Behavior Driven Development
  • 4.
    3 Princípios doBDD 1 - O SUFICIENTE É SUFICIENTE. 2 - ENTREGAR VALOR PARA OS STAKEHOLDERS. 3 - TUDO É COMPORTAMENTO.
  • 5.
    Com isso, esseartefato pode ser utilizado como documentação, automatização de testes e auxílio aos desenvolvedores. Tanto os desenvolvedores quanto os analistas de testes, bem como o próprio cliente, podem escrever os casos de teste/critérios de aceitação, visto que eles serão escritos em linguagem natural.
  • 6.
    Critérios de Aceitação vs Casosde Teste Behavior Driven Development
  • 7.
  • 11.
    De acordo coma 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
  • 12.
    Critério de Aceitação ●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.*
  • 13.
    Vantagens do 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 tecnicamente é teste de unidade, integração ou sistema, mas com valor de teste de aceite; ● BDD é teste que evita defeito não que encontra defeitos;
  • 14.
  • 15.
    Com ele, asfuncionalidades do sistema são escritas em arquivos de texto e em uma linguagem de domínio específico chamada Gherkin, muito semelhante à linguagem natural, mas que contém algumas palavras chaves. CUCUMBER
  • 16.
  • 17.
    Os testes deBDD são compostos, basicamente, por arquivos que especificam as funcionalidades (“features”) e por arquivos de definição de passos (“steps”). Os arquivos com as funcionalidades são compostos por cenários, que exemplificam uma ou mais regras de negócio do sistema.
  • 18.
  • 19.
    Veja os passospara a utilização desse framework: 1. Descreva um comportamento em um texto simples; 2. Escreva uma definição dos passos em Java ou em outras linguagens; 3. Execute e veja os passos falhar; 4. Escreva o código para fazer os passos passar; 5. Se necessário, refatorar o código ou o comportamento descrito.
  • 25.
    Vantagens sobre oSelenium + Testlink 1 - O que está sendo testado está claro e em um único lugar. 2 - Facilidade na manutenção tanto do critério de aceitação quanto do código de teste.
  • 26.

Notas do Editor

  • #4 o BDD é um conjunto de práticas de engenharia de software projetado para ajudar as equipes a construir e entregar mais rápido software de alta qualidade. OU desenvolvimento orientado por comportamento . Tecnicamente o BDD é teste de unidade, comportamento ou sistema mas com valor de teste de aceite.
  • #5 1 - Não devemos automatizar tudo, mas sim tudo o que descreve o comportamento esperado do produto pelo cliente. Mais do que isso é desperdício de esforço 2 - Entregue somente o que tem valor para o cliente, nada mais. Se o que vc ta fazendo nao agrega valor, pare. 3 - Não importa o nível de teste, o tipo de funcionalidade, sempre será descrito como comportamento.
  • #7 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.
  • #8 Cada Story recebe um ou mais Acceptance Criterias (Critérios 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
  • #9 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 automatizar 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.
  • #10 Pensando nisso , vamos escrver nossos criterios de aceitação. Para esse primeiro exemplo, como pôde ser observado descrevemos a funcionalidade de uma forma bem superficial.
  • #14 Como não usar BDD: 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.
  • #15 O Cucumber foi originalmente criado por membros da comunidade Ruby para apoiar o desenvolvimento de testes de aceitação automatizado utilizando a técnica BDD. é uma ferramenta que suporta Behavior Driven Development (BDD), que consiste em descrever o comportamento de um usuário. Dessa forma, as necessidades reais do usuário são descritas JAVA: ling de programação SELENIUM: ferramenta para automação de testes
  • #22 Cria-se um arquivo do tipo feature Note que estamos utilizando uma linguagem padrão para especificação de testes de aceitação chamada “Grerkin”, do Cucumber. Outro ponto a destacar é que estamos utilizando a sintaxe desse framework em Português, indicado por “# language: pt”. A anotação @ContaTeste está anotada neste arquivo, pois o teste fará a chamada para execução deste mediante esta tag.