потому что там так и написано 🤷‍♂
начиная с Application actions

Imagine that instead of always entering new items via the UI we could set the state of the application directly from our test. Because Cypress architecture allows interacting with the application under test, this is simple. All we need to do is to expose a reference to the application’s model object by attaching it to the window object for example.

и дальше всю дорогу об этом. А в конце

In the above implementation, the application code cannot do the login using the same method as cy.request. Thus the end-to-end tests should call cy.request() and not invoke an application action

and not invoke an application action - звучит как будто call cy.request() - это не апп экшэнс.

может, конечно, я и не правильно все понял 🤷‍♂

Тут то о чем я писал выше - "в используемом приложении нельзя залогиниться с помощью реквеста. Таким образом е2е тесты должны вызывать cy.request (для логина), а не дергать код апликейшена."
Так и есть, реквест на апи - это не апп экшен. Но вот сама процедура логина - реквест и сохранение кук или локал стореджа - вполне.

Это решение показалось самым изящным, но увы

The input element's type ('number') does not support selection.

можно, конечно, через .executeScript еще и тип поменять :)

интересная статья для начинающих в JS https://blog.craftlab.hu/react-testing-crash-course-479f2108e6df

я запутался. Так что такое application actions? Я смотрю вот на эту статью https://www.cypress.io/blog/2019/01/03/stop-using-page-objects-and-start-using-app-actions/
там описан один единственный подход, когда тест как-то манкипатчит приложение. А ты говоришь что на реальных проектах так не делают и что апи хватает. Так прекондишены через апи делают и адепты пейдж обжектов, уже очень давно 🤷‍♂
если это только про прекондишены через апи/дб/манипуляции с куками, то тогда в чем разница?

Вот статья за 2017 год про пейдж обджекты: https://johnfergusonsmart.com/page-objects-that-suck-less-tips-for-writing-more-maintainable-page-objects/

Рекомендую обратить внимание на пункты:
- Keep business logic out of your Page Objects
- Model user behaviour not user interfaces
- Encapsulate interaction logic inside step methods
- Keep step methods in “action” classes
- Use action classes to model user tasks

Ничего не напоминает?

В статье описано, что нужно моделировать не страницы, а поведение и задачи юзера в приложении. У бахмутова тоже самое + как по максимуму делать прекондишены, и на примере показано как "если шо" дергать функции приложения, и что если других вариантов особо нет - это нормально.

а нужны ли все эти сложности в автотестах? наделать кучу функций с человекочитаемыми именами, а то классы, пейджи, наследование :)

Вот именно. Потому аппликейшен экшнс - подход, который можно применять как с пейдж обджектами, так и без них.

мы не знаем контекста, может и нужно

если тестов немного, на "страницу" пишется максимум 1-2 теста, то я бы не стал заморачиваться пейджами
надо смотреть по ситуации

контекст - это вот эта статья https://www.cypress.io/blog/2019/01/03/stop-using-page-objects-and-start-using-app-actions/
из сайпрес блога где предлагается использовать application actions как альтернативу пейдж обжекту.

Эта статья спорная :)

а что не так?

Мне кажется что экшены и по не взаимоисключают друг друга

прочитал статью. Там пишут что надо делать page components(что тоже самое что и po, но для компонентов) и сверху делать слой для user actions(чтобы потом использовать в бдд стэпах), где будет логика.
у статье из сайпрес блога я не заметил что это "тоже самое + воркэраунды". Там пишут что "не надо использовать ПО, а надо - application actions"(а не user actions)

понять бы что такое апп экшены 🤔

возможно действия в приложении, н-р залогиниться, зарегистрироваться, открыть сообщение

cy.login