Cypress 要不要用 Page Object Model？

Cypress 官方并不推荐传统 POM——自定义命令和 App Actions 模式比 POM 更契合 Cypress 的命令链机制。POM 把 DOM 选择器封进类方法，但 Cypress 的重试机制使得类方法中返回 this 的链式调用容易丢失重试上下文。真正需要时，可用轻量页面对象仅封装选择器常量，操作逻辑仍交给自定义命令。

追问

Cypress 官方推荐的替代模式是什么？ App Actions：通过 cy.request() 直接调用 API 设置状态，跳过 UI 操作步骤。例如登录不再走页面填写表单，而是 cy.request('POST', '/api/login', credentials) 配合 cy.session() 缓存。

POM 在什么场景下仍有价值？ 页面交互极其复杂、选择器频繁变更的 SPA 项目中，POM 的选择器集中管理仍有意义。但应避免在 POM 方法中使用 Cypress 命令，改为返回选择器字符串供测试中组合。

POM 方法中 cy.get() 返回 this 为什么有问题？ cy.get() 返回 Chainable 而非页面对象实例，在 POM 方法中 return this 会导致后续 .should() 等断言脱离 Cypress 重试队列。正确做法是方法内完成全部操作，不返回 this 继续链式调用。

选择器管理有没有更好的方案？ 用 data-cy 或 data-testid 属性统一选择器策略，配合自定义命令封装常用操作，比 POM 类更轻量且不丢失重试能力。

写段代码

javascript
// 推荐：选择器常量 + 自定义命令
const selectors = { email: '[data-cy=email]', submit: '[data-cy=submit]' };

Cypress.Commands.add('login', (email, pwd) => {
  cy.get(selectors.email).type(email);
  cy.get(selectors.submit).click();
});