Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Protractor style guide - Agile Testers Conference 2016

773 views

Published on

Apresentação para a conferência Agile Testers sobre o recentemente lançado guia de estilos do Protractor

Published in: Technology

Protractor style guide - Agile Testers Conference 2016

  1. 1. Vamos falar sobre o Protractor Style Guide? Walmyr Lima e Silva Filho
  2. 2. 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
  3. 3. ● 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)
  4. 4. ● Regras gerais ● Estrutura de projeto ● Estratégias de localizadores (locators) ● Page Objects ● Suites de teste Style guide
  5. 5. ● Regras gerais ● Estrutura de projeto ● Estratégias de localizadores (locators) ● Page Objects ● Suites de teste Style guide
  6. 6. ● 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
  7. 7. ● 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
  8. 8. /* Evite */ protractor.conf.dev.js protractor.conf.stg.js protractor.conf.local.js /* Recomenda-se */ protractor.conf.js -> gulp test-local; gulp test- dev; ...
  9. 9. ● Regras gerais ● Estrutura de projeto ● Estratégias de localizadores (locators) ● Page Objects ● Suites de teste Style guide
  10. 10. ● 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/)
  11. 11. ● Regras gerais ● Estrutura de projeto ● Estratégias de localizadores (locators) ● Page Objects ● Suites de teste Style guide
  12. 12. ● Porquê? ○ Markup sujeito a alterações ○ xpath tem problemas de desempemho (performance) ○ Não são legíveis NUNCA utilize xpath
  13. 13. ● 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
  14. 14. ● 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
  15. 15. 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)
  16. 16. Nunca utilize xpath
  17. 17. ● Regras gerais ● Estrutura de projeto ● Estratégias de localizadores (locators) ● Page Objects ● Suites de teste Style guide
  18. 18. ● 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
  19. 19. ● Porquê? ○ Mantém o código limpo e facilita encontrar o que se procura Declare um Page Object por arquivo
  20. 20. ● Porquê? ○ Um PageObject por aquivo significa que só há uma classe à exportar Utilize somente um module.exports ao final do arquivo Page Object
  21. 21. ● 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
  22. 22. ● 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
  23. 23. ● 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
  24. 24. ● 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
  25. 25. ● 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
  26. 26. ● Regras gerais ● Estrutura de projeto ● Estratégias de localizadores (locators) ● Page Objects ● Suites de teste Style guide
  27. 27. ● 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
  28. 28. ● Porquê? ○ É bem documentado ○ É também suportado pelo time do Protractor ○ beforeAll e afterAll Utilize Jasmine2
  29. 29. ● 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
  30. 30. ● 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
  31. 31. 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
  32. 32. NUNCA use xpath
  33. 33. ● 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
  34. 34. ● 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
  35. 35. Referências http://angular.github.io/protractor/#/style-guide https://www.youtube.com/watch? feature=player_embedded&v=-lTGnYwnEuM
  36. 36. Alguns exemplos https://github.com/wlsf82/protractor-style-guide
  37. 37. Obrigado! walmyr.filho.com talkingabouttesting.com @walmyrlimaesilv wlsf82

×