Write WebdriverIO tests with AI coding assistants

Generates WebdriverIO (WDIO) browser automation tests in JavaScript or TypeScript, targeting either a local Selenium/DevTools setup or TestMu AI's cloud grid (LambdaTest service), and picking a test runner based on cues in the request - Mocha by default, Jasmine or Cucumber/BDD when explicitly mentioned.

describe('Login', () => {
    it('should login successfully', async () => {
        await browser.url('/login');
        await $('[data-testid="email"]').setValue('user@test.com');
        await $('[data-testid="password"]').setValue('password123');
        await $('[data-testid="submit"]').click();
        await expect(browser).toHaveUrl(expect.stringContaining('/dashboard'));
    });
});

Core selector patterns favor data-testid attributes ($('[data-testid="submit"]')), accessibility selectors ($('aria/Submit')), and text-based selectors ($('button=Submit')), with chaining ($('form').$('input[name="email"]')) and multi-element queries ($$('.list-item')). Page objects are generated as classes with getter-based element accessors and action methods, exported as a singleton instance. For TestMu AI cloud runs, a wdio.conf.js is generated with LT_USERNAME/LT_ACCESS_KEY env vars, the LambdaTest hub hostname, the lambdatest service, and capabilities including platform, build/test name, and video/network capture. Wait strategies cover explicit element waits (waitForDisplayed({ timeout })) and condition polling (browser.waitUntil with a timeout and message).

A quick-reference command table covers setup (npm init wdio@latest), running all or specific specs/suites (npx wdio run wdio.conf.js --spec ... / --suite ...), parallel execution (maxInstances in config), and screenshots (browser.saveScreenshot). Two reference files extend the core skill on demand: reference/cloud-integration.md (LambdaTest service, parallel runs, capabilities) and reference/advanced-patterns.md (custom commands, reporters, services). A deeper reference/playbook.md covers thirteen additional sections: production multi-env/multi-browser configuration, the full Page Object Model (BasePage/LoginPage/DashboardPage), custom browser and element commands in TypeScript, network mocking (DevTools mock/abort/error simulation), file operations (upload/download/drag-and-drop), multi-tab/iframe/shadow-DOM handling, visual regression via image comparison, API testing (fetch-based and combined API+UI), mobile testing via the Appium service, LambdaTest cloud-grid integration, CI/CD integration (GitHub Actions, Docker Compose), an 11-item debugging quick-reference, and a 14-item best-practices checklist.

Use it whenever WebdriverIO, WDIO, wdio.conf, or WDIO-style selectors (browser.url, $, $$) are mentioned and browser automation tests need generating - local or against TestMu AI's cloud grid. It's scoped specifically to WebdriverIO conventions, not other automation frameworks like Playwright or Cypress.

Input is a description of the browser flow to test, plus optional signals for execution target (local/cloud) and test framework (Mocha/Jasmine/Cucumber). Output is WebdriverIO test code (spec files, page objects, or config), pointing to deeper reference files for advanced patterns as needed.

Built on WebdriverIO with TestMu AI/LambdaTest cloud-grid integration for cross-browser execution, and referenced integrations spanning Appium (mobile), GitHub Actions/Docker Compose (CI/CD), and visual-regression/network-mocking services.

Teams already committed to WebdriverIO over Playwright or Cypress - especially ones running on TestMu AI's cloud grid - who want the AI to reach for the project's actual conventions (data-testid selectors, the established page-object shape, the right reference file for an advanced pattern) instead of generating generic Selenium-style code that has to be rewritten to fit.