Generate Selenium tests with AI assistants on cloud grid

Generates production-grade Selenium WebDriver automation scripts and tests across six languages - Java (default, Maven + JUnit 5), Python (pip + pytest), JavaScript (npm + Mocha/Jest), C# (NuGet + NUnit), Ruby (gem + RSpec), and PHP (Composer + PHPUnit) - detected from language signals in the request, reading the matching reference/<language>-patterns.md for non-Java targets. It first decides the execution target: local (ChromeDriver, "my machine") by default, or TestMu AI cloud via RemoteWebDriver when the user mentions cloud, TestMu, LambdaTest, Grid, cross-browser, real devices, or specific browser/OS combinations like Safari on Windows - defaulting to local but mentioning cloud for broader coverage when ambiguous. Request scope is also routed: a single test gets an inline test file, "set up Selenium project" gets a full project with Page Object Model, config, and base classes, debugging requests read a dedicated debugging reference, and cloud requests read a dedicated cloud-integration reference. Core Java patterns enforce a strict locator priority - By.id first as most stable, then By.name for form elements, then By.cssSelector, with By.xpath only as a last resort, and fragile absolute XPaths like //div[3]/span[2]/a explicitly forbidden - and a critical wait rule: only explicit WebDriverWait with ExpectedConditions, never Thread.sleep(), and never mixing implicit waits with explicit ones since that produces unpredictable timeouts.

WebDriverWait wait = new WebDriverWait(driver, Duration.ofSeconds(10));
WebElement element = wait.until(ExpectedConditions.elementToBeClickable(By.id("submit")));

never this:

Thread.sleep(3000);
driver.manage().timeouts().implicitlyWait(Duration.ofSeconds(10));

A five-item anti-pattern table pairs each bad practice with its fix and reason: Thread.sleep versus explicit WebDriverWait (flaky, slow), mixed wait strategies versus explicit-only (unpredictable timeouts), findElement without a prior wait versus wait-then-find (avoids NoSuchElementException), absolute XPath versus relative CSS/ID (breaks on DOM changes), and missing driver.quit() versus always quitting in teardown (leaks browser processes). A basic JUnit 5 test structure sets up the driver in @BeforeEach, always tears it down in @AfterEach, and asserts against explicit waits rather than static delays; a Page Object Model example separates locators and interaction methods into a page class from assertions in the test class. TestMu AI cloud setup builds the remote hub URL from LT_USERNAME/LT_ACCESS_KEY environment variables, sets browser/platform capabilities plus build/name/video/network flags under LT:Options, and reports pass/fail status back to the dashboard via a lambda-status JavaScript execution. A five-point validation workflow checks locators (no absolute XPath), waits (explicit only, zero Thread.sleep), cleanup (driver.quit() in teardown), cloud credentials (from env vars, never hardcoded), and POM structure (locators in the page class, assertions in the test class). A quick-reference table covers running tests with Maven/Gradle, parallel execution via TestNG, screenshots, the Actions API, dropdown selection, alert handling, iframe switching, and new-window/tab handling. Eight reference files cover cloud/Grid setup, the full Page Object Model with base classes and factories, each non-Java language's patterns, and common debugging issues (stale elements, timeouts, flakiness). A 14-section advanced playbook covers thread-safe multi-browser driver factories, config management across environments, a production BasePage with 20+ helper methods (Shadow DOM, iframes, Angular/jQuery-aware waits), smart wait strategies (FluentWait, stale-element retry), data-driven testing via CSV/Excel, screenshot capture on failure, Allure reporting, CI/CD matrix setup, parallel execution config, advanced interactions (file download, multi-window, network logs), a flaky-test retry mechanism, an 11-exception debugging table, and a 17-item production checklist.

Use it whenever a user asks to write Selenium tests, automate with WebDriver, run cross-browser tests locally or on TestMu AI cloud (3000+ browser/OS combinations), or debug a flaky Selenium test.

Input is a UI flow to test (or an existing flaky test to debug) plus the target language and execution environment (local or cloud). Output is a WebDriver test file (or full project with Page Object Model) using explicit waits and stable locators, plus cloud capability config when targeting TestMu AI.

Generates code for Selenium WebDriver in six languages with their standard test frameworks (JUnit 5, pytest, Mocha/Jest, NUnit, RSpec, PHPUnit), and integrates with TestMu AI's RemoteWebDriver cloud grid via LT_USERNAME/LT_ACCESS_KEY credentials.

QA engineers and developers writing Selenium browser automation who want production-grade, non-flaky tests (explicit waits, stable locators, proper cleanup) across any of six languages, locally or on a cross-browser cloud grid.