CodeVetter · Repo Unpack · Behavior traces
webdriverio/webdriverio
Three concrete flows were followed through implementation: CLI test execution, element lookup and click, and screenshot persistence. Startup includes configuration import, worker scheduling, framework discovery, session creation, and teardown. Element interaction changes behavior according to runner environment, protocol support, and error conditions. Screenshot persistence separates capture selection from filesystem output.
- Startup 1: wdio.js imports the compiled CLI → run() parses commands → the run handler checks the configuration path and resolves TypeScript settings → launch() constructs Launcher and calls run(); --watch instead enters Watcher.watch().
- Startup 2: Launcher.run → initialize/ConfigParser.initialize → runner plugin construction → launcher services → runner.initialize → user and service onPrepare hooks → driver/browser setup → _runMode/_runSpecs → _startInstance and runner.run.
- Startup 3: worker IPC dispatch invokes Runner.run → worker config import → stub session → worker services and beforeSession → reporters/framework discovery → real _initSession when tests exist → before hook → framework.run → endSession outside watch mode → snapshot IPC → _shutdown.
- Action 1: browser.$ delegates string selectors through globalThis.wdio in browser-runner mode; otherwise it calls findElement and getElement. Eligible BiDi string lookups use findDeepElement, while regular lookups dispatch findElement or findElementFromElement.
- Action 2: getElement installs elementErrorHandler(wrapCommand) → implicitWait waits and requeries missing elements except explicit waits/state checks and selected native scroll operations → middleware updates elementId → command executes; non-interactable and stale failures enter separate recovery branches.
- Action 3: click without options calls elementClick → POST /session/:sessionId/element/:elementId/click → request.makeRequest; intercepted clicks scroll to center and retry. Options instead build pointer move/down/pause/up actions and honor skipRelease.
- Persistence 1: browser.saveScreenshot → environment.value.saveScreenshot installed by node.ts → Node saveScreenshot checks filepath type → path.resolve → assertDirectoryExists → chooses takeScreenshotClassic or takeScreenshotBidi.
- Persistence 2: Classic validates PNG/no options and calls takeScreenshot; BiDi obtains context/tree, validates format/quality/clip, and uses an html element screenshot inside an iframe or browsingContextCaptureScreenshot otherwise. The returned base64 becomes a Buffer, fs.writeFile persists it, and the Buffer is returned.