Command abstraction / strategy pattern for commands Cypress Community #i-need-help

Command abstraction / strategy pattern for command...

colossal-umbrella-95675

01/26/2023, 11:25 AM

Hi, I have a question regarding a test strategy/setup. I made a commands to handle basic tasks on my website. E.g. selecting the correct menu item like cy.menuItemOpen(1) where 1 is the first menu item. No comes the challenge, i am building tests for more theme's that are functional the same, but do have a complete different layout and selectors. I want to keep my tests clean form IF / ELSE statements because then i need a tests to test my test .... I want to make a command for every theme when needed (if the command is theme dependant). I was thinging like

cy.prittyTheme().menuItemOpen(1)

cy.pritty.menuItemOpen(1)

. where menuItemOpen() is a new command for every theme. Is this possible? And so how or does anyone have a reference to documentation how i could make this? Thanks in advance! If not how do you deal with multiple theme's?

colossal-umbrella-95675

01/26/2023, 1:59 PM

or some way to organise commands ?

modern-dawn-86006

01/26/2023, 8:43 PM

I am not sure about organizing commands but you can organize your code for sure using the page object model.

colossal-umbrella-95675

01/27/2023, 6:17 AM

I red a bit about the page object model yesterday, and this is something i probably want. But it is also discouraged ?

colossal-umbrella-95675

01/27/2023, 6:17 AM

https://www.cypress.io/blog/2019/01/03/stop-using-page-objects-and-start-using-app-actions/

colossal-umbrella-95675

01/27/2023, 6:20 AM

I think P.O.M. is what i need indeed. But then i do not have the

cy.

prefix and my functions are not commands anymore. So i get page.themeName.Action() but action is not really a command. I am figuring out if this has a downside (like chaining functions or having the promisse returned)

gray-kilobyte-89541

01/27/2023, 1:12 PM

the blog post strikes again

modern-dawn-86006

01/29/2023, 7:01 AM

This is a very controversial blog by Mr gleb. Using app actions or page object models is a personal choice. The only downside of page object model is it takes a bit of time. So, let's say if you spec file is taking 60 seconds to execute, it would take around 70-75 seconds with page object model (just a rough guess) but at the sametime, it will make your code more readable that even anyone can understand. Page object model is not a part of cypress but is a part of javascript, so mostly people are using it.

modern-dawn-86006

01/29/2023, 7:05 AM

I am just a noob but I have an opinion on page actions and it is that when you are doing e2e testing, you wait for the dependent things on the frontend to load so, i guess with page actions, something is most likely to get skipped. (Just a wild guess, I can be wrong).

modern-dawn-86006

01/29/2023, 7:06 AM

I would keep using P.O.M so, everyone in my organization can understand my code even the project manager with a bit of a coding background can understand it.

gray-kilobyte-89541

01/29/2023, 2:24 PM

Sure

colossal-umbrella-95675

01/30/2023, 6:06 AM

Sounds good! I've decided to make a proof of concept for our department. The structure would probably be way better than having all command defined in the index.d.ts and the implementation in separate files grouped per category.

colossal-umbrella-95675

01/31/2023, 10:20 AM

POC works very nice. I've create a state class that keeps the 'context' (this is the theme) using a strategy pattern. In each test i get the POM, tell him what theme (state) it is in and then i call the function. This way there is no conditional coding and all implementations per theme are separate/in their own class. for this i enabled typescript so i could do a bit more strict programming (abstract classes, interfaces and defining variable types)

modern-dawn-86006

02/01/2023, 5:45 AM

I am glad this worked out for you

6 Views

Previous Next