Workflow:Webdriverio Webdriverio Standalone Browser Automation
| Knowledge Sources | |
|---|---|
| Domains | Browser_Automation, Testing, Node_JS |
| Last Updated | 2026-02-12 01:30 GMT |
Overview
End-to-end process for programmatically controlling a browser session using the WebdriverIO standalone API without a test runner framework.
Description
This workflow demonstrates how to use WebdriverIO's remote() function to create and control browser sessions directly from a Node.js script. Unlike the WDIO testrunner approach, standalone mode gives full programmatic control without any test framework overhead. It is the lowest-level way to interact with the WebdriverIO API: you import the library, create a session, run commands sequentially, and clean up. This approach is ideal for scripts, one-off automation tasks, web scraping, or embedding browser automation into larger applications.
Usage
Execute this workflow when you need to automate a browser without a test framework, such as for scripting, data extraction, screenshot capture, or integrating browser automation into a custom application pipeline. This is the right choice when you do not need test assertions, suite organization, or parallel execution provided by the full testrunner.
Execution Steps
Step 1: Install Dependencies
Set up a Node.js project and install the webdriverio package as a dependency. This package provides the remote() function and all browser command bindings. Optionally install a browser driver if not using automatic driver management.
Key considerations:
- WebdriverIO v9+ requires Node.js 18 or later
- The package handles driver management automatically by default
- No test framework packages are needed for standalone mode
Step 2: Create Browser Session
Import the remote function from the webdriverio package and call it with a capabilities configuration object. The capabilities specify which browser to launch, headless mode preferences, and connection options. The function returns a browser instance that exposes all WebDriver commands.
Key considerations:
- Capabilities follow the W3C WebDriver standard format
- Browser-specific options use vendor prefixes (e.g., goog:chromeOptions)
- The remote() call initializes the WebDriver session and returns a chainable client object
Use the browser instance to navigate to URLs, find elements, interact with them (click, type, select), and read page content. Commands are async and return promises. Element selection uses CSS selectors, XPath, or WebdriverIO-specific strategies via $() and $$() shorthand methods.
Key considerations:
- All browser commands are asynchronous and must be awaited
- Use $() to find a single element and $$() for multiple elements
- Commands can be chained: await browser.$('selector').click()
- Element interactions include click(), setValue(), getText(), getAttribute()
Step 4: Handle Errors
Wrap browser interactions in try-catch blocks to handle failures gracefully. WebDriver commands throw errors when elements are not found, sessions time out, or unexpected browser states occur. Proper error handling ensures sessions are always cleaned up.
Key considerations:
- Always use try-catch-finally to guarantee cleanup
- WebDriver errors include element not found, stale element, and timeout errors
- The finally block should always call deleteSession()
Step 5: Clean Up Session
Terminate the browser session by calling deleteSession() on the browser instance. This closes the browser, stops the driver process, and frees resources. Failure to clean up leads to orphaned browser processes.
Key considerations:
- Always call deleteSession() in a finally block
- This stops the underlying browser driver process
- Resources are freed automatically after session deletion