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

● 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; ...

● 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/)

● 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)

● 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

● 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

● 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

Referências
http://angular.github.io/protractor/#/style-guide
https://www.youtube.com/watch?
feature=player_embedded&v=-lTGnYwnEuM

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

Obrigado!
walmyr.filho.com
talkingabouttesting.com
@walmyrlimaesilv
wlsf82

Protractor style guide - Agile Testers Conference 2016

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (6)

Semelhante a Protractor style guide - Agile Testers Conference 2016

Semelhante a Protractor style guide - Agile Testers Conference 2016 (20)

Mais de Walmyr Lima e Silva Filho

Mais de Walmyr Lima e Silva Filho (13)

Protractor style guide - Agile Testers Conference 2016