I found their idea about defining commands very odd, but when we ignored these entirely and just went with the good old page pattern, the tests became very tame again. All the cypress-internals are done in small methods within page-objects, the tests contain only the abstract page-object-methods.
But yes, when we tried to run with the patterns they advertise, the tests became indeed hard to write and read; maybe we did it all wrong but it's at least consistent with the experience expressed by you and others in the thread here.
The one slight gotcha is if you go for the page object pattern the intuition is that each page object holds a reference to the cypress element that formed it so you can do new LoginForm(cy.get('#loginForm')) or similar which is a mistake because of the way cypress chaining works - it will result in only being able to use a single method once on the page object. Instead you need to query fresh again each time.
Which is fine when the page object is a login form, but a bit more comfortable complicated when it's notification 5 or something.
Good point, I'd gotten used to that and forgotten how it is kind of counterintuitive at first. Our base test helper object does this:
get root() {
// It is important here to run cy.get()
// each time this property is accessed.
// Lots of methods of this class chain
// off of `this.root` so it needs to be
// re-evaluated every time.
return cy.get(rootComponentCss);
}
find(selector: string, options?: any) {
return this.root.find(selector, options);
}
...so that component-specific test helper objects (subclasses) can just do something like:
get sendMissileAlertButton() {
this.root.find('.x-hawaii-missile-incoming');
}
That way, it looks up the target element every time it is used in a test.
But yes, when we tried to run with the patterns they advertise, the tests became indeed hard to write and read; maybe we did it all wrong but it's at least consistent with the experience expressed by you and others in the thread here.