lambdatest-automate
Author and run E2E tests on LambdaTest - cloud grid for cross-browser + real-device testing with W3C WebDriver, Cypress, Playwright, and Appium support. Covers LT_USERNAME + LT_ACCESS_KEY auth, hub URL hub.lambdatest.com/wd/hub, W3C capabilities + LT:Options dict (build, name, project, smartUI, network, console, video, tunnel), LambdaTest Tunnel for internal apps. Use for cross-browser regression with LambdaTest as the cloud grid; complements BrowserStack + Sauce Labs.
Install with skills.sh (any agent)
npx skills add testland/qa --skill lambdatest-automatelambdatest-automate
Overview
LambdaTest is a newer cloud-grid provider with strong real-device coverage + Visual UI testing add-ons. Like BrowserStack + Sauce Labs, it exposes a W3C-compliant endpoint.
Per lambdatest.com/support/docs/getting-started-with-lambdatest-automation (opens in new window) (Cloudflare-protected; cite by stable URL).
Composes with browser-matrix-strategy-reference (in the qa-compatibility plugin).
When to use
How to use
Authentication
export LT_USERNAME="your-username"
export LT_ACCESS_KEY="<access-key>"Hub URL
https://hub.lambdatest.com/wd/hubCapabilities (W3C)
Standard W3C fields plus an LT:Options block for LambdaTest-specific settings:
{
"browserName": "Chrome",
"browserVersion": "latest",
"platformName": "Windows 11",
"LT:Options": {
"user": "$LT_USERNAME",
"accessKey": "$LT_ACCESS_KEY",
"build": "PR-1234",
"name": "Login flow on Chrome Windows",
"project": "my-app"
}
}The exhaustive LT:Options table (console, network, video, visual, tunnel / tunnelName, smartUI.project, ...) is in references/ci-and-capabilities.md.
Worked example
Run one suite on the grid end to end - set vendor caps on the Options object, create the remote driver, drive the test, report status, quit:
import os
from selenium import webdriver
options = webdriver.EdgeOptions()
options.browser_version = "latest"
options.platform_name = "Windows 11"
lt_options = {
"user": os.environ["LT_USERNAME"],
"accessKey": os.environ["LT_ACCESS_KEY"],
"build": os.environ.get("BUILD_TAG", "local"),
"name": "Checkout on Edge",
"project": "my-app",
"console": "errors",
"network": True,
"video": True,
}
# Set vendor caps on the Options object BEFORE creating the driver. In
# Selenium 4 W3C mode driver.capabilities is a read-only result dict, so
# assigning to it after Remote() is a no-op and LT:Options never applies
# (per the [Selenium options] docs).
options.set_capability("LT:Options", lt_options)
driver = webdriver.Remote(
command_executor="https://hub.lambdatest.com/wd/hub",
options=options,
)
driver.get("https://example.com")
# test...
# report pass / fail; LambdaTest's JS-executor pattern is "lambda-<command>=..."
failed = False
driver.execute_script("lambda-status=" + ("failed" if failed else "passed"))
driver.quit()LambdaTest Tunnel
For internal-network apps, start the tunnel, then set LT:Options.tunnel: true and tunnelName: "my-tunnel":
# Download from lambdatest.com/support/docs/lambda-tunnel
./LT --user $LT_USERNAME --key $LT_ACCESS_KEY --tunnelName "my-tunnel"Anti-patterns
| Anti-pattern | Why it fails | Fix |
|---|---|---|
Confusing tunnel (boolean) with tunnelName (string) | Tunnel won't activate | Set both when using tunnel |
Missing project field | Dashboard organisation suffers | Always set project |
Default w3c: false (old mode) | W3C parity issues; future versions remove non-W3C | Always set w3c: true (default) |
| Polling for tunnel ready without timeout | Test suite hangs | Bounded wait |
| Hardcoded LambdaTest URL in tests | Switching grids requires code changes | Abstract via env-var-driven config |
| SmartUI baseline never approved | False positives flood reports | Approve initial baseline; audit changes |
| Treating LambdaTest as drop-in replacement for BrowserStack | Caps shape differs (LT:Options vs bstack:options) | Use a small abstraction layer in test harness |
Limitations
References
LambdaTest Automate CI, full capabilities, and SmartUI
View source (opens in new window)LambdaTest Automate CI, full capabilities, and SmartUI
Deep reference for lambdatest-automate SKILL.md. Consult when wiring LambdaTest into CI, tuning the full LT:Options capability set, wiring SmartUI visual regression, or pulling session artifacts via REST.
Full LT:Options table
LT:Options carries LambdaTest-specific settings:
| Option | Purpose |
|---|---|
user / accessKey | Credentials (alternative to env vars) |
build | CI build / PR identifier |
name | Session label |
project | Group sessions by project (dashboard) |
selenium_version | Pin Selenium version |
w3c | Enable W3C mode (default true) |
console | Console-log level: "errors" / "warnings" / "info" / "verbose" |
network | Capture HAR file |
video | Session recording |
visual | Per-step screenshots |
tunnel / tunnelName | LambdaTest Tunnel for internal apps |
smartUI.project | Link to SmartUI visual-regression project |
SmartUI integration
LambdaTest SmartUI handles visual regression alongside the functional test:
driver.execute_script("smartui.takeScreenshot=login-page")Smart screenshots compare against a baseline; differences flagged in the SmartUI dashboard. See qa-visual-regression for visual-regression discipline.
Parsing results
LambdaTest session reports:
REST API:
curl -u "$LT_USERNAME:$LT_ACCESS_KEY" \
"https://api.lambdatest.com/automation/api/v1/sessions/<session-id>"CI integration
on: pull_request
jobs:
lambdatest:
runs-on: ubuntu-latest
strategy:
matrix:
browser:
- { name: Chrome, version: latest, platform: "Windows 11" }
- { name: Firefox, version: latest, platform: "Windows 11" }
- { name: Safari, version: "17", platform: "macOS Sonoma" }
steps:
- uses: actions/checkout@v6
- name: Run on LambdaTest
env:
LT_USERNAME: ${{ secrets.LT_USERNAME }}
LT_ACCESS_KEY: ${{ secrets.LT_ACCESS_KEY }}
LT_BROWSER: ${{ matrix.browser.name }}
LT_VERSION: ${{ matrix.browser.version }}
LT_PLATFORM: ${{ matrix.browser.platform }}
BUILD_TAG: pr-${{ github.event.pull_request.number }}
run: pytest tests/e2e/ --lambdatestMatch the matrix breadth to a tiered plan - see browser-matrix-strategy-reference for tiering guidance.
Related skills
browserstack-automate
Author and run E2E tests on BrowserStack Automate - cloud grid covering 3000+ real device + browser combinations. Covers BROWSERSTACK_USERNAME + ACCESS_KEY auth, hub URL https://hub-cloud.browserstack.com/wd/hub, W3C capabilities + bstack:options (projectName, buildName, sessionName), BrowserStackLocal for testing against localhost / internal environments, parallel session limits, and CI integration. Use for cross-browser regression on real devices + browsers - distinct from running a single test framework locally, and from a matrix runner limited to the browser engines bundled on the local machine.
cypress-testing
Authors and improves Cypress E2E tests - installs Cypress, configures `cypress.config.ts`, authors `cy.*` command chains, refactors existing specs (`cy.wait(ms)` sleeps into assertions, repeated flows into `cy.session` custom commands), and debugs with the time-travel GUI; Cypress Cloud for parallel runs and recording. Use for both greenfield test authoring and improving hand-written specs already in the codebase. For automated refactor of raw Cypress Studio recordings specifically, use a dedicated codegen-review pass.
playwright-testing
Authors and remediates Playwright E2E tests across Chromium, Firefox, WebKit - `npm init playwright@latest` scaffolding, `playwright.config.ts` browser projects, accessibility-first locators (`getByRole`/`getByLabelText`) to replace brittle CSS selectors, web-first assertions to eliminate `waitForTimeout` flakiness, Page Object pattern, trace viewer debugging, sharded parallel execution with merged HTML reporting, and GitHub Actions CI integration. Use for new test authoring, flakiness remediation, and CI setup; for reviewing codegen output specifically, use a dedicated codegen-review pass.
puppeteer-testing
Authors browser automation scripts using Puppeteer - Chrome / Chromium-only headless / headed automation, Page object via `page.*` API, network interception, PDF generation, screenshot capture, scraping. Distinct from Playwright (Puppeteer's older sibling, Chrome-only) - use Puppeteer for Chrome-only browser automation tasks (scraping, generating PDFs from HTML, screenshot pipelines) where Playwright's multi-browser support is unneeded overhead. Use when a project already depends on `puppeteer` / `puppeteer-core`, or when a Chrome-only script must emit PDFs, screenshots, or scraped data rather than assert on a page.
saucelabs-automate
Author and run E2E tests on Sauce Labs - cloud grid for cross-browser + real-device testing with W3C WebDriver, Cypress, Playwright, and Appium support. Covers SAUCE_USERNAME + SAUCE_ACCESS_KEY auth, regional hub URLs (us-west-1 / us-east-4 / eu-central-1), W3C capabilities, sauce:options dict (build, name, screenResolution, tunnelName), Sauce Connect Proxy for internal-environment testing. Use for cross-browser regression with Sauce Labs as the cloud grid; complements BrowserStack + LambdaTest as alternative providers.
selenium-testing
Authors Selenium WebDriver tests in any of its 6+ supported languages (Java, Python, JavaScript, C#, Ruby, Kotlin, PHP) - picks the appropriate language binding, configures WebDriver per browser, uses `By.*` locators with the team's accessibility-first preference where supported, runs locally + via Selenium Grid for distributed execution, parses results to JUnit XML. Use for legacy Selenium-locked stacks; new projects pick Playwright or Cypress.
testcafe-testing
Authors TestCafe E2E tests - `npm install testcafe`, fixture/test syntax, `Selector` API for queries, automatic-waits, no WebDriver required (TestCafe injects scripts via a proxy), supports any browser including remote / cloud farms. Use when the team prefers a no-WebDriver architecture and one of TestCafe's specific features (e.g., role-based auth) matters.
web-e2e-overview
Teaches web end-to-end testing from first principles: what browser-driven E2E covers and how it differs from unit and integration tests, a decision table for choosing between Playwright, Cypress, Selenium WebDriver, WebdriverIO, Puppeteer, TestCafe and the BrowserStack / Sauce Labs / LambdaTest cloud grids based on files already present in the repo, install and first-run commands for each, and the flakiness traps (fixed sleeps, CSS and XPath selectors, state shared between tests) that sink new suites. Use when a web application has no E2E coverage yet, when picking or replacing an E2E framework, or when a first browser test needs to go green end to end.
webdriverio-testing
Authors WebdriverIO E2E tests - `npm init wdio@latest` scaffolding, services architecture (sauce, browserstack, appium, devtools), reporters (spec, allure, junit), built-in Mocha/Jasmine/Cucumber framework integrations. WebdriverIO sits between Selenium (W3C protocol) and Playwright (modern API) - Selenium-protocol-compatible with rich plugin ecosystem. Use when the team needs WebDriver protocol + service-based device-farm integration.