[MTC 2021] Criando testes automatizados rápidos e robustos com cypress - Walmyr Lima e Silva Filho
0 gostou206 visualizações
O documento discute boas práticas para criar testes automatizados rápidos e robustos com Cypress, como fazer autenticação de forma programática, criar mecanismos para controle de estado e usar atributos data-* para aumentar a testabilidade. Também aborda erros comuns como testes lentos ou instáveis.
![Não use cy.wait(5000)
cy.wait('@myReq')
O Cypress já possui esperas automáticas com
diferentes timeout defaults para esperar por
elementos estarem visíveis, por animações
acabarem, por requisições serem enviadas e
respondidas e por páginas serem carregadas.
O que você pode fazer, para tornar seus testes
ainda mais robustos, é aguardor por elementos
estarem visíveis:
Ex.: cy.get('[data-cy="avatar"]').should('be.visible')
Ou então, você pode esperar por uma deteminada
requisição a qual você deu um alias.
Ex2.: cy.intercept(...).as('myReq')
...](https://image.slidesharecdn.com/criandotestesautomatizadosrpidoserobustoscomcypress-walmyrlimaesilvafilho-210804112816/85/MTC-2021-Criando-testes-automatizados-rapidos-e-robustos-com-cypress-Walmyr-Lima-e-Silva-Filho-16-320.jpg)
[MTC 2021] Criando testes automatizados rápidos e robustos com cypress - Walmyr Lima e Silva Filho
- 1. https://walmyrfilho.com Criando testes automatizados rápidos e robustos com Cypress MTC em 2021
- 2. Sobre mim Meu nome é Walmyr Filho, sou um engenheiro de software especializado em automação de testes e integração contínua, embaixador do Cypress.io, autor do blog TAT e do canal TAT, instrutor de cursos de automação de testes web no Udemy, mentor e um cara apaixonado por skateboarding, comida vegana, música, tatuagens e minha família.
- 3. O problema dos testes lentos Testes instáveis (flaky) Boas práticas p/ testes rápidos e confiáveis ✅ Mão-na-massa Perguntas e respostas ❓ Surpresa! Agenda Pontos de discussão
- 4. Testes leeentos E os problemas que eles trazem junto consigo ATRASAM O TIME Gosto de um pipeline de integração contínua de não mais que 10 minutos. Mais que isso e problemas começam a voltar quando são mais caros de corrigir. ATRASAM ENTREGAS É arriscado entregar um software sem a garantia de que todos os testes de regressão estão passando. Mas e quando são muito lentos uai? SÃO "LARGADOS DE ΜÃO" É isso mesmo, testes que atrasam o time não são uma alternativa para times em busca de agilidade.
- 5. Testes instáveis (os famosos flakey tests) EXECUÇÃO 1 Ô trem bão! Passou! EXECUÇÃO2 E nenhum código mudou desde a última execução. Falhou ) : EXECUÇÃO4 Uai, aquela falha devia ser alguma instabilidade no ambiente. Passou! EXECUÇÃO 5 Vixe, esse trem é flaky! Falhou :( EXECUÇÃO3 E nenhum código mudou desde a última execução de novo. Passou!
- 6. Faça autenticação de forma programática Boas práticas Testes devem ser independentes uns dos outros Crie mecanismos para o controle do estado da app Selecione elementos com atributos data-* (testabilidade) Não tente armazenar comandos do Cypress em variáveis Testes não devem ser muito pequenos nem muito grandes Não teste aplicações que você não controla Não use os hooks after e afterEach Não use cy.wait(Number) Inicialize o servidor antes de iniciar os testes
- 7. Boas práticas - continuação Configure uma URL base (baseUrl) Já que sobrou espaçao, fica o convite para conhecerem as "pitadas de Cypress" no blog Talking About Testing https://talkingabouttesting.com/category/cypress/
- 8. Testes independentes Dica: utilize o hook beforeEach quando precisar executar passos repetidos para todos os testes de um determinado describe ou context. Testes automatizados devem ser capazes de serem executados de forma isolada, sem a necesidade de que outro teste tenha executado para criar algum estado na aplicação em teste. A falha em um teste não deve impactar no resultados de outros testes
- 9. Autenticação programática Ao adiconar mecanismos para realizar login de forma programática, os testes ficam mais rápidos e independentes. Realizar login via interface gráfica de usuário como pré-condição de todos testes é custoso (em termos de tempo de execução), além de tornar os testes dependentes, o que por si só já é uma má prática.
- 10. Mecanismos para criação de estado Alguns exemplos desses mecanismos são: chamadas de API para criação de recursos; comunicação direto com o banco de dados; execução de scripts à nível de sistema; ou, execucão de tarefas diversas. Ao criar tais mecanismos, garantimos testes completamente desacoplados uns dos outros, não precisamos de abstrações que adicionam complexidade aos testes, tais como Page Objects, por exemplo, e garantimos testes rápidos e direto-ao-ponto.
- 11. Atributos data-* Adicionando atributos aos elementos do frontend, tais como: data-test, data-testid, ou data-cy, adicionmos o que chamo de "testabilidade" na aplicação, visto que tais atributos são especificamente criados para fins de testes, diminuindo a chance de mudanças no frontend quebraem os testes.
- 12. Não faça isso: var el = cy.get('seletor') cy.get('@myBtn).click() Lembre-se. Cypress não é Selenium! O Cypress possui uma arquitura própria, onde apesar de em muitos casos permitir a escrita de código que parece síncrono, mesmo que seja assíncrono (visto que coloca cada comando em uma fila para posterior execução), não é possível fazer algo como: const myBtn = cy.contains('button', 'My button') myBtn.click() Porém, você pode fazer: cy.contains('button', 'My button').as('myBtn)
- 13. Não teste aplicações externas Para garantir que tais serviços estão de acordo com sua aplicação, você pode ter uma suite de smoke-test, por exemplo, ou testes de contrato. Depender do login do Google via GUI para seus testes, ou de alguma API de terceiros pode tornar seus testes instáveis, visto que mudanças nestes serviços (os quais você não controla) irão quebrar seus testes, mesmo que esteja tudo certo do lado da aplicação sendo desenvolida.
- 14. Testes pequenos ou muito grandes Porém, cuidado com testes muuuito grandes. Quem sabe estes estão testando muitas coisas não relacionadas e poderiam ser quebrados em testes menores. Testes end-to-end não são testes de unidade. Devido ao seu custo de execução, vale a pena adicionar mais de uma verificação por teste, para otimizar seu tempo.
- 15. Não use os hooks after e afterEach Como boa prática, faça qualquer limpeza antes da execução dos testes, tais como no hook beforeEach. Caso algo dê errado durante a execução dos testes, tais hooks correm o risco de não serem executados, deixando "lixo" na aplicação.
- 16. Não use cy.wait(5000) cy.wait('@myReq') O Cypress já possui esperas automáticas com diferentes timeout defaults para esperar por elementos estarem visíveis, por animações acabarem, por requisições serem enviadas e respondidas e por páginas serem carregadas. O que você pode fazer, para tornar seus testes ainda mais robustos, é aguardor por elementos estarem visíveis: Ex.: cy.get('[data-cy="avatar"]').should('be.visible') Ou então, você pode esperar por uma deteminada requisição a qual você deu um alias. Ex2.: cy.intercept(...).as('myReq') ...
- 17. start-server-and-test Utilize mecanismos, tais como o uso da biblioteca star-server-and-test, para inicializar o servidor da aplicação antes da execução dos testes, garantindo que a mesma será executada com o código correto e que os testes serão executados somente quando a aplicação estiver respondendo. Além disso, tal abordagem ajudará na execução dos testes em um servidor de integração contínua.
- 18. Defina a baseUrl Além disso, tal URL pode ser sobrescrita por meio de um arquivo cypress.env.json, variáveis de ambiente (CYPRESS_ ou cypress_), linha de comando, etc., possibilitando a execução dos mesmos testes contra diferentes ambientes. Ao definir a baseUrl no arquivo de configuração (cypress.json), seus testes podem visitar as páginas via URLs relativas.
- 19. Seguindo essas boas práticas, você terá testes rápidos e robustos, nos quais seu time confia e ajuda a manter.
- 20. "Mão-na-massa" Cypress RWA MTC em 2021
- 21. Alguma pergunta? Ficarei feliz em responder!