Skill

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.

Works with seleniumplaywrightcypressgithubcopilot

35
Spark score
out of 100
Updated last month
Version 1.0.0

Add to Favorites

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

01

Install Selenium automation skills for AI assistants like Claude, Copilot, Cursor, and Gemini CLI

02

Generate expert-level Selenium test code through natural language prompts to AI assistants

03

Execute automated browser tests across multiple browsers and devices on TestMu AI cloud

04

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

  1. Locators: No absolute XPath, prefer ID/CSS
  2. Waits: Only explicit WebDriverWait, zero Thread.sleep()
  3. Cleanup: driver.quit() in @AfterEach/teardown
  4. Cloud: LT_USERNAME + LT_ACCESS_KEY from env vars
  5. 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.