WebdriverIO 项目路线图全解从未来规划到已落地里程碑【免费下载链接】webdriverioNext-gen browser and mobile automation test framework for Node.js项目地址: https://gitcode.com/GitHub_Trending/we/webdriverio本篇技术指南以仓库根目录的 ROADMAP.md 为骨架系统梳理 WebdriverIO 这一下一代浏览器与移动端自动化测试框架的长期技术规划既包括组件测试、网络录制、Lighthouse 集成等未来项目也包括 CLI 增强、Cucumber 支持、TypeScript 重写、ESM 化等已经完成的里程碑。读完本文你将理解 WebdriverIO 每个 roadmap 项目背后的技术动因、对应在 monorepo 中的真实源码落点以及社区如何参与这些方向的演进。Roadmap 是什么由谁制定、如何运作WebdriverIO 的 Roadmap 是一份活的记录文档living record用于反映项目当前及预期的优先事项。它有两个基本特征动态可变内容随时可能调整其存在目的仅是为社区提供一个我们正在往哪里走的参考。由 TSC 制定路线图由 Technical Steering Committee技术指导委员会团队设定。如果社区成员想为 WebdriverIO 或任意wdio/*包提出功能建议需要向官方仓库提交 feature request issue只有规模足够大且获得团队批准才会被收录进这份文档。需要特别注意的是bugfix 和小型杂项功能不属于 roadmap projects它们会在常规开发流程中按部就班地处理。这份文档只负责勾勒 WebdriverIO 的长期、大规模规划。未来规划项目九个方向逐一解读ROADMAP 中的Upcoming Projects列表按重要程度罗列了当前关注的方向顺序不分先后。下面结合仓库现状逐一解读每个项目背后的技术意图。1. Component Testing单元与组件测试能力项目描述Component Testing与 WebdriverIO 单元/组件测试能力相关的想法、issue 与增强WebdriverIO 希望不仅能做端到端测试还能让开发者用同一套 API 在真实浏览器中运行单元与组件测试。这一方向在仓库中已经有实质性落地packages/wdio-browser-runner的包描述就是 A WebdriverIO runner to run unit tests tests in the browserpackage.json其依赖包含 Vite、vitest/spy、expect、istanbul 系列覆盖率、vite-plugin-istanbul等可见它是以 Vite 作为浏览器端构建与模块服务基础设施的。配套文档位于 website/docs/component-testing覆盖了Lit、Preact、React、Solid、Stencil、Svelte、Vue等主流框架以及coverage.md覆盖率和mocking.mdMock两个专项能力。仓库的端到端样例也验证了这一点例如e2e/browser-runner/下就包含react.test.tsx、svelte.test.js、vue.test.js、stencil.test.tsx等真实用例。2. Core Initiatives核心功能与技术栈项目描述Core Initiatives与 WebdriverIO 核心功能和技术栈相关的一切这个项目是核心栈的总目录涵盖协议层packages/webdriver、packages/wdio-protocols、配置解析packages/wdio-config、运行器packages/wdio-runner、packages/wdio-local-runner与工具库packages/wdio-utils等的持续演进。核心技术的每一次大版本换代几乎都源自这里比如后文会提到的 TypeScript 重写与 ESM 化就都归属于这一类。3. Google Lighthouse 集成把性能审计带到更多浏览器项目描述Google Lighthouse Integrationwdio/lighthouse-service提供超越 WebDriver 的自动化能力如 PWA、性能测试理想情况是该服务在 Firefox 和 Edge 中也能以同样的方式工作wdio/lighthouse-service的目标是让 WebdriverIO 突破 WebDriver 协议限制直接通过 Chrome DevTools 协议执行 Lighthouse 审计。从仓库看packages/wdio-lighthouse-service 已是一个完整的服务包其 package.json 依赖lighthouse8.6.0、puppeteer-core、devtools-protocol以及istanbul-*覆盖率相关库源码目录src/下包含auditor.ts、commands.ts、gatherer/、handler/等模块。ROADMAP 明确写出期望希望该服务在Firefox 与 Edge上获得与 Chrome 一致的能力——这是一个仍在推进中的跨浏览器目标。4. Network Recording像 Jest 快照一样断言网络行为项目描述Network Recording希望让断言浏览器网络行为变得无缝。受 Jest 及其 Snapshot 功能启发在 WebdriverIO 中实现类似能力这一方向借鉴 Jest 的 Snapshot 思路目标是让开发者能像断言 DOM 一样断言网络请求行为。该思想已经在仓库中部分演化为快照测试能力——website/docs/Snapshot.md 详细说明了toMatchSnapshot()与toMatchInlineSnapshot()的用法而npx wdio run wdio.conf.js -s或--updateSnapshot可以更新快照对应 CLI 实现见 packages/wdio-cli/src/commands/run.ts 中的updateSnapshots参数。网络行为本身则由 mock 体系承载browser.mock()等命令的端到端用例位于 e2e/wdio/headless/mocking.e2e.ts配套文档见 website/docs/MocksAndSpies.md。5. 改进前端框架支持React / Angular / Vue / Svelte 等项目描述Improved Frontend Framework Support几乎所有 Web 应用都由 React、Angular、Vue、Svelte 等现代框架编写这些框架在选择元素、内省应用状态等环节往往比较棘手。WebdriverIO 有能力帮助用户更好地测试这些应用现代前端框架在 DOM 选择器和状态内省上对测试框架提出了额外要求。WebdriverIO 的应对路径是把能力下沉到组件测试层对应前述 Component Testing并为每个框架提供针对性文档与驱动见 website/docs/component-testing 下的 React.md、Vue.md、Svelte.md 等。6. 更好的调试能力用 IDE 打断点项目描述Better Debugging Capabilities已有少量调试测试代码的选项但使用 Node.js 原生调试仍不直观——它需要特殊处理 worker 与子进程。目标应是开发者能直接用 IDE 设置断点来调试当多个进程、多个浏览器同时跑大量测试时调试难度会显著上升。仓库中 website/docs/Debugging.md 总结了三条核心路径browser.debug()命令暂停测试并让命令行切到 REPL 模式在 REPL 里可以像在测试中一样操作browser对象以及$/$$函数调试完成后用^C或.exit继续。REPL 机制的独立实现见packages/wdio-repl。maxInstances: 1 定向 spec把并行度降为 1、只跑目标 spec 与浏览器可大幅简化复现。动态配置 --inspect利用环境变量在调试态与常规态之间切换配置例如execArgv: debug ? [--inspect] : []再用DEBUGtrue npx wdio wdio.conf.js --spec ./tests/e2e/myspec.test.js启动配合 IDE 的 auto-attach 或.vscode/launch.json打断点。调试易用性尤其是IDE 打断点即可调试仍是 roadmap 中期望继续打磨的方向。7. VS Code 扩展写、跑、调一站式项目描述VS Code Extension为提升测试编写体验计划构建一个 VS Code 扩展让用户在 VS Code 中编写、运行和调试测试这是关于测试作者体验的工程方向。当前仓库中已提供相应的社区资源website/recipes/vscode-extension目录收录了 VS Code 扩展相关配方recipes/vscode-extension下有两个 JS 文件可作为编写/调试配置的参考。8. Fiddle 平台在线分享测试片段项目描述Fiddle Platform一位社区成员已开始为 WebdriverIO 构建 fiddletry.webdriver.io目前运行不佳需要更多工作。在线分享测试代码片段将极大帮助定位自动化脚本中的问题未来也可能接入 Sauce LabsFiddle 平台的核心诉求是用一段可运行的在线示例快速复现并交流自动化问题。ROADMAP 指出其当前实现尚不完善需要更多社区投入并保留与云端服务如 Sauce Labs集成的想象空间。已完成的路线图项目九个里程碑复盘ROADMAP 用一个表格完整记录了已经交付的路线图项目包括完成日期与对应的 WebdriverIO 发行版本。下表汇总了原文档的全部信息项目完成日期对应 WebdriverIO 版本让 CLI 工具更强大CLI 增强2019-06-06v5.10.0Cucumber 框架支持2019-07-09v5.11.0Jest 框架支持2019-12-20v6.0.0内置断言库Custom Assertion Library2019-12-20v6.0.0自动生成示例文件Autogenerate Sample Files2020-06-13v6.2.0集成到常见脚手架/构建工具2020-07-18v6.2.0网络原语Network Primitives2020-07-16v6.3.0TypeScript 重写2021-02-08v7.0.0ESM 支持2022-12-01v8.0.0下面选取其中最有代表性的项目做源码级复盘。CLI 更强大一行命令装配插件v5.10.0原项目动因对不熟悉项目或 WebDriver 的新手来说手动向配置中添加 service / reporter 插件相当困难。在 CLI 界面增加简单命令允许添加 service 与 reporter 并自动修改配置文件可以大幅简化插件装配过程。仓库现状packages/wdio-cli已经是一个完整的 CLI 包src/commands/下包含run.ts、repl.ts与index.ts三个命令模块。run命令的updateSnapshots-s、watch、hostname、logLevel、bail、waitforTimeout等参数都在 run.ts 中定义脚手架初始化由packages/create-wdio承载其src/下含 44 个 EJS 模板用于按需生成各类配置文件。这正是配置向导 命令思路的产品化结果。Cucumber 框架支持v5.11.0原项目动因大量用户把 Cucumber 作为首选框架。社区已经完成了初始工作代码补齐单元测试后即可发布。仓库现状packages/wdio-cucumber-framework现已成为官方一等公民框架src/下有 5 个 TS 源文件与 1 个 CTS 文件测试覆盖见packages/wdio-cucumber-framework/tests配套的tests/cucumber/目录中还有真实的 feature 文件与 step-definitions 样例。Jest 框架支持与内置断言库v6.0.0原项目动因Jest 已是 JS 生态最流行的单元测试框架之一。尽管多数特性在 e2e 领域用处有限但快照测试等能力对编写更好的 e2e 测试很有帮助。与之配套WebdriverIO 希望内置一套原生断言库类似 Jest / Jasmine 提供的让所有框架下的元素/对象断言更简单。仓库现状断言与快照能力已经深度融入框架。toMatchSnapshot()/toMatchInlineSnapshot()的完整用法见 website/docs/Snapshot.mdDOM、任意对象以及 WebdriverIO 命令返回值都可以被快照快照产物示例含 shadow DOM 嵌套结构见 e2e/browser-runner/snapshots/lit.test.js.snap。与此同时expect-webdriverio可见于根package.json的 mock 文件__mocks__/expect-webdriverio.ts提供了元素级别的异步断言例如await expect(elementList).toBeElementsArrayOfSize(7)这类断言会自动等待条件满足详见 Debugging.md 与 BestPractices.md。自动生成示例文件v6.2.0原项目动因允许用户预置现成 boilerplate无需自行搭建这些文件。社区积累了大量可用的 boilerplate 项目希望它们能作为测试搭建的基线通过配置向导或新的wdio命令被选用。仓库现状这一能力由packages/create-wdio承担。其src/内含 57 个文件44 个 EJS 模板 12 个 TS 源文件 1 个 feature 文件可交互式生成从wdio.conf.*到各类框架/工具配置在内的整套初始化文件与命令 向导的路线图意图完全一致。网络原语v6.3.0原项目动因随着 Puppeteer 的跨浏览器支持提升为 WebdriverIO 提供更好的网络层访问原语这些能力在 WebDriver 演进到 WebDriver BiDi 协议W3C 工作组与浏览器厂商正在设计的新版 WebDriver后很可能获得更广泛支持。仓库现状网络能力已全面落地为 mock 与拦截体系。browser.mock()、browser.throttle()等命令的文档见 website/docs/MocksAndSpies.md真实端到端用例见 e2e/wdio/headless/mocking.e2e.ts。而关于 BiDi 的预见也已兑现WebdriverIO v9 发布说明website/blog/2024-08-15-webdriverio-v9-release.md指出v9 的所有会话默认启用 WebDriver BiDi除非通过wdio:enforceWebDriverClassic显式关闭browser.isBidi属性可查询当前会话是否支持 Bidiurl命令也顺势支持自定义请求头、Basic 认证、beforeLoad注入脚本等能力。TypeScript 重写v7.0.0原项目动因随着代码库增长难以发现的类型问题影响越来越大。为规避这类问题并让代码库更易维护计划整体重写为 TypeScript。仓库现状这是已经彻底完成的重构——当前仓库的packages/下所有核心包webdriver、webdriverio、wdio-config、wdio-runner、wdio-cli、wdio-protocols等的源码均以.ts/.cts编写类型定义收敛于packages/wdio-types顶层 tsconfig.json 统一管理编译配置并通过tests/typings/下的类型级测试如tests/typings/webdriverio、tests/typings/mocha等配合npx tsc --skipLibCheck持续保障类型正确性。开发者也可以直接参照tests/typings/README.md了解类型测试的组织方式。ESM 支持v8.0.0原项目动因随着生态转向 ESM 模块体系将整个代码库改造为可在 ESM 环境运行同时保持对 CommonJS 项目的兼容。仓库现状根 package.json 明确声明type: module并使用 pnpm workspace 管理 monorepopackages/webdriver同时提供.ts与.cts入口以满足 CJS 消费场景。仓库还专门维护了互操作测试tests/interop/下包含webdriver.e2e.js、webdriverio.e2e.js等用例用于验证 ESM 环境下各包的导入行为且tests/interop/package.json独立管理其依赖。如何参与把想法推上 RoadmapROADMAP 明确给出了社区参与的通道功能建议应通过官方仓库的feature requestissue 模板提交只有足够规模且被团队批准才会进入 Roadmap。路线图项目在 GitHub 的 project board 中组织每个项目对应一个 Vision Tracker 议题在其上评论是最佳的参与方式。部分 project 可能是空的——这恰恰意味着它们在等待社区的 idea 与建议。与其等别人实现不如直接参与推进这些倡议。一句话总结如果你希望某个wdio/*包具备某项能力先提交 issue再关注对应 project 的讨论这是让需求进入路线图的唯一官方路径。结语WebdriverIO 的 Roadmap 清楚地展示了一条从协议层到体验层的演进主线先是 WebDriver / BiDi 协议与网络原语打底再用 TypeScript 与 ESM 重构技术栈继而通过 CLI 向导、create-wdio、内置断言与快照优化开发体验最终把组件测试、Lighthouse 性能审计、框架级支持等能力逐步沉淀为官方包。对照当前仓库packages/、e2e/、website/docs/你会发现 Roadmap 上的绝大多数方向都能找到对应的源码与文档落点——这份文档既是未来方向的指引也是理解 WebdriverIO 现有架构演进脉络的最佳索引。【免费下载链接】webdriverioNext-gen browser and mobile automation test framework for Node.js项目地址: https://gitcode.com/GitHub_Trending/we/webdriverio创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 WebdriverIO 项目路线图全解：从未来规划到已落地里程碑
WebdriverIO 项目路线图全解从未来规划到已落地里程碑【免费下载链接】webdriverioNext-gen browser and mobile automation test framework for Node.js项目地址: https://gitcode.com/GitHub_Trending/we/webdriverio本篇技术指南以仓库根目录的 ROADMAP.md 为骨架系统梳理 WebdriverIO 这一下一代浏览器与移动端自动化测试框架的长期技术规划既包括组件测试、网络录制、Lighthouse 集成等未来项目也包括 CLI 增强、Cucumber 支持、TypeScript 重写、ESM 化等已经完成的里程碑。读完本文你将理解 WebdriverIO 每个 roadmap 项目背后的技术动因、对应在 monorepo 中的真实源码落点以及社区如何参与这些方向的演进。Roadmap 是什么由谁制定、如何运作WebdriverIO 的 Roadmap 是一份活的记录文档living record用于反映项目当前及预期的优先事项。它有两个基本特征动态可变内容随时可能调整其存在目的仅是为社区提供一个我们正在往哪里走的参考。由 TSC 制定路线图由 Technical Steering Committee技术指导委员会团队设定。如果社区成员想为 WebdriverIO 或任意wdio/*包提出功能建议需要向官方仓库提交 feature request issue只有规模足够大且获得团队批准才会被收录进这份文档。需要特别注意的是bugfix 和小型杂项功能不属于 roadmap projects它们会在常规开发流程中按部就班地处理。这份文档只负责勾勒 WebdriverIO 的长期、大规模规划。未来规划项目九个方向逐一解读ROADMAP 中的Upcoming Projects列表按重要程度罗列了当前关注的方向顺序不分先后。下面结合仓库现状逐一解读每个项目背后的技术意图。1. Component Testing单元与组件测试能力项目描述Component Testing与 WebdriverIO 单元/组件测试能力相关的想法、issue 与增强WebdriverIO 希望不仅能做端到端测试还能让开发者用同一套 API 在真实浏览器中运行单元与组件测试。这一方向在仓库中已经有实质性落地packages/wdio-browser-runner的包描述就是 A WebdriverIO runner to run unit tests tests in the browserpackage.json其依赖包含 Vite、vitest/spy、expect、istanbul 系列覆盖率、vite-plugin-istanbul等可见它是以 Vite 作为浏览器端构建与模块服务基础设施的。配套文档位于 website/docs/component-testing覆盖了Lit、Preact、React、Solid、Stencil、Svelte、Vue等主流框架以及coverage.md覆盖率和mocking.mdMock两个专项能力。仓库的端到端样例也验证了这一点例如e2e/browser-runner/下就包含react.test.tsx、svelte.test.js、vue.test.js、stencil.test.tsx等真实用例。2. Core Initiatives核心功能与技术栈项目描述Core Initiatives与 WebdriverIO 核心功能和技术栈相关的一切这个项目是核心栈的总目录涵盖协议层packages/webdriver、packages/wdio-protocols、配置解析packages/wdio-config、运行器packages/wdio-runner、packages/wdio-local-runner与工具库packages/wdio-utils等的持续演进。核心技术的每一次大版本换代几乎都源自这里比如后文会提到的 TypeScript 重写与 ESM 化就都归属于这一类。3. Google Lighthouse 集成把性能审计带到更多浏览器项目描述Google Lighthouse Integrationwdio/lighthouse-service提供超越 WebDriver 的自动化能力如 PWA、性能测试理想情况是该服务在 Firefox 和 Edge 中也能以同样的方式工作wdio/lighthouse-service的目标是让 WebdriverIO 突破 WebDriver 协议限制直接通过 Chrome DevTools 协议执行 Lighthouse 审计。从仓库看packages/wdio-lighthouse-service 已是一个完整的服务包其 package.json 依赖lighthouse8.6.0、puppeteer-core、devtools-protocol以及istanbul-*覆盖率相关库源码目录src/下包含auditor.ts、commands.ts、gatherer/、handler/等模块。ROADMAP 明确写出期望希望该服务在Firefox 与 Edge上获得与 Chrome 一致的能力——这是一个仍在推进中的跨浏览器目标。4. Network Recording像 Jest 快照一样断言网络行为项目描述Network Recording希望让断言浏览器网络行为变得无缝。受 Jest 及其 Snapshot 功能启发在 WebdriverIO 中实现类似能力这一方向借鉴 Jest 的 Snapshot 思路目标是让开发者能像断言 DOM 一样断言网络请求行为。该思想已经在仓库中部分演化为快照测试能力——website/docs/Snapshot.md 详细说明了toMatchSnapshot()与toMatchInlineSnapshot()的用法而npx wdio run wdio.conf.js -s或--updateSnapshot可以更新快照对应 CLI 实现见 packages/wdio-cli/src/commands/run.ts 中的updateSnapshots参数。网络行为本身则由 mock 体系承载browser.mock()等命令的端到端用例位于 e2e/wdio/headless/mocking.e2e.ts配套文档见 website/docs/MocksAndSpies.md。5. 改进前端框架支持React / Angular / Vue / Svelte 等项目描述Improved Frontend Framework Support几乎所有 Web 应用都由 React、Angular、Vue、Svelte 等现代框架编写这些框架在选择元素、内省应用状态等环节往往比较棘手。WebdriverIO 有能力帮助用户更好地测试这些应用现代前端框架在 DOM 选择器和状态内省上对测试框架提出了额外要求。WebdriverIO 的应对路径是把能力下沉到组件测试层对应前述 Component Testing并为每个框架提供针对性文档与驱动见 website/docs/component-testing 下的 React.md、Vue.md、Svelte.md 等。6. 更好的调试能力用 IDE 打断点项目描述Better Debugging Capabilities已有少量调试测试代码的选项但使用 Node.js 原生调试仍不直观——它需要特殊处理 worker 与子进程。目标应是开发者能直接用 IDE 设置断点来调试当多个进程、多个浏览器同时跑大量测试时调试难度会显著上升。仓库中 website/docs/Debugging.md 总结了三条核心路径browser.debug()命令暂停测试并让命令行切到 REPL 模式在 REPL 里可以像在测试中一样操作browser对象以及$/$$函数调试完成后用^C或.exit继续。REPL 机制的独立实现见packages/wdio-repl。maxInstances: 1 定向 spec把并行度降为 1、只跑目标 spec 与浏览器可大幅简化复现。动态配置 --inspect利用环境变量在调试态与常规态之间切换配置例如execArgv: debug ? [--inspect] : []再用DEBUGtrue npx wdio wdio.conf.js --spec ./tests/e2e/myspec.test.js启动配合 IDE 的 auto-attach 或.vscode/launch.json打断点。调试易用性尤其是IDE 打断点即可调试仍是 roadmap 中期望继续打磨的方向。7. VS Code 扩展写、跑、调一站式项目描述VS Code Extension为提升测试编写体验计划构建一个 VS Code 扩展让用户在 VS Code 中编写、运行和调试测试这是关于测试作者体验的工程方向。当前仓库中已提供相应的社区资源website/recipes/vscode-extension目录收录了 VS Code 扩展相关配方recipes/vscode-extension下有两个 JS 文件可作为编写/调试配置的参考。8. Fiddle 平台在线分享测试片段项目描述Fiddle Platform一位社区成员已开始为 WebdriverIO 构建 fiddletry.webdriver.io目前运行不佳需要更多工作。在线分享测试代码片段将极大帮助定位自动化脚本中的问题未来也可能接入 Sauce LabsFiddle 平台的核心诉求是用一段可运行的在线示例快速复现并交流自动化问题。ROADMAP 指出其当前实现尚不完善需要更多社区投入并保留与云端服务如 Sauce Labs集成的想象空间。已完成的路线图项目九个里程碑复盘ROADMAP 用一个表格完整记录了已经交付的路线图项目包括完成日期与对应的 WebdriverIO 发行版本。下表汇总了原文档的全部信息项目完成日期对应 WebdriverIO 版本让 CLI 工具更强大CLI 增强2019-06-06v5.10.0Cucumber 框架支持2019-07-09v5.11.0Jest 框架支持2019-12-20v6.0.0内置断言库Custom Assertion Library2019-12-20v6.0.0自动生成示例文件Autogenerate Sample Files2020-06-13v6.2.0集成到常见脚手架/构建工具2020-07-18v6.2.0网络原语Network Primitives2020-07-16v6.3.0TypeScript 重写2021-02-08v7.0.0ESM 支持2022-12-01v8.0.0下面选取其中最有代表性的项目做源码级复盘。CLI 更强大一行命令装配插件v5.10.0原项目动因对不熟悉项目或 WebDriver 的新手来说手动向配置中添加 service / reporter 插件相当困难。在 CLI 界面增加简单命令允许添加 service 与 reporter 并自动修改配置文件可以大幅简化插件装配过程。仓库现状packages/wdio-cli已经是一个完整的 CLI 包src/commands/下包含run.ts、repl.ts与index.ts三个命令模块。run命令的updateSnapshots-s、watch、hostname、logLevel、bail、waitforTimeout等参数都在 run.ts 中定义脚手架初始化由packages/create-wdio承载其src/下含 44 个 EJS 模板用于按需生成各类配置文件。这正是配置向导 命令思路的产品化结果。Cucumber 框架支持v5.11.0原项目动因大量用户把 Cucumber 作为首选框架。社区已经完成了初始工作代码补齐单元测试后即可发布。仓库现状packages/wdio-cucumber-framework现已成为官方一等公民框架src/下有 5 个 TS 源文件与 1 个 CTS 文件测试覆盖见packages/wdio-cucumber-framework/tests配套的tests/cucumber/目录中还有真实的 feature 文件与 step-definitions 样例。Jest 框架支持与内置断言库v6.0.0原项目动因Jest 已是 JS 生态最流行的单元测试框架之一。尽管多数特性在 e2e 领域用处有限但快照测试等能力对编写更好的 e2e 测试很有帮助。与之配套WebdriverIO 希望内置一套原生断言库类似 Jest / Jasmine 提供的让所有框架下的元素/对象断言更简单。仓库现状断言与快照能力已经深度融入框架。toMatchSnapshot()/toMatchInlineSnapshot()的完整用法见 website/docs/Snapshot.mdDOM、任意对象以及 WebdriverIO 命令返回值都可以被快照快照产物示例含 shadow DOM 嵌套结构见 e2e/browser-runner/snapshots/lit.test.js.snap。与此同时expect-webdriverio可见于根package.json的 mock 文件__mocks__/expect-webdriverio.ts提供了元素级别的异步断言例如await expect(elementList).toBeElementsArrayOfSize(7)这类断言会自动等待条件满足详见 Debugging.md 与 BestPractices.md。自动生成示例文件v6.2.0原项目动因允许用户预置现成 boilerplate无需自行搭建这些文件。社区积累了大量可用的 boilerplate 项目希望它们能作为测试搭建的基线通过配置向导或新的wdio命令被选用。仓库现状这一能力由packages/create-wdio承担。其src/内含 57 个文件44 个 EJS 模板 12 个 TS 源文件 1 个 feature 文件可交互式生成从wdio.conf.*到各类框架/工具配置在内的整套初始化文件与命令 向导的路线图意图完全一致。网络原语v6.3.0原项目动因随着 Puppeteer 的跨浏览器支持提升为 WebdriverIO 提供更好的网络层访问原语这些能力在 WebDriver 演进到 WebDriver BiDi 协议W3C 工作组与浏览器厂商正在设计的新版 WebDriver后很可能获得更广泛支持。仓库现状网络能力已全面落地为 mock 与拦截体系。browser.mock()、browser.throttle()等命令的文档见 website/docs/MocksAndSpies.md真实端到端用例见 e2e/wdio/headless/mocking.e2e.ts。而关于 BiDi 的预见也已兑现WebdriverIO v9 发布说明website/blog/2024-08-15-webdriverio-v9-release.md指出v9 的所有会话默认启用 WebDriver BiDi除非通过wdio:enforceWebDriverClassic显式关闭browser.isBidi属性可查询当前会话是否支持 Bidiurl命令也顺势支持自定义请求头、Basic 认证、beforeLoad注入脚本等能力。TypeScript 重写v7.0.0原项目动因随着代码库增长难以发现的类型问题影响越来越大。为规避这类问题并让代码库更易维护计划整体重写为 TypeScript。仓库现状这是已经彻底完成的重构——当前仓库的packages/下所有核心包webdriver、webdriverio、wdio-config、wdio-runner、wdio-cli、wdio-protocols等的源码均以.ts/.cts编写类型定义收敛于packages/wdio-types顶层 tsconfig.json 统一管理编译配置并通过tests/typings/下的类型级测试如tests/typings/webdriverio、tests/typings/mocha等配合npx tsc --skipLibCheck持续保障类型正确性。开发者也可以直接参照tests/typings/README.md了解类型测试的组织方式。ESM 支持v8.0.0原项目动因随着生态转向 ESM 模块体系将整个代码库改造为可在 ESM 环境运行同时保持对 CommonJS 项目的兼容。仓库现状根 package.json 明确声明type: module并使用 pnpm workspace 管理 monorepopackages/webdriver同时提供.ts与.cts入口以满足 CJS 消费场景。仓库还专门维护了互操作测试tests/interop/下包含webdriver.e2e.js、webdriverio.e2e.js等用例用于验证 ESM 环境下各包的导入行为且tests/interop/package.json独立管理其依赖。如何参与把想法推上 RoadmapROADMAP 明确给出了社区参与的通道功能建议应通过官方仓库的feature requestissue 模板提交只有足够规模且被团队批准才会进入 Roadmap。路线图项目在 GitHub 的 project board 中组织每个项目对应一个 Vision Tracker 议题在其上评论是最佳的参与方式。部分 project 可能是空的——这恰恰意味着它们在等待社区的 idea 与建议。与其等别人实现不如直接参与推进这些倡议。一句话总结如果你希望某个wdio/*包具备某项能力先提交 issue再关注对应 project 的讨论这是让需求进入路线图的唯一官方路径。结语WebdriverIO 的 Roadmap 清楚地展示了一条从协议层到体验层的演进主线先是 WebDriver / BiDi 协议与网络原语打底再用 TypeScript 与 ESM 重构技术栈继而通过 CLI 向导、create-wdio、内置断言与快照优化开发体验最终把组件测试、Lighthouse 性能审计、框架级支持等能力逐步沉淀为官方包。对照当前仓库packages/、e2e/、website/docs/你会发现 Roadmap 上的绝大多数方向都能找到对应的源码与文档落点——这份文档既是未来方向的指引也是理解 WebdriverIO 现有架构演进脉络的最佳索引。【免费下载链接】webdriverioNext-gen browser and mobile automation test framework for Node.js项目地址: https://gitcode.com/GitHub_Trending/we/webdriverio创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考