从你已经录好的 Playwright spec 里自动抽取 Page Object

你有五个 spec，开头都长一样：落到 /dashboard、打开 Overview 面板、再点进 Projects。这段开场你当初驱动应用录过一次，之后它就复制进了每一个需要走到那儿的 spec。把 Projects 标签页改个名，你就得改五个文件。

Page Object Model 治的就是这个病：让一个类拥有这段共享导航，每个 spec 只调一个方法。可要手写，就得把每个 spec 重读一遍，找出公共前缀，再用同样的手法把它们逐个重构，一个都不能漏。

Hover 帮你找出前缀

detect_shared_flows 会比对各个 spec 里那些有据可查的步骤记录，把至少被 N 个 spec 共享的每一段序列都报出来。接着 extract_page_objects 会在 pages/ 下生成一个页面类、一个把它接进你测试的带类型 fixtures.ts，再把每一个受影响的 spec 重新渲染一遍，用那个方法替掉重复的步骤。

这一切都不跑模型。Hover 当初就把共享步骤录成了结构化、有据可查的动作，每个动作无非是一个 role、一个 name 和一个 value，所以抽取不过是把这些动作确定性地翻译成一个类方法。那个带你走到 Projects 的方法，用的还是你 spec 里原本那个 getByRole。重构过后，record equals replay 依旧成立。

你的登录不会被卷进来

假如五个 spec 都共享一次 /login 访问加一次密码填充，那段前缀不该做成 Page Object，它属于一个 auth fixture——登录一次，会话复用。Hover 认得出被脱敏的凭据，会把那段前缀排除在抽取之外，所以你的登录会留在它本该待的 auth.setup.ts 里。登录一次，跨每个测试复用会话 →

它在什么时候发生

在一次 test_app 运行里，一旦 Hover 已经结晶出好几个 spec，它就会查一查有没有可抽取的流程，并问你要不要把它拉出来。你说行，它就一步到位，写出页面类、fixture 和折叠后的 spec。提交前，你先看 diff。

就算这次重构跑得晚，等你已经攒了一整套套件之后再做，也一样安全，因为 sidecar 为每个 spec 都保留了完整的录制上下文。要把某个 spec 重新渲染成使用 Page Object 时，Hover 会读这份上下文、原样重写，连 auth 设置和断言都一并保留，所以折叠一个 spec，绝不会把它的登录弄丢。

阅读 Page Object 文档 →