技能介绍

痛点：E2E 测试为什么总被接口牵着走

写端到端测试时，最常见的问题是用例绑定在真实后端上。接口改个字段，测试就挂；后端响应慢或返回错误数据，整个测试套件变得不稳定。更麻烦的是，前端往往依赖某个特定响应才能渲染出目标 UI，没有拦截就没法构造这个场景。第二个老问题是元素选择器脆弱——用 CSS 选择器盯着 DOM 结构，一次重构就大面积失败。

这个技能怎么工作

核心是三件事：

cy.intercept() 拦截网络请求：在请求发出前按 URL 或 method 匹配，返回自定义的 mock 响应。响应体、状态码、延迟都可以自己定。
cy.wait() 断言请求发生：配合别名使用，比如 cy.wait('@alias') 可以断言某个接口被调用了一次，还能检查调用参数。这把等待结果变成了验证行为。
Cypress Testing Library 查询可访问元素：findByRole() 按 ARIA role 找元素（比如按钮、对话框），findByText() 按可见文本找。两类查询都贴近用户视角，也更抗重构。

典型流程是：先注册拦截规则，再触发 UI 操作，然后 cy.wait() 等待请求完成，最后用 Testing Library 查询渲染结果。

适用边界与注意点

cy.intercept() 只对 XHR 和 fetch 请求生效，静态资源（如图片）的失败模拟需要其他手段。
拦截规则必须注册在请求发出之前；SSR 框架（如 Next.js）在页面加载时就会发起数据请求，所以 cy.intercept() 要放在 cy.visit() 之前。
Testing Library 的查询依赖可访问性，组件若缺少正确的 ARIA 属性，findByRole() 可能找不到元素。
旧版 Cypress 对 cy.intercept() 有最低版本要求，更早的版本只有 cy.route()（且不支持 fetch）。
单元测试工具（Vitest、Jest）中的请求模拟与这套路子不通用，cy.intercept() 只在 Cypress 运行时工作。