Ditto. It is really easy to write re-usable code for Cypress tests in plain TypeScript/JavaScript, and just directly import the file.

    x.usernameField.type('Joe User');
    x.passwordField.type('$ecureBR0');
    x.enterWrongCaptcha();
    cy.get('.err-captcha-fail').should('be.visible');

Basically, I think all the code to locate UI elements and perform common interactions with them should be in re-usable utility code, so that the actual tests can focus on just testing what they test.

I don't think the Cypress docs probably do a great job emphasizing how easy this is (especially since they go out of their way to de-emphasize the 'page objects' pattern, but without offering much in the way of a replacement).

Yes, I'll echo my disagreement with the Cypress advice against the page object pattern - the advantage was always that the logic to get the element could be updated in a single place, and that applies as much whether that code is 3-5 lines of webdriver code or one line of cypress code.

100% this is the model we follow. no dom in tests helps a lot. the cypress docs don’t make any sense here

Yeah, "no DOM in tests" is actually a pretty good mantra.

Code that is just inspecting the DOM to find elements, or to do stuff to them that is just working up to the state where you can actually test something, should be in some shared object/library, but that is as easy as:

    import { Whatever } from '/foo/bar';

Having that kind of code outside of the test probably makes the introductory "test hello world" example more complicated, but I think it's definitely a good practice in the real world, and isn't documented well.