WebdriverIO SolidJS 组件测试实战基于 Browser Runner 在真实浏览器中测试响应式组件【免费下载链接】webdriverioNext-gen browser and mobile automation test framework for Node.js项目地址: https://gitcode.com/GitHub_Trending/we/webdriverio导读SolidJS 是一款以简单且高性能的响应式著称的用户界面框架而 WebdriverIO 的 Browser Runner 允许你在真实的桌面或移动浏览器中直接运行单元测试与组件测试并通过 WebDriver 协议与页面上渲染的元素交互。本文将围绕 WebdriverIO 官方 SolidJS 组件测试指南完整讲解 Browser Runner 的solid预设配置、vite-plugin-solid依赖安装、测试编写范式与底层实现原理帮助你为 SolidJS 组件搭建一套真实浏览器环境下的可复用测试方案。一、为什么用 Browser Runner 测试 SolidJS传统的组件测试框架如基于 JSDOM 的方案在 Node.js 中对 DOM 与 HTML 标准进行再实现与用户真实使用的浏览器环境存在差异。WebdriverIO 的 Browser Runner 则完全不同它直接在真实浏览器中初始化并执行测试框架二者对比要点如下交互方式JSDOM 只能通过 JavaScript 模拟组件交互Browser Runner 可以通过 WebdriverIO API 基于 WebDriver 协议操作真实元素。Web APIJSDOM 存在部分未支持的 Web API 与 caveats真实浏览器中所有 Web API 均可用包括 Canvas。伪类状态JSDOM 无法测试元素伪状态Browser Runner 支持:hover、:active等伪类。跨浏览器JSDOM 无法做跨浏览器错误检测Browser Runner 支持所有浏览器含移动浏览器。Browser Runner 使用 Vite 编译测试代码并加载到浏览器中内置了 React、Preact、Vue、Svelte、SolidJS、Stencil、Lit 等框架预设其中 SolidJS 就是本文的主角。其安装与整体架构可参见 Component Testing 文档 与 Browser Runner 包说明。注意使用 Browser Runner 时alert、confirm等会阻塞页面的线程对话框无法原生使用它们会导致 WebdriverIO 无法继续与页面通信而挂起。WebdriverIO 为此提供了默认返回值的 mock具体可参考 Mocking 文档。二、环境搭建与 preset 配置2.1 初始化项目在开始前请先通过 WebdriverIO 的初始化向导创建一个项目npm init wdiolatest ./ # 或 yarn create wdio ./在配置向导中选择browser用于单元/组件测试并在预设列表中选择SolidJS。若你只需要基础单元测试也可以选择Other。完整的初始化流程与说明见 Component Testing 文档。2.2 配置 runner 与solid预设在你的wdio.conf.js中将 runner 配置为browser并在其选项中将preset设置为solid// wdio.conf.js export const config { // ... runner: [browser, { preset: solid }], // ... }从源码看solid是 Browser Runner 支持的合法预设值之一。在 FrameworkPreset 类型定义 中列出了全部可选值export type FrameworkPreset react | preact | vue | svelte | lit | solid | stencil2.3 复用已有 Vite 配置如果你已经在项目中使用 Vite 作为开发服务器可以直接复用vite.config.ts中的配置而不必依赖预设import viteConfig from ../vite.config.ts export const config { // ... runner: [browser, { viteConfig }], // ... }viteConfig支持三种形态自定义对象、指向配置文件的字符串路径、或返回配置的函数。它的详细类型与用法见 Runner Options。需要注意的是preset与viteConfig不能同时使用二者在runner选项中互斥。2.4 安装 SolidJS 预设所需的 Vite 插件solid预设底层依赖vite-plugin-solid来将 SolidJS 的 JSX/响应式编译为浏览器可执行的代码。从 vite/constants.ts 中的PRESET_DEPENDENCIES映射可以确认solid: [vite-plugin-solid, default, undefined],也就是说当 preset 为solid时WebdriverIO 会动态加载名为vite-plugin-solid的包并取其default导出作为 Vite 插件。因此你需要手动安装它npm install --save-dev vite-plugin-solid如果没有安装该依赖WebdriverIO 会通过 userfriendlyImport 抛出明确的错误提示并建议你执行npm install vite-plugin-solid或yarn add --dev vite-plugin-solid。2.5 运行测试完成配置与依赖安装后即可启动测试npx wdio run ./wdio.conf.js在 CI 环境中CI环境变量被设置为1或true时Browser Runner 默认会以 headless 模式运行你可以在 runner 选项中通过headless手动控制该行为详见 Runner 文档。三、编写 SolidJS 组件测试3.1 一个典型的 SolidJS 组件假设你有如下使用createSignal管理主题状态的组件import { createSignal } from solid-js function App() { const [theme, setTheme] createSignal(light) const toggleTheme () { const nextTheme theme() light ? dark : light setTheme(nextTheme) } return button onClick{toggleTheme} Current theme: {theme()} /button } export default App这是 SolidJS 典型的响应式范式theme是一个 signal模板中的{theme()}会随其变化自动更新点击按钮触发toggleTheme切换light/dark。3.2 用solid-js/web的render挂载组件在测试文件中使用 SolidJS 自带的render方法来自solid-js/web将组件挂载到测试页面上。推荐使用 WebdriverIO 命令与组件交互因为它们的行为更接近真实用户操作经由 WebDriver 协议发送真实事件例如import { expect } from wdio/globals import { render } from solid-js/web import App from ./components/Component.jsx describe(Solid Component Testing, () { /** * 保证每个测试都在一个新的 root 容器中渲染组件 */ let root: Element beforeEach(() { if (root) { root.remove() } root document.createElement(div) document.body.appendChild(root) }) it(Test theme button toggle, async () { render(App /, root) const buttonEl await $(button) await buttonEl.click() expect(buttonEl).toContainHTML(dark) }) })3.3 关键点拆解1每次测试前创建并清理 root 容器。beforeEach中先移除旧的root再创建新的div挂到document.body上。这样每个用例都从干净的 DOM 状态开始避免多个用例之间组件残留互相污染。官方文档特别提醒如果你不使用 Testing Library 这类会自动清理组件的工具就必须自己把组件挂载到会在用例间清理的容器中参见 Component Testing 文档。2用 WebdriverIO 选择器定位元素。$(button)返回一个元素对象随后的click()是 WebdriverIO 的真实交互命令而非简单的 DOM 事件派发。如果你使用的是 Vite 等工具链别忘了在断言前通过await等待元素就绪。3用expect做断言。expect从wdio/globals导入前提是配置了injectGlobals。这里使用的toContainHTML(dark)断言按钮在点击后其 HTML 内容包含dark文本——这验证了 signal 更新确实反映到了 DOM 中。3.4 测试文件的隔离机制从 Browser Runner 的实现看每个测试文件或测试文件组都在单个页面中运行用例之间会重新加载页面以保证隔离见 Browser Runner 包说明。因此你无需担心测试间全局状态互相污染页面刷新是 Browser Runner 内置的隔离手段。四、底层原理preset 是如何被加载的理解solid预设背后发生了什么有助于你排查环境问题。核心流程位于 vite/server.ts 的start()方法中如果配置了presetWebdriverIO 会在PRESET_DEPENDENCIES表中查找对应的[包名, 导出属性, 插件选项]元组通过userfriendlyImport动态导入该包取出指定导出对 solid 而言是default并调用plugin(opts)将其追加到 Vite 插件列表。若依赖缺失userfriendlyImport会抛出带有安装命令提示的错误信息。此外在preset加载完毕后WebdriverIO 还会将自定义viteConfig与内部默认配置DEFAULT_VITE_CONFIG包括sourcemap: inline、optimizeDeps、自定义日志器等通过deepmerge合并并最后为 Vite 服务器分配一个空闲端口。这也解释了为什么文档建议优先使用 preset或在使用自定义viteConfig时显式加载 SolidJS 的 Vite 插件——preset 的本质就是帮你在内部 Vite 实例上注册正确的框架插件。五、调试、Watch 与进阶配置5.1 使用--watch实现热更新调试组件测试最直接的方式是给 testrunner 加上--watch标志npx wdio run ./wdio.conf.js --watch首次会跑完全部测试之后你修改的文件会被单独重跑如果通过filesToWatch指向应用源码文件那么修改应用代码时会触发全部测试重跑。5.2 使用debug命令断点调试虽然目前还无法让 IDE 断点直接作用到远程浏览器但你可以在测试任意位置调用debug命令暂停执行然后打开 DevTools 的 Sources 面板设置断点。命令触发后终端也会进入 Node.js REPL 提示The execution has stopped! You can now go into the browser or use the command line as REPL (To exit, press ^C again or type .exit)按Ctrl/Commandc或输入.exit即可继续测试。5.3 通过 Selenium Grid 运行若通过 Selenium Grid 运行浏览器需要在 runner 选项中设置host让浏览器能访问到承载测试文件的正确主机例如export const config: WebdriverIO.Config { runner: [browser, { // 运行 WebdriverIO 进程的机器网络 IP host: http://172.168.0.2 }] }5.4 覆盖率coverageBrowser Runner 通过istanbul支持测试覆盖率报告。在 runner 选项中启用runner: [browser, { preset: solid, coverage: { enabled: true, // include: [**], // exclude: [coverage/**, dist/**, **/*.d.ts, ...], // reporter: [text, html, clover, json-summary], // reportsDirectory: ./coverage } }]enabled默认为false其余常用选项include、exclude、reporter、reportsDirectory、lines/functions/branches/statements阈值等的完整默认值见 Runner Options。六、总结在 WebdriverIO 中测试 SolidJS 组件核心路径非常清晰在wdio.conf.js中将runner配置为[browser, { preset: solid }]并安装vite-plugin-solid在测试文件中用solid-js/web的render把组件挂载到每次测试都会重建的 root 容器中用 WebdriverIO 的$/click等命令模拟真实用户交互用wdio/globals的expect断言渲染结果。这一方案的价值在于组件在真实浏览器中运行交互通过 WebDriver 协议下发信号驱动的 UI 变化能够被真实地观察与断言其行为与线上用户体验高度一致。上述配置的完整可运行示例可以参考 WebdriverIO 官方维护的 component-testing-examples 仓库中基于 TypeScript Vite 的 SolidJS 示例配合 Component Testing、Runner 与 Browser Runner 源码 阅读即可掌握从环境搭建到源码级原理的完整链路。【免费下载链接】webdriverioNext-gen browser and mobile automation test framework for Node.js项目地址: https://gitcode.com/GitHub_Trending/we/webdriverio创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 WebdriverIO + SolidJS 组件测试实战：基于 Browser Runner 在真实浏览器中测试响应式组件
WebdriverIO SolidJS 组件测试实战基于 Browser Runner 在真实浏览器中测试响应式组件【免费下载链接】webdriverioNext-gen browser and mobile automation test framework for Node.js项目地址: https://gitcode.com/GitHub_Trending/we/webdriverio导读SolidJS 是一款以简单且高性能的响应式著称的用户界面框架而 WebdriverIO 的 Browser Runner 允许你在真实的桌面或移动浏览器中直接运行单元测试与组件测试并通过 WebDriver 协议与页面上渲染的元素交互。本文将围绕 WebdriverIO 官方 SolidJS 组件测试指南完整讲解 Browser Runner 的solid预设配置、vite-plugin-solid依赖安装、测试编写范式与底层实现原理帮助你为 SolidJS 组件搭建一套真实浏览器环境下的可复用测试方案。一、为什么用 Browser Runner 测试 SolidJS传统的组件测试框架如基于 JSDOM 的方案在 Node.js 中对 DOM 与 HTML 标准进行再实现与用户真实使用的浏览器环境存在差异。WebdriverIO 的 Browser Runner 则完全不同它直接在真实浏览器中初始化并执行测试框架二者对比要点如下交互方式JSDOM 只能通过 JavaScript 模拟组件交互Browser Runner 可以通过 WebdriverIO API 基于 WebDriver 协议操作真实元素。Web APIJSDOM 存在部分未支持的 Web API 与 caveats真实浏览器中所有 Web API 均可用包括 Canvas。伪类状态JSDOM 无法测试元素伪状态Browser Runner 支持:hover、:active等伪类。跨浏览器JSDOM 无法做跨浏览器错误检测Browser Runner 支持所有浏览器含移动浏览器。Browser Runner 使用 Vite 编译测试代码并加载到浏览器中内置了 React、Preact、Vue、Svelte、SolidJS、Stencil、Lit 等框架预设其中 SolidJS 就是本文的主角。其安装与整体架构可参见 Component Testing 文档 与 Browser Runner 包说明。注意使用 Browser Runner 时alert、confirm等会阻塞页面的线程对话框无法原生使用它们会导致 WebdriverIO 无法继续与页面通信而挂起。WebdriverIO 为此提供了默认返回值的 mock具体可参考 Mocking 文档。二、环境搭建与 preset 配置2.1 初始化项目在开始前请先通过 WebdriverIO 的初始化向导创建一个项目npm init wdiolatest ./ # 或 yarn create wdio ./在配置向导中选择browser用于单元/组件测试并在预设列表中选择SolidJS。若你只需要基础单元测试也可以选择Other。完整的初始化流程与说明见 Component Testing 文档。2.2 配置 runner 与solid预设在你的wdio.conf.js中将 runner 配置为browser并在其选项中将preset设置为solid// wdio.conf.js export const config { // ... runner: [browser, { preset: solid }], // ... }从源码看solid是 Browser Runner 支持的合法预设值之一。在 FrameworkPreset 类型定义 中列出了全部可选值export type FrameworkPreset react | preact | vue | svelte | lit | solid | stencil2.3 复用已有 Vite 配置如果你已经在项目中使用 Vite 作为开发服务器可以直接复用vite.config.ts中的配置而不必依赖预设import viteConfig from ../vite.config.ts export const config { // ... runner: [browser, { viteConfig }], // ... }viteConfig支持三种形态自定义对象、指向配置文件的字符串路径、或返回配置的函数。它的详细类型与用法见 Runner Options。需要注意的是preset与viteConfig不能同时使用二者在runner选项中互斥。2.4 安装 SolidJS 预设所需的 Vite 插件solid预设底层依赖vite-plugin-solid来将 SolidJS 的 JSX/响应式编译为浏览器可执行的代码。从 vite/constants.ts 中的PRESET_DEPENDENCIES映射可以确认solid: [vite-plugin-solid, default, undefined],也就是说当 preset 为solid时WebdriverIO 会动态加载名为vite-plugin-solid的包并取其default导出作为 Vite 插件。因此你需要手动安装它npm install --save-dev vite-plugin-solid如果没有安装该依赖WebdriverIO 会通过 userfriendlyImport 抛出明确的错误提示并建议你执行npm install vite-plugin-solid或yarn add --dev vite-plugin-solid。2.5 运行测试完成配置与依赖安装后即可启动测试npx wdio run ./wdio.conf.js在 CI 环境中CI环境变量被设置为1或true时Browser Runner 默认会以 headless 模式运行你可以在 runner 选项中通过headless手动控制该行为详见 Runner 文档。三、编写 SolidJS 组件测试3.1 一个典型的 SolidJS 组件假设你有如下使用createSignal管理主题状态的组件import { createSignal } from solid-js function App() { const [theme, setTheme] createSignal(light) const toggleTheme () { const nextTheme theme() light ? dark : light setTheme(nextTheme) } return button onClick{toggleTheme} Current theme: {theme()} /button } export default App这是 SolidJS 典型的响应式范式theme是一个 signal模板中的{theme()}会随其变化自动更新点击按钮触发toggleTheme切换light/dark。3.2 用solid-js/web的render挂载组件在测试文件中使用 SolidJS 自带的render方法来自solid-js/web将组件挂载到测试页面上。推荐使用 WebdriverIO 命令与组件交互因为它们的行为更接近真实用户操作经由 WebDriver 协议发送真实事件例如import { expect } from wdio/globals import { render } from solid-js/web import App from ./components/Component.jsx describe(Solid Component Testing, () { /** * 保证每个测试都在一个新的 root 容器中渲染组件 */ let root: Element beforeEach(() { if (root) { root.remove() } root document.createElement(div) document.body.appendChild(root) }) it(Test theme button toggle, async () { render(App /, root) const buttonEl await $(button) await buttonEl.click() expect(buttonEl).toContainHTML(dark) }) })3.3 关键点拆解1每次测试前创建并清理 root 容器。beforeEach中先移除旧的root再创建新的div挂到document.body上。这样每个用例都从干净的 DOM 状态开始避免多个用例之间组件残留互相污染。官方文档特别提醒如果你不使用 Testing Library 这类会自动清理组件的工具就必须自己把组件挂载到会在用例间清理的容器中参见 Component Testing 文档。2用 WebdriverIO 选择器定位元素。$(button)返回一个元素对象随后的click()是 WebdriverIO 的真实交互命令而非简单的 DOM 事件派发。如果你使用的是 Vite 等工具链别忘了在断言前通过await等待元素就绪。3用expect做断言。expect从wdio/globals导入前提是配置了injectGlobals。这里使用的toContainHTML(dark)断言按钮在点击后其 HTML 内容包含dark文本——这验证了 signal 更新确实反映到了 DOM 中。3.4 测试文件的隔离机制从 Browser Runner 的实现看每个测试文件或测试文件组都在单个页面中运行用例之间会重新加载页面以保证隔离见 Browser Runner 包说明。因此你无需担心测试间全局状态互相污染页面刷新是 Browser Runner 内置的隔离手段。四、底层原理preset 是如何被加载的理解solid预设背后发生了什么有助于你排查环境问题。核心流程位于 vite/server.ts 的start()方法中如果配置了presetWebdriverIO 会在PRESET_DEPENDENCIES表中查找对应的[包名, 导出属性, 插件选项]元组通过userfriendlyImport动态导入该包取出指定导出对 solid 而言是default并调用plugin(opts)将其追加到 Vite 插件列表。若依赖缺失userfriendlyImport会抛出带有安装命令提示的错误信息。此外在preset加载完毕后WebdriverIO 还会将自定义viteConfig与内部默认配置DEFAULT_VITE_CONFIG包括sourcemap: inline、optimizeDeps、自定义日志器等通过deepmerge合并并最后为 Vite 服务器分配一个空闲端口。这也解释了为什么文档建议优先使用 preset或在使用自定义viteConfig时显式加载 SolidJS 的 Vite 插件——preset 的本质就是帮你在内部 Vite 实例上注册正确的框架插件。五、调试、Watch 与进阶配置5.1 使用--watch实现热更新调试组件测试最直接的方式是给 testrunner 加上--watch标志npx wdio run ./wdio.conf.js --watch首次会跑完全部测试之后你修改的文件会被单独重跑如果通过filesToWatch指向应用源码文件那么修改应用代码时会触发全部测试重跑。5.2 使用debug命令断点调试虽然目前还无法让 IDE 断点直接作用到远程浏览器但你可以在测试任意位置调用debug命令暂停执行然后打开 DevTools 的 Sources 面板设置断点。命令触发后终端也会进入 Node.js REPL 提示The execution has stopped! You can now go into the browser or use the command line as REPL (To exit, press ^C again or type .exit)按Ctrl/Commandc或输入.exit即可继续测试。5.3 通过 Selenium Grid 运行若通过 Selenium Grid 运行浏览器需要在 runner 选项中设置host让浏览器能访问到承载测试文件的正确主机例如export const config: WebdriverIO.Config { runner: [browser, { // 运行 WebdriverIO 进程的机器网络 IP host: http://172.168.0.2 }] }5.4 覆盖率coverageBrowser Runner 通过istanbul支持测试覆盖率报告。在 runner 选项中启用runner: [browser, { preset: solid, coverage: { enabled: true, // include: [**], // exclude: [coverage/**, dist/**, **/*.d.ts, ...], // reporter: [text, html, clover, json-summary], // reportsDirectory: ./coverage } }]enabled默认为false其余常用选项include、exclude、reporter、reportsDirectory、lines/functions/branches/statements阈值等的完整默认值见 Runner Options。六、总结在 WebdriverIO 中测试 SolidJS 组件核心路径非常清晰在wdio.conf.js中将runner配置为[browser, { preset: solid }]并安装vite-plugin-solid在测试文件中用solid-js/web的render把组件挂载到每次测试都会重建的 root 容器中用 WebdriverIO 的$/click等命令模拟真实用户交互用wdio/globals的expect断言渲染结果。这一方案的价值在于组件在真实浏览器中运行交互通过 WebDriver 协议下发信号驱动的 UI 变化能够被真实地观察与断言其行为与线上用户体验高度一致。上述配置的完整可运行示例可以参考 WebdriverIO 官方维护的 component-testing-examples 仓库中基于 TypeScript Vite 的 SolidJS 示例配合 Component Testing、Runner 与 Browser Runner 源码 阅读即可掌握从环境搭建到源码级原理的完整链路。【免费下载链接】webdriverioNext-gen browser and mobile automation test framework for Node.js项目地址: https://gitcode.com/GitHub_Trending/we/webdriverio创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考