Transferir como PDF, PPTX
Carregado porWalmyr Lima e Silva Filho
Protractor style guide - Agile Testers Conference 2016
O documento discute as vantagens de utilizar um style guide para testes end-to-end no Protractor, incluindo padronização, facilidade de depuração e manutenção. Ele fornece recomendações sobre estrutura de projeto, localizadores, page objects e independência de testes.
![[MTC 2021] Tests smells: aquele cheirinho de que algo não está bom no seu cód...](https://cdn.slidesharecdn.com/ss_thumbnails/testssmellsaquelecheirinhodequealgonoestbomnoseucdigodeteste-rafaelpeixotosilva-210804112832-thumbnail.jpg?width=640&height=640&fit=bounds)
Protractor style guide - Agile Testers Conference 2016
- 1. Vamos falar sobreo Protractor Style Guide? Walmyr Lima e Silva Filho
- 2. Porque utilizar umstyle 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. ● Pirâmide dostestes: 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. ● Regras gerais ●Estrutura de projeto ● Estratégias de localizadores (locators) ● Page Objects ● Suites de teste Style guide
- 5. ● Regras gerais ●Estrutura de projeto ● Estratégias de localizadores (locators) ● Page Objects ● Suites de teste Style guide
- 6. ● Porquê? ○ Poisos 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. ● Porquê? ○ Suasferramentas de build podem sobrescrever as configurações para você (grunt, gulp) ○ Evite configurações duplicadas Utilize somente um arquivo de configuração
- 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. ● Regras gerais ●Estrutura de projeto ● Estratégias de localizadores (locators) ● Page Objects ● Suites de teste Style guide
- 10. ● Porquê? ○ Fácilde 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/)
- 12. ● Regras gerais ●Estrutura de projeto ● Estratégias de localizadores (locators) ● Page Objects ● Suites de teste Style guide
- 13. ● Porquê? ○ Markupsujeito a alterações ○ xpath tem problemas de desempemho (performance) ○ Não são legíveis NUNCA utilize xpath
- 15. ● Porquê? ○ Acesseelementos 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
- 17. ● Porquê? ○ Acesseelementos 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
- 19. Evite localizadores portextos 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)
- 20.
- 21. ● Regras gerais ●Estrutura de projeto ● Estratégias de localizadores (locators) ● Page Objects ● Suites de teste Style guide
- 22. ● Porquê? ○ Encapsulamentode 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
- 24. ● Porquê? ○ Mantémo código limpo e facilita encontrar o que se procura Declare um Page Object por arquivo
- 26. ● Porquê? ○ UmPageObject por aquivo significa que só há uma classe à exportar Utilize somente um module.exports ao final do arquivo Page Object
- 28. ● Porquê? ○ Asdependê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
- 30. ● Porquê? ○ Ousuá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
- 32. ● Porquê? ○ Amaioria (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
- 34. ● Porquê? ○ Aresponsabilidade 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
- 35. ● 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
- 37. ● Regras gerais ●Estrutura de projeto ● Estratégias de localizadores (locators) ● Page Objects ● Suites de teste Style guide
- 38. ● Porquê? ○ Utilizara 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
- 39. ● Porquê? ○ Ébem documentado ○ É também suportado pelo time do Protractor ○ beforeAll e afterAll Utilize Jasmine2
- 41. ● Porquê? ○ Executetestes 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
- 43. ● Porquê? ○ Execuçãoisolada de testes ○ Você pode depurar seus testes facilmente (ex.: fdescribe, xdescribe, fit, xit) Faça seus testes independentes uns dos outros
- 44. Exceto quando asoperaçõ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
- 45.
- 46. ● Porquê? ○ Garantiade que a página em teste está em um estado limpo Navegue até a página em teste antes de cada teste
- 48. ● Porquê? ○ Garantiade 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
- 50.
- 51.
- 52.