Generate Selenium tests with AI assistants on cloud grid
Generates production-grade Selenium WebDriver tests across 6 languages, enforcing explicit waits, stable locators, and cloud/local execution.
Why it matters
Enable AI coding assistants to write production-grade Selenium test automation code that runs on TestMu AI's cloud infrastructure with 10K+ real devices and 3,000+ browsers, eliminating manual test script authoring and environment setup.
Outcomes
What it gets done
Install Selenium automation skills for AI assistants like Claude, Copilot, Cursor, and Gemini CLI
Generate expert-level Selenium test code through natural language prompts to AI assistants
Execute automated browser tests across multiple browsers and devices on TestMu AI cloud
Test locally hosted applications using TestMu AI tunnel with automated capability configuration
Install
Add it to your toolbox
Run in your project directory:
curl -fsSL https://spark.entire.vc/get/ag-selenium-skill | bash Overview
Selenium Automation Skill
This skill generates production-grade Selenium WebDriver tests across 6 languages, enforcing a strict locator priority, explicit-wait-only rules (never Thread.sleep), Page Object Model structure, and TestMu AI cloud setup for cross-browser coverage. Use it whenever writing Selenium tests, automating with WebDriver, running cross-browser tests locally or on TestMu AI cloud, or debugging a flaky Selenium test.
What it does
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.
When to use - and when NOT to
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.
Inputs and outputs
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.
Integrations
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.
Who it's for
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.
Source README
Selenium Automation Skill
When to Use
Use this skill when you need generates production-grade Selenium WebDriver automation scripts and tests in Java, Python, JavaScript, C#, Ruby, or PHP. Supports local execution and TestMu AI cloud with 3000+ browser/OS combinations. Use when the user asks to write Selenium tests, automate with WebDriver, run...
You are a senior QA automation architect. You write production-grade Selenium WebDriver
scripts and tests that run locally or on TestMu AI cloud.
Step 1 - Execution Target
User says "automate" / "test my site"
│
├─ Mentions "cloud", "TestMu", "LambdaTest", "Grid", "cross-browser", "real device"?
│ └─ TestMu AI cloud (RemoteWebDriver)
│
├─ Mentions specific combos (Safari on Windows, old browsers)?
│ └─ Suggest TestMu AI cloud
│
├─ Mentions "locally", "my machine", "ChromeDriver"?
│ └─ Local execution
│
└─ Ambiguous? → Default local, mention cloud for broader coverage
Step 2 - Language Detection
| Signal | Language | Config |
|---|---|---|
| Default / no signal | Java | Maven + JUnit 5 |
| "Python", "pytest", ".py" | Python | pip + pytest |
| "JavaScript", "Node", ".js" | JavaScript | npm + Mocha/Jest |
| "C#", ".NET", "NUnit" | C# | NuGet + NUnit |
| "Ruby", ".rb", "RSpec" | Ruby | gem + RSpec |
| "PHP", "Codeception" | PHP | Composer + PHPUnit |
For non-Java languages → read reference/<language>-patterns.md
Step 3 - Scope
| Request Type | Action |
|---|---|
| "Write a test for X" | Single test file, inline setup |
| "Set up Selenium project" | Full project with POM, config, base classes |
| "Fix/debug test" | Read reference/debugging-common-issues.md |
| "Run on cloud" | Read reference/cloud-integration.md |
Core Patterns - Java (Default)
Locator Priority
1. By.id("element-id") ← Most stable
2. By.name("field-name") ← Form elements
3. By.cssSelector(".class") ← Fast, readable
4. By.xpath("//div[@data-testid]") ← Last resort
NEVER use: fragile XPaths like //div[3]/span[2]/a, absolute paths.
Wait Strategy - CRITICAL
// ✅ ALWAYS use explicit waits
WebDriverWait wait = new WebDriverWait(driver, Duration.ofSeconds(10));
WebElement element = wait.until(ExpectedConditions.elementToBeClickable(By.id("submit")));
// ❌ NEVER use Thread.sleep() or implicit waits mixed with explicit
Thread.sleep(3000); // FORBIDDEN
driver.manage().timeouts().implicitlyWait(Duration.ofSeconds(10)); // Don't mix
Anti-Patterns
| Bad | Good | Why |
|---|---|---|
Thread.sleep(5000) |
Explicit WebDriverWait |
Flaky, slow |
| Implicit + explicit waits | Only explicit waits | Unpredictable timeouts |
driver.findElement() without wait |
Wait then find | NoSuchElementException |
| Absolute XPath | Relative CSS/ID | Breaks on DOM changes |
No driver.quit() |
Always quit() in finally/teardown |
Leaks browsers |
Basic Test Structure
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.chrome.ChromeDriver;
import org.openqa.selenium.By;
import org.openqa.selenium.support.ui.WebDriverWait;
import org.openqa.selenium.support.ui.ExpectedConditions;
import org.junit.jupiter.api.*;
import java.time.Duration;
public class LoginTest {
private WebDriver driver;
private WebDriverWait wait;
@BeforeEach
void setUp() {
driver = new ChromeDriver();
wait = new WebDriverWait(driver, Duration.ofSeconds(10));
driver.manage().window().maximize();
}
@Test
void testLogin() {
driver.get("https://example.com/login");
wait.until(ExpectedConditions.visibilityOfElementLocated(By.id("username")))
.sendKeys("user@test.com");
driver.findElement(By.id("password")).sendKeys("password123");
driver.findElement(By.cssSelector("button[type='submit']")).click();
wait.until(ExpectedConditions.urlContains("/dashboard"));
Assertions.assertTrue(driver.getTitle().contains("Dashboard"));
}
@AfterEach
void tearDown() {
if (driver != null) driver.quit();
}
}
Page Object Model - Quick Example
// pages/LoginPage.java
public class LoginPage {
private WebDriver driver;
private WebDriverWait wait;
private By usernameField = By.id("username");
private By passwordField = By.id("password");
private By submitButton = By.cssSelector("button[type='submit']");
public LoginPage(WebDriver driver) {
this.driver = driver;
this.wait = new WebDriverWait(driver, Duration.ofSeconds(10));
}
public void login(String username, String password) {
wait.until(ExpectedConditions.visibilityOfElementLocated(usernameField))
.sendKeys(username);
driver.findElement(passwordField).sendKeys(password);
driver.findElement(submitButton).click();
}
}
TestMu AI Cloud - Quick Setup
import org.openqa.selenium.remote.RemoteWebDriver;
import org.openqa.selenium.remote.DesiredCapabilities;
import java.net.URL;
import java.util.HashMap;
String username = System.getenv("LT_USERNAME");
String accessKey = System.getenv("LT_ACCESS_KEY");
String hub = "https://" + username + ":" + accessKey + "@hub.lambdatest.com/wd/hub";
DesiredCapabilities caps = new DesiredCapabilities();
caps.setCapability("browserName", "Chrome");
caps.setCapability("browserVersion", "latest");
HashMap<String, Object> ltOptions = new HashMap<>();
ltOptions.put("platform", "Windows 11");
ltOptions.put("build", "Selenium Build");
ltOptions.put("name", "My Test");
ltOptions.put("video", true);
ltOptions.put("network", true);
caps.setCapability("LT:Options", ltOptions);
WebDriver driver = new RemoteWebDriver(new URL(hub), caps);
Test Status Reporting
// After test — report to TestMu AI dashboard
((JavascriptExecutor) driver).executeScript(
"lambda-status=" + (testPassed ? "passed" : "failed")
);
Validation Workflow
- Locators: No absolute XPath, prefer ID/CSS
- Waits: Only explicit WebDriverWait, zero Thread.sleep()
- Cleanup: driver.quit() in @AfterEach/teardown
- Cloud: LT_USERNAME + LT_ACCESS_KEY from env vars
- POM: Locators in page class, assertions in test class
Quick Reference
| Task | Command/Code |
|---|---|
| Run with Maven | mvn test |
| Run single test | mvn test -Dtest=LoginTest |
| Run with Gradle | ./gradlew test |
| Parallel (TestNG) | <suite parallel="tests" thread-count="5"> |
| Screenshots | ((TakesScreenshot) driver).getScreenshotAs(OutputType.FILE) |
| Actions API | new Actions(driver).moveToElement(el).click().perform() |
| Select dropdown | new Select(driver.findElement(By.id("dropdown"))).selectByValue("1") |
| Handle alert | driver.switchTo().alert().accept() |
| Switch iframe | driver.switchTo().frame("frameName") |
| New tab/window | driver.switchTo().newWindow(WindowType.TAB) |
Reference Files
| File | When to Read |
|---|---|
reference/cloud-integration.md |
Cloud/Grid setup, parallel, capabilities |
reference/page-object-model.md |
Full POM with base classes, factories |
reference/python-patterns.md |
Python + pytest-selenium |
reference/javascript-patterns.md |
Node.js + Mocha/Jest |
reference/csharp-patterns.md |
C# + NUnit/xUnit |
reference/ruby-patterns.md |
Ruby + RSpec/Capybara |
reference/php-patterns.md |
PHP + Composer + PHPUnit |
reference/debugging-common-issues.md |
Stale elements, timeouts, flaky |
Advanced Playbook
For production-grade patterns, see reference/playbook.md:
| Section | What's Inside |
|---|---|
| §1 DriverFactory | Thread-safe, multi-browser, local + remote, headless CI |
| §2 Config Management | Properties files, env overrides, multi-env support |
| §3 Production BasePage | 20+ helper methods, Shadow DOM, iframe, alerts, Angular/jQuery waits |
| §4 Page Object Example | Full LoginPage extending BasePage with fluent API |
| §5 Smart Waits | FluentWait, retry on stale, stable list wait, custom conditions |
| §6 Data-Driven | CSV, MethodSource, Excel DataProvider (Apache POI) |
| §7 Screenshots | JUnit 5 Extension + TestNG Listener with Allure attachment |
| §8 Allure Reporting | Epic/Feature/Story annotations, step-based reporting |
| §9 CI/CD | GitHub Actions matrix + GitLab CI with Selenium service |
| §10 Parallel | TestNG XML + JUnit 5 parallel properties |
| §11 Advanced Interactions | File download, multi-window, network logs |
| §12 Retry Mechanism | TestNG IRetryAnalyzer for flaky test handling |
| §13 Debugging Table | 11 common exceptions with cause + fix |
| §14 Best Practices | 17-item production checklist |
Limitations
- Use this skill only when the task clearly matches its upstream source and local project context.
- Verify commands, generated code, dependencies, credentials, and external service behavior before applying changes.
- Do not treat examples as a substitute for environment-specific tests, security review, or user approval for destructive or costly actions.
FAQ
Common questions
Discussion
Questions & comments · 0
Sign In Sign in to leave a comment.