I understand it's best practice to make tests inde...
# best-practices
c
I understand it's best practice to make tests independent. However, to make tests independent either requires that our tests are extremely long and combine many tests in one or we end up doing a lot of repeated navigation to be able to split tests up and keep them independent. This seems like kind of an art, but how do you balance making tests independent with repeating code?
p
Page Objects with reusable helper functions. Or the Cypress way would be to write custom Cypress commands. What I haven't seen are examples of how you manage 800 custom Cypress commands, which is why I keep going back to Page Objects as it's nice and tidy.
b
IS the repeating code mainly navigation based?
c
Yes, that's the main concern. Waiting unnecessarily to navigate back to the same page repeatedly just for the sake of making a test independent
b
If it isn't a page part of a process flow of some sort, using the url of that page to cut down on time.
g
I am so glad to finally hear someone with similar thoughts. Every cypress resource on internet suggests against using POM.
p
I've yet to see someone present a better way than page objects. Locators can be stored in a dict and easy imported so you don't have to keep re-typing locator strings. But it assumes all of your locators are cleverly constructed into a single string that can be leveraged in a single
cy.get()
command and you don't opt to chain commands like
parent()
etc. Plus, storing your locators in a dict is 1/2 of the way towards a page object, right? So, I'm back to a page object which stores the locators, exposes them to the tests, and can also leverage them in custom per-page helper methods. I certainly don't claim to be an expert. But a single line my test looks like this
exercise.typeExerciseCode("1+1");
vs whatever the many lines of raw Cypress commands would look like, and I've used that method 27 times in my test suite thus far.
3 Views