Protractor style guide - Agile Testers Conference 2016

Post on 15-Apr-2017

493 views 0 download

Transcript of Protractor style guide - Agile Testers Conference 2016

Vamos falar sobre o Protractor Style Guide?

Walmyr Lima e Silva Filho

Porque utilizar um style guide?

● Boas práticas

● Padronização

● Tornar rápido e fácil escrever testes e2e

● Facilidade na depuração de erros

● Facilidade na manutenção dos testes por

qualquer membro do time

● Pirâmide dos testes: teste e2e o principal

● Vantagens:

○ Demonstram que o todo funciona conforme o

esperado

○ Previne incidentes em produção

○ Teste manual toma muito tempo X CD

(continuous delivery)

Testes end-to-end (e2e)

● Regras gerais

● Estrutura de projeto

● Estratégias de localizadores (locators)

● Page Objects

● Suites de teste

Style guide

● Regras gerais

● Estrutura de projeto

● Estratégias de localizadores (locators)

● Page Objects

● Suites de teste

Style guide

● Porquê?

○ Pois os testes de unidade executam muito

mais rápidos que os testes e2e

○ Evitar duplicidade de testes

Não crie testes e2e para funcinalidades já cobertas por testes de unidade

● Porquê?

○ Suas ferramentas de build podem

sobrescrever as configurações para você

(grunt, gulp)

○ Evite configurações duplicadas

Utilize somente um arquivo de configuração

/* Evite */

protractor.conf.dev.js

protractor.conf.stg.js

protractor.conf.local.js

/* Recomenda-se */

protractor.conf.js -> gulp test-local; gulp test-dev; ...

● Regras gerais

● Estrutura de projeto

● Estratégias de localizadores (locators)

● Page Objects

● Suites de teste

Style guide

● Porquê?

○ Fácil de localizar

○ Separa testes e2e de testes de unidade

○ Estrutura de diretórios mais limpa

Agrupe seus testes e2e em uma estrutura que faça sentido para seu projeto (ex.: my-project/tests/e2e/)

● Regras gerais

● Estrutura de projeto

● Estratégias de localizadores (locators)

● Page Objects

● Suites de teste

Style guide

● Porquê?

○ Markup sujeito a alterações

○ xpath tem problemas de desempemho

(performance)

○ Não são legíveis

NUNCA utilize xpath

● Porquê?

○ Acesse elementos facilmente

○ O código é mais difícil de mudar que o

markup

○ São localizadores mais legíveis (ex.:

by.model, by.binding)

Dê preferência à localizadores específicos do Protractor quando possível

● Porquê?

○ Acesse elementos facilmente

○ Você utiliza markup que é menos sujeito

a alterações

○ Legibilidade de localizadores

Dê preferência à by.id e by.css quando não houver um localizador específico do protractor disponível

Evite localizadores por textos que mudam com frequência● Porquê?

○ Textos de botões, links e rótulos tendem

a mudar ao longo do tempo

○ Seus testes não podem quebrar por

simples alterações de textos

○ Sistemas multilanguage (tradução)

Nunca utilize xpath

● Regras gerais

● Estrutura de projeto

● Estratégias de localizadores (locators)

● Page Objects

● Suites de teste

Style guide

● Porquê?

○ Encapsulamento de informações sobre

elementos da página em teste

○ Reutilização de código

○ Desacopla a lógica dos testes dos

detalhes da implementação

Utilize Page Objects para interagir com a página em teste

● Porquê?

○ Mantém o código limpo e facilita

encontrar o que se procura

Declare um Page Object por arquivo

● Porquê?

○ Um PageObject por aquivo significa que

só há uma classe à exportar

Utilize somente um module.exports ao final do arquivo Page Object

● Porquê?

○ As dependências de módulos devem ser claras

e fáceis de encontrar

○ Separação de dependências e código de teste

○ Torna as dependências disponíveis para toda

a suite de teste

Requeira e instancie todos os node modules no topo

● Porquê?

○ O usuário de um Page Object deve ter

acesso rápido aos elementos disponíveis

na página

Declare todos elementos do construtor como públicos

● Porquê?

○ A maioria (ou todos) dos elementos do

Page Object estão expostos e podem ser

utilizados diretamente no teste

○ Fazer de outra forma adiciona

complexidade desnecessária

Declare funções para operações que necessitam de mais de um passo

● Porquê?

○ A responsabilidade pelos assertions é do

teste

○ As pessoas que vão ler o código de teste

devem ser capazes de compreender o

comportamento esperado da aplicação lendo

somente o teste

Não faça assertions nos Page Objects

● Porquê?

○ Você pode utilizá-los em múltiplos

testes

○ Evita duplicidade de código

○ Quando uma diretiva muda, você só

precisa mudar o wrapper, uma vez

Adicione wrappers para diretivas, diálogos e elementos comuns

● Regras gerais

● Estrutura de projeto

● Estratégias de localizadores (locators)

● Page Objects

● Suites de teste

Style guide

● Porquê?

○ Utilizar a aplicação real com todos suas

dependências lhe provê alta confiança

○ Use mock quando você realmente não pode

fazer chamadas à aplicação real

Não utilize mock a não ser que seja totalmente necessário

● Porquê?

○ É bem documentado

○ É também suportado pelo time do Protractor

○ beforeAll e afterAll

Utilize Jasmine2

● Porquê?

○ Execute testes em paralelo com sharding

○ A ordem de execução não é garantida

○ Execução isolada de suites de teste

Faça seus testes independentes ao menos no nível de arquivo

● Porquê?

○ Execução isolada de testes

○ Você pode depurar seus testes facilmente

(ex.: fdescribe, xdescribe, fit, xit)

Faça seus testes independentes uns dos outros

Exceto quando as operações realizadas para

iniciar o estado inicial do testes é muito

custosa

● Porquê?

○ Os testes ficarão executando para sempre

Faça seus testes independentes uns dos outros

NUNCA use xpath

● Porquê?

○ Garantia de que a página em teste está em um

estado limpo

Navegue até a página em teste antes de cada teste

● Porquê?

○ Garantia de que as principais partes da

aplicação estão corretamente conectadas

○ Usuários não navegam digitando URLs

○ Provê confiança sobre questões

relacionadas a permissões

Tenha uma suite de testes que navega através das principais rotas de sua aplicação

Alguns exemplos

https://github.com/wlsf82/protractor-style-guide