Testland
Browse all skills & agents

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-automate
View source

lambdatest-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

  • Cross-browser regression with LambdaTest as the chosen grid.
  • Visual regression via LambdaTest's SmartUI (alternative to Percy / Chromatic in qa-visual-regression).
  • Internal-network apps via LambdaTest Tunnel.
  • Cost-comparison against BrowserStack / Sauce.

How to use

  1. Export LT_USERNAME + LT_ACCESS_KEY.
  2. Point the WebDriver client at the hub URL https://hub.lambdatest.com/wd/hub.
  3. Set vendor caps in an LT:Options dict on the Options object before creating the driver (build, name, project), then run one suite end to end - see Worked example.
  4. Report each session's pass / fail with the lambda-status JS-executor before driver.quit().
  5. For internal apps, run LambdaTest Tunnel (below). For the full CI matrix workflow, the exhaustive LT:Options table, SmartUI visual regression, and REST session retrieval, see references/ci-and-capabilities.md.

Authentication

export LT_USERNAME="your-username"
export LT_ACCESS_KEY="<access-key>"

Hub URL

https://hub.lambdatest.com/wd/hub

Capabilities (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-patternWhy it failsFix
Confusing tunnel (boolean) with tunnelName (string)Tunnel won't activateSet both when using tunnel
Missing project fieldDashboard organisation suffersAlways set project
Default w3c: false (old mode)W3C parity issues; future versions remove non-W3CAlways set w3c: true (default)
Polling for tunnel ready without timeoutTest suite hangsBounded wait
Hardcoded LambdaTest URL in testsSwitching grids requires code changesAbstract via env-var-driven config
SmartUI baseline never approvedFalse positives flood reportsApprove initial baseline; audit changes
Treating LambdaTest as drop-in replacement for BrowserStackCaps shape differs (LT:Options vs bstack:options)Use a small abstraction layer in test harness

Limitations

  • Smaller real-device matrix than BrowserStack. Device coverage improving but still less broad.
  • Visual UI testing is paid add-on. SmartUI requires additional licensing.
  • Less mature documentation. Some edge cases (specific browser versions, mobile-real-device-only features) have thinner docs than competitors.
  • Pricing model differs. Per-parallel-session vs per-minute; cost analysis depends on workload shape.

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:

OptionPurpose
user / accessKeyCredentials (alternative to env vars)
buildCI build / PR identifier
nameSession label
projectGroup sessions by project (dashboard)
selenium_versionPin Selenium version
w3cEnable W3C mode (default true)
consoleConsole-log level: "errors" / "warnings" / "info" / "verbose"
networkCapture HAR file
videoSession recording
visualPer-step screenshots
tunnel / tunnelNameLambdaTest Tunnel for internal apps
smartUI.projectLink 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:

  • Session video (video: true)
  • Network HAR (network: true)
  • Browser console logs (console: "verbose")
  • Per-step screenshots (visual: true)
  • SmartUI diffs (if SmartUI configured)

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/ --lambdatest

Match 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.