e2e路线图前瞻：通往1.0的API稳定性与版本规划
【免费下载链接】e2eNext generation e2e testing framework for web and mobile apps.项目地址: https://gitcode.com/GitHub_Trending/e2e6/e2e
e2e 是一款面向 Web 和移动端的下一代端到端测试框架（e2e testing framework）：用自然语言描述测试目标，由 AI Agent 驱动应用完成操作，再用定位器和断言验证结果。当前项目正处于0.18.0的活跃开发阶段，README 中明确写着"在通往 1.0 的路上，API 和配置仍可能在次版本间变化"。这篇文章带你提前看懂它的路线图：哪些接口正在"冻结"、版本如何演进、以及 1.0 到底意味着什么。
🧭 版本现状：0.x 阶段走完了哪些关键节点
这个项目采用monorepo + changesets的发布体系，e2e核心运行器与@e2e-dev/web、@e2e-dev/mobile、@e2e-dev/github、@e2e-dev/kernel、@e2e-dev/eas、@e2e-dev/decision等引擎/集成包各自独立计版。从 packages/e2e/CHANGELOG.md 可以清晰看到 0.x 阶段的演进主线——每一次大改都是在为 1.0 的"锁定"做铺垫：
| 版本 | 标志性变化 |
|---|---|
0.2.0 | "driver/backend" 概念落地，Playwright 引擎拆分为独立包 |
0.5.0 | backend 全面更名为engine（引擎），应用声明移入引擎工厂 |
0.10.0 | playwright改为 peer 依赖，引擎不再捆绑浏览器 |
0.11.0 | 引擎按"驱动对象"命名：web()/mobile()；运行器更名e2e |
0.15.0 | agents配置对象化、secrets与credentials命名空间分离、browser夹具定型 |
0.17.0 | playwright-core精确锁版；interrupted与failed语义拆分 |
0.18.0 | 自建基于 oxc 的 TypeScript 加载器替代 tsx；要求 Node.js22.22.3+ / 24.8.0+ |
💡 0.x 阶段遵循的惯例是：即使是破坏性变更也只提升 minor 版本号，但每个被删除的旧配置键都会以
INVALID_CONFIG错误在加载期点名告诉你替代写法（例如specVersion会提示"delete it; the runner version is the format version"）。这让频繁升级的迁移成本非常低。
仓库内置了 7 个开箱即通的示例工程（Vite、Next.js、Expo、SwiftUI、Jetpack Compose、Kotlin Multiplatform、Flutter），它们既是文档，也是 1.0 之前的兼容性回归矩阵，全部位于 examples/ 目录。
🔒 API 稳定性策略：正在冻结的三层契约
1.0 的核心是"锁定"，而路线图里能看到的冻结动作集中在三个层面：
- 引擎 SPI（引擎服务接口）0.14 版本起，packages/e2e/src/engine/ 中的引擎契约被明确重塑为"为 1.0 锁定的、仅 UI 的、跨平台的 SPI"，
spiVersion稳定在1。defineEngine、perform、pointerActions等构成第三方编写自定义引擎（参见 docs/writing-an-engine.mdx）的长期接口。 - 报告与会话的线上格式（Wire Format）
report.json、会话、Agent 判定结果分别由 packages/e2e/schema/ 下的 JSON Schema 约束（specVersion: '0.1'），且 schema 文件随 npm 包一起发布——这是"版本即格式版本"策略：配置里不再需要手写specVersion，运行器版本就是格式版本。 - Agent 判定协议
agent-judgment已从 v1 升级为 v2（holds / fails / inconclusive三态判定），v1 schema 被标记为"弃用但保留于稳定窗口内"——这正是 1.0 前后平滑迁移的典型手法。
📦 版本规划：从 0.x 到 1.0 的路径
- changesets 驱动发布：通过
pnpm changeset提交minor/patch变更说明，version-packages+release完成发版；另有canary快照流水线（见 package.json 中的canary:publish脚本与 scripts/canary-changeset.ts），社区可以先用@canary标签尝鲜未定型的特性。 - 依赖范围治理：引擎包对
e2e核心声明>=0.15.0 <1这类 peer 范围，配合 scripts/restore-peer-ranges.ts 保证"只升级核心、引擎不动"也能正常安装。 - 1.0 的语义承诺：按 0.x 惯例反推，1.0 之后将进入标准 semver 承诺——只有 patch 级别的向后兼容变更，破坏性变更留给 2.0。届时引擎 SPI、线上格式、CLI 行为都应以 changelog 记载为准。
✅ 1.0 前必须跑通的"验收关卡"
项目把"自我测试"做成了独立应用，这些就是 1.0 前的质量门槛：
- apps/testbed/：桌面级 Web 回归测试床，覆盖表单、弹窗、滚动、下载等全量交互；
- apps/web-benchmark/：40+ 个 Web 基准场景（含 Shadow DOM、虚拟列表、ARIA 陷阱等"敌对"页面）；
- apps/mobile-benchmark/：移动端基准套件，含手势、权限弹窗、Apple Pay 等真机级场景。
🚀 给使用者的三条建议
- 现在就可以用：0.18 阶段功能已完整（Agent 回放缓存、MCP 服务器、探索模式、GitHub PR 评论报告器），只需接受"次版本可能调整 API"。
- 升级先读 changelog：每个包的 CHANGELOG.md 都写明了破坏性变更的迁移方式，配置错误信息本身也是"迁移指南"。
- 提交回放缓存：把
.e2e/cache/纳入版本控制，配合--strict-cache，界面一变更 CI 立即变红，而不是悄悄消耗模型调用。
想动手验证整个路线图的现状？把仓库克隆到本地跑一跑示例即可：
git clone https://gitcode.com/GitHub_Trending/e2e6/e2e cd e2e/examples/with-vite && npm install && npm test总结一句：e2e 的 1.0 不是"功能大爆发"，而是一场接口收敛工程——引擎 SPI、报告格式、判定协议三层契约相继锁定，7 个示例栈 + 3 套基准持续压测。对于已经在使用 0.x 的团队来说，现在写下的测试，正是 1.0 最直接的"验收代码"。
【免费下载链接】e2eNext generation e2e testing framework for web and mobile apps.项目地址: https://gitcode.com/GitHub_Trending/e2e6/e2e
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
