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.

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!

22. https://walmyrfilho.com
Muito obrigado!
MTC em 2021