Por que QAs usam Page Objects com Cypress?
Vložit
- čas přidán 22. 08. 2024
- Nesta live, vou te apresentar o motivo pelo qual QAs trazem o padrão Page Objects para o mundo de testes automatizados com Cypress, quando existem melhores alternativas (na minha opinião).
Acesse o repositório demonstrado durante a live (meu fork): github.com/wls....
E conheça a página Page Objects Anônimos: page-objects-a....
___
Conheça os cursos de automação de testes web da Escola TAT no Udemy udemy.com/user...
- Cypress básico www.udemy.com/...
- Cypress intermediário www.udemy.com/...
- Cypress avançado www.udemy.com/...
- Testes de regressão visual com Cypress e Percy (básico) www.udemy.com/...
- Boas práticas em automação de testes com Cypress www.udemy.com/...
- Testes end-to-end com Cypress www.udemy.com/...
Aproveite também para seguir o blog TalkingAboutTe....
Assine a newsletter da TAT e receba conteúdos exclusivos todo mês na sua caixa de entrada mailchi.mp/6b1....
Conheça o grupo da TAT no LinkedIn / 12492726
E me siga no Twitter / @walmyrlimaesilv e LinkedIn / walmyr-lima-e-silva-fi... . Sempre compartilho conteúdos legais por lá, além de promoções!
Eu ainda acho o mapeamento de elementos centralizado necessário. Imagine trocar todas as strings de identificação pelos arquivos. essa foi a má experiência que tive com a falta de um mapeamento.
Obg por compartilhar!
Eduardo, o ponto é que usando tudo que o Cypress oferece e tendo testabilidade para a criação do estado da aplicação sem passar pela GUI para tudo, isso deixa de ser um problema, e onde necessário, pode-se dar alias para os elementos, eliminando duplicações. Além disso, você pode fazer uso dos comandos customizados para fins de não duplicar código, sem a necessidade de Page Objects.
@@TalkingAboutTesting sim, mas também comandos e tasks devem ser usados com cuidados para não virar um novo framework.
O mal de alias é que tens que ter um ponto inicial. E se fores compartilhar entre arquivos de teste fica complicado. Quem deve criar o alias? E... Quais?
Toda vez que vejo o blog do cypress a defender não usar POM e vejo string para todo lado ao invés de centralizar num mapeamento tenho pena de quem manteria daquele jeito.
@@edudelta se precisa compartilhar elementos em diferentes testes o problema é ainda maior, pois seus testes são dependentes da UI.
@@TalkingAboutTesting mas os testes de cypress são dependendes da ui. se tenho testes a olhar uma tabela e em dois ou três testes olho essa tabela, a referência a essa tabela vai ficar espalhada por diferentes locais com algo como cy.get('table') que se tiveres centralizado em outro lugar podes usar cy.get(locator.tabelaEx) que para manutenção de código é muito mais simples. se a tabela mudar de referência, a atuaização é em um arquivo em uma linha para atualizar a referência ao invés de múltiplos lugares por string.
@@edudelta como mostro na live, um alias resolve também. Mas não sou contra usar em uma variável também. Só acho que o Page Objects complica demais, na minha opinião.
Pô Walmyr, fui procurar um conteúdo de teste e dei de cara com teu vídeo cara hahaha. Trabalhamos no suporte daquela fábrica de pcs há anos atrás meu, Olicheski aqui! Integramos a facção com Thiago, Lacraia, Oliveira, Salsicha, Borba, Fritz, Mafaldo e o Queixada, bons tempos :). Atualmente sou QA no banco do nosso estado. Abração Bro!!!
Caraca mano, bons tempos mesmo. Feliz com o contato por aqui. Tu ainda tens contato com alguém daquela galera? Podíamos fazer um call pra reunir aquela galera, hein?
@@TalkingAboutTesting Bah meu, eu não tenha praticamente mais ninguém, única rede social que tenho é o LinkedIn. Falei com o Borba ano passado, ele mora em SP, mas a gente pode tentar achar a galera sim.
Parabéns pelo conteúdo! Muito esclarecedor ver sua perspectiva sobre Page Objects. Estou iniciando agora em Cypress, fazendo a v2 do curso básico e vindo de um background de Selenium+PO, você havia comentado brevemente sobre o assunto de commands em uma das aulas, resolvi pesquisar mais sobre o assunto! :)
ico feliz que gostou da live Daniela. Espero que esteja gostando também da v2 do curso básico de Cypress.
Eu tava acostumado com outros frameworks a usar page-objects. Já com o Cypress com o tempo também fui usando sem pra diminuir a complexidade. Mas ainda sim tem casos que é interessante, como grandes rotinas que são usadas em outros testes.
Você não acha que comandos customizados atendem a necessidade sem Page Objects?
@@TalkingAboutTesting Se bem documentados atendem. Tipo, eu passei a usar o page objects, pois tive dificuldades pra escrever aquele types.d pra fazer o autocomplete do comando customizado. (posso tá viajando na maionese, mas na época que trabalhei assim, tive essas dificuldades).
@@richardrosario entendi. No curso de testes end-to-end ensino isso. Depois que aprende só vai. Aí não tem mais desculpa hahaha.
Segue um cupom de desconto caso tenha interesse www.udemy.com/course/testes-end-to-end-com-cypress/?couponCode=1C660B18CDDA3BD40CE7
@@TalkingAboutTesting Boa dica. Valeu Walmyr.
Entendo seu ponto de vista, concordo sobre a questao de se analisar a verdadeira necessidade de uso do PO, porém volto no ponto, existem projetos que requerem uma maior interacao com a interface, inclusive sendo projetos que recorrentemente apresentam bugs no front (obvio que sabemos que ai entra toda uma questao que envolve arquitetura de projeto, e o time etc..), porém nem sempre o mundo "ideal" é alcancado dentro de um contexto de projeto. Eu mesmo trabalho em projeto que envolvem construcao de fluxos BPMN's , de extrema complexidade, onde validamos fluxos atraves de API, porem tbm existe uma necessidade grande de validacao de fluxo do lado da criacao/interacao com os elementos de pagina, infelizmente (e2e), por mim, eu trabalharia apenas criando testes a nivel de BE rs, mas infelizmente nao é possível. No meu contexto, vejo um grande valor o uso do PO, pois conseguimos atingir um padrao e clareza no código muito positiva. Mas como dito, cada projeto requer uma análise única. Parabéns pelo conteúdo.
Ótimos pontos Juliana. De qualquer forma, softwares devem evoluir. Nada deveria impedir de usar PO por um tempo, ir desacoplando diferentes componentes do FE, testando-os de forma isolada, e não necessitando mais dos POs quando fizermos testes e2e, pois estes serão mínimos, visto a garantia dos outros testes (previamente mencionados) e do desacoplamento das diferentes partes da aplicação. Obrigado pela contribuição.
Excelente Walmyr. Você é top
Muito obrigado!
Incrível Walmyr, li o mesmo post que você comentou sobre o Cypress não usar PageObjects, seria interessante um collab com você e o Pessoni, um tempo atrás ele defendeu o Selenium no Instagram, seria muito interessante a visão dos 2 xD
O Pessoni e eu estamos fazendo uma parceria este ano. Vou trocar uma ideia com ele.
Acabei de finalizar de assistir e a diferença é gritante em deixar um pouco de lado o uso do POM. Parabens pelo material Walmyr.
Fico feliz que gostou Rodrigo! Aproveito pra te apresentar a página dos Page Objects Anônimos page-objects-anonimos.vercel.app/
Eu particularmente vejo o uso de App Actions como um complemento ao Page Objects, não acho que sejam mutuamente excludentes. Eu posso usar actions para configurar o estado inicial dos meus testes sem passar pela UI e ao mesmo tempo ter os benefícios da centralização e modularização que o POM fornece.
Não lembro de ter falado de App Actions neste vídeo e sim de custom commands, os quais atingem os mesmos resultados dos Page Objects, porém com menos código. Sou a favor da simplicidade. Recomendo assistir este vídeo também é depois me diga o que acha Associação dos Page Objects Anônimos - Perca esse vício
czcams.com/video/YyU8wHm5cv4/video.html
hehehe cheguei nesse vídeo através do outro, e esse projeto foi onde aprendi o padrão de PO, por isso perguntei sobre, tinha sido minha primeira atuação com o cypress, alias até com o robot eu to fazendo esse padrão, acredito que irei abdicar dele
Depois assista também este czcams.com/video/YyU8wHm5cv4/video.html
@@TalkingAboutTesting maratonando...Walmyr parabens pela iniciativa, fera demais
@@Vini7Santos fico feliz que gostou. Obrigado!
Parabéns pelo conteúdo!
O motivo que o projeto com page objects ter executado mais "rápido", deve ser pelo fato dele estar usando o dashboard do Cypress, e lá os testes são executados paralelamente.
Eu trabalho com Cypress a quase 2 anos, e logo no inicio fiz com page objects, justamente pelo "vicio" do selenium, e para mim o page objects no meu projeto mais atrapalha do que ajuda.
Nao necessariamente precisa do Dashboard pra usar paralelização, basta saber procurar no Google 😆
No entanto, usar Page Objects ou não, não tem nada a ver com isso, certo?
Feliz em saber que compartilhamos da mesma opinião!
Não me sinto sozinho 😆
Fica o convite pra conhecer o site page-objects-anonimos.vercel.app/
@@TalkingAboutTesting Claro, não precisa mesmo do Dashboard pra usar paralelização e também page objects não tem nada haver com isso, só fiz esse comentário aleatório pq fiquei pensando o motivo que ter executado mais rápido. :D
@@patrickreis4663 muito obrigado por compartilhar suas experiências!
Principais Vantagens do Page Objects:
- É mais fácil e rápido entender o que teste faz, pois as funções se tornam um roteiro.
- O reaproveitamento de código é absurdo, se você precisa fazer a mesma coisa, basta importar o arquivo e chamar a função.
- Manutenção no código se torna fácil, você altera apenas em um lugar e todos lugares que chamam a função já estão atualizados.
- Você quebra seu código em pequenas partes, diminuindo a complexidade para entender o que ele faz.
Oi Alif,
No Cypress, podemos facilmente criar comandos customizados e reutilizá-los sem a necessidade do padrão Page Objects.
Algumas vantagens dessa abordagem (na minha opinião) são:
- Um comando customizado exige menos código que um Page Object
- Quando utilizando comandos customizados, tais comandos ficam disponíveis através do objeto global cy, ou seja, não há a necessidade de importar nada, como é necessário quando se usa o padrão Page Objects
- Ao não usar o padrão Page Objects, nos damos a liberdade para criar não só comandos customizados que interagem com a aplicação através da interface gráfica de usuário, como também as famosas App Actions, as quais podem criar estado na aplicação em teste para otimizar os testes, com diferentes mecanismos, tais como chamdas à APIs, execução de comandos à nível de sistema operacional, tarefas (tasks) para população e limpeza do banco de dados, etc.
Já tentei usar os comandos customizaveis ao invés de PO, e a conclusao que cheguei é que no projeto em que atuo, a junção dos dois, acaba me trazendo o cenário perfeito, infelizmente nao consigo ver que apenas com uso dos comandos customizados, se tem um ganho bacana na legibilidade e organizacao do código.
Fala mestre, achei muito interessante essa live e fiquei curioso sobre o pipeline do git, vc tem algum vídeo sobre isso?? Como configurar ou como usar ??
Tenho uma playlist inteira sobre integração contínua. Aí vai czcams.com/play/PL-eblSNRj0QHgzdWNkGks9_JdhV9iAwFr.html
@@TalkingAboutTesting valeu mestre!! Excelente conteúdo!!! Estou aprendendo muito!!
Fico feliz! A propósito, git e GitHub são coisas diferentes.
que dahora que cair nesse video
Fico feliz que gostou Vinicius!