Mocha test timeout configuration
The before() hook in Mocha can set a custom timeout using this.timeout(milliseconds). For Tauri WebDriver tests, a 120 second timeout is recommended to account for application build time.
Tauri · Develop · all subjects
debugging
95 notes in this subject, read out of this brain and free to use. This is page 2 of 2.
Selenium test example: CSS color value parsing
Selenium returns CSS color values as rgb(r, g, b) strings. These can be parsed with a regex pattern like /^rgb\((?<r>\d+), (?<g>\d+), (?<b>\d+)\)$/ to extract individual r, g, b values. For example, calculating luminance: 0.2126 * rgb.r + 0.7152 * rgb.g + 0.0722 * rgb.b.
Graceful shutdown of Selenium WebDriver and tauri-driver
A closeTauriDriver() function should call tauriDriver.kill() to terminate the tauri-driver process and await driver.quit() to close the WebDriver session. An exit flag should be used to distinguish intentional shutdown from unexpected process exit. Process signal handlers (exit, SIGINT, SIGTERM, SIGHUP, SIGBREAK) should call cleanup functions to ensure proper shutdown.
No Tauri application code modification needed for WebDriver tests
WebDriver testing with Selenium and tauri-driver can be performed without modifying the Tauri application code itself. The tests interact with the running application through the WebDriver protocol.
WebdriverIO config for Tauri testing
The wdio.conf.js configuration file controls the WebdriverIO test suite for Tauri. Key properties include: host set to '127.0.0.1', port set to 4444, specs pointing to test files (e.g., './develop/tests/specs/**/*.js'), maxInstances set to 1, capabilities including a 'tauri:options' object with an application path pointing to the built Tauri binary (e.g., '../src-tauri/target/debug/tauri-app'), reporters set to 'spec', framework set to 'mocha', and mochaOpts with ui set to 'bdd' and timeout set to 60000ms.
WebdriverIO onPrepare hook builds Tauri binary
The onPrepare hook in wdio.conf.js runs before test sessions start. It executes 'npm run tauri build -- --debug --no-bundle' from the parent directory to build the Tauri binary with spawnSync, inheriting stdio. This ensures the binary specified in capabilities exists before WebDriver sessions start.
WebdriverIO beforeSession spawns tauri-driver
The beforeSession hook spawns the tauri-driver process from ~/.cargo/bin/tauri-driver to proxy WebDriver requests. The spawned process writes to process.stdout and process.stderr, and error handlers ensure the test process exits if tauri-driver errors or exits unexpectedly.
WebdriverIO afterSession and shutdown cleanup
The afterSession hook calls closeTauriDriver() to clean up the spawned tauri-driver process. An onShutdown handler ensures tauri-driver is killed when the test process exits via process.on('exit'), 'SIGINT', 'SIGTERM', 'SIGHUP', or 'SIGBREAK' events.
WebdriverIO Tauri testing package.json
A minimal WebdriverIO Tauri testing setup uses package.json with: type set to 'module', a test script running 'wdio run wdio.conf.js', dependencies including '@wdio/cli' (^9.19.0), and devDependencies including '@wdio/local-runner', '@wdio/mocha-framework', and '@wdio/spec-reporter' (all ^9.19.0).
WebdriverIO test spec structure with Mocha
WebdriverIO specs use Mocha syntax with describe(), it(), and expect() functions. The spec has access to WebdriverIO APIs like $() for element selection, getText() to get element text, getCSSProperty() to read CSS properties, and expect() with matchers like toMatch() and toBeLessThan().
WebdriverIO Tauri service alternative to manual setup
The @wdio/tauri-service package automates WebdriverIO and tauri-driver setup, supporting macOS unlike manual configuration. Projects should prefer using @wdio/tauri-service instead of wiring WebdriverIO to tauri-driver by hand.
WebdriverIO example test for Tauri application
This example shows a test spec that validates a Tauri hello world application: it checks that a body > h1 header text matches /^[hH]ello/ (case-insensitive 'hello'), ends with '!' (matches /!$/), and has a dark background-color with luma value less than 100 for readability.
WebdriverIO test directory structure
Tests are organized in a dedicated e2e-tests directory. Test specifications are placed in test/specs/ with a .e2e.js suffix (e.g., test/specs/example.e2e.js). The wdio.conf.js file is at the root of the e2e-tests directory.
Windows WebDriver setup requires msedgedriver
To run WebDriver tests on Windows in CI, install Microsoft Edge Driver using msedgedriver-tool. The tool can be installed with 'cargo install --git https://github.com/chippers/msedgedriver-tool' and then run to download the matching driver version.
Linux WebDriver setup requires webkit2gtk-driver and xvfb
To run WebDriver tests on Linux in CI, install webkit2gtk-driver and xvfb as system dependencies. webkit2gtk-driver is needed for tauri-driver to run, and xvfb provides a fake X11 display server for headless testing.
GitHub Actions WebDriver CI workflow structure
A typical WebDriver CI workflow includes: checkout code, install system dependencies (with platform-specific handling), setup Rust toolchain and cache, run cargo tests first to validate the application builds, setup Node.js and install dependencies, install tauri-driver, then run WebdriverIO tests with platform-specific execution (xvfb-run on Linux, direct run on Windows).
tauri-driver is installed independently of Tauri versions
tauri-driver is a separate tool with its own versioning independent of the Tauri framework version. Install the latest version in CI with 'cargo install tauri-driver --locked'.
Run WebDriver tests on Linux with xvfb-run
On Linux CI systems, execute WebDriver tests through xvfb-run to provide a fake X11 display server, allowing the Tauri application to run headless without code changes. Example: 'xvfb-run yarn test'.
WebDriver tests can run on multiple CI platforms
GitHub Actions supports running WebDriver tests on both Linux (ubuntu-latest) and Windows (windows-latest) platforms. The workflow can use matrix strategies to test on multiple platforms simultaneously.
Run Rust unit tests before WebDriver tests in CI
Execute 'cargo test' before running WebDriver tests to validate that the application builds and runs correctly, avoiding the overhead of testing a broken application with WebDriver.
WebdriverIO Tauri minimal configuration
A minimal WebdriverIO configuration for Tauri testing requires setting the 'tauri' service with appBinaryPath pointing to your release binary and driverProvider set to 'embedded', 'external', or 'crabnebula'.
tauri-plugin-wdio-webdriver plugin
The tauri-plugin-wdio-webdriver plugin runs the embedded WebDriver server. It is required for the embedded driver provider (the default). It is optional and can be skipped if using external or crabnebula providers instead.
tauri-plugin-wdio plugin
The tauri-plugin-wdio plugin enables backend access including browser.tauri.execute(), command (IPC) mocking, and log capture. It is optional depending on testing requirements.
WebdriverIO browser mode for Tauri
Browser mode is available for fast, renderer-only tests and runs your Tauri frontend in plain Chrome against a Vite dev server without needing a Tauri binary, driver, or plugin. It intercepts invoke() calls allowing you to mock commands and assert on their arguments using the same WDIO API.
tauri-driver direct usage
tauri-driver can be driven directly without Node.js when preferring Selenium or integrating WebDriver into a custom test harness. Direct driving only supports Windows and Linux on desktop, as macOS has no WKWebView driver tool available. Use the service's embedded WebDriver server for macOS support.
WebDriver testing with Tauri
WebDriver is a standardized interface for automated testing of web documents. The recommended way to use WebDriver with Tauri is WebdriverIO with the @wdio/tauri-service, which works on Windows, Linux, and macOS. It provides Tauri API access through browser.tauri.execute(), command (IPC) mocking, frontend and backend log capture, and multiremote capabilities.
WebdriverIO Tauri service driver providers
The @wdio/tauri-service supports three driver providers: embedded (default, includes WebDriver server inside your app with no external driver needed on any platform and supports macOS), external (drives platform native WebDriver on Windows and Linux through tauri-driver), and crabnebula (cross-platform fork of tauri-driver requiring paid API key for macOS support).
Enable and access Web Inspector for Android applications
The Web Inspector is enabled by default for Android emulators. For physical devices, enable Developer Mode by going to Settings > About and tapping Build Number 7 times. Then enable USB Debugging in Developer Options settings. Access the Web Inspector by navigating to chrome://inspect in Chrome on your computer when your Android application is running.
Open Web Inspector in desktop app with keyboard shortcut
Right-click on the webview and click Inspect, or use the keyboard shortcut Ctrl + Shift + I on Windows and Linux, or Cmd + Option + I on macOS to open the Web Inspector for debugging.
Access Web Inspector for iOS applications
Safari must be used to access the Web Inspector for iOS applications. Open Safari, go to Safari > Settings in the menu bar, click Advanced, and select Show features for web developers. For physical devices, enable Web Inspector in Settings > Safari > Advanced on the device. After these steps, a Develop menu appears in Safari where you can select your device or simulator and click localhost to open Safari Developer Tools.
Use tauri-invoke-http to access Tauri APIs in browser DevTools
Tauri's APIs only work in the app window. If you need to use browser developer tooling instead, configure tauri-invoke-http to bridge Tauri API calls through an HTTP server.
Hotreload support for frontend static files in 1.2.0
Tauri 1.2.0 adds hotreload support for frontend static files.
Event loop crash fixed in Tauri 1.6.0
Tauri 1.6.0 fixes a long-standing event loop crash that occurred on all platforms. This crash was difficult to reproduce because it only happened when applications ran for extended periods.
iOS physical device development server binding
When running Tauri apps on a physical iOS device, the development server must bind to the TUN address provided by the device (ends with ::2) for connections to work. This connection is only possible when Xcode is opened and connected to the device. Use 'tauri ios dev --force-ip-prompt' to select the iOS device's TUN address. The IP address the frontend must listen to is provided by the TAURI_DEV_HOST environment variable.
Mobile development server network changes
In Tauri 2.0.0-rc, the development server network exposure changed to support connecting to localhost for both Android and iOS development. Previously this was only possible for desktop. The development server no longer needs to be exposed on the public network by default.