Catch visual regressions with cross-browser screenshots
Generates framework-agnostic SmartUI visual regression configs for Playwright, Selenium, Cypress, or Puppeteer on TestMu AI cloud.
Why it matters
Automate visual regression testing by capturing and comparing screenshots across multiple browsers and viewports on the LambdaTest SmartUI cloud platform, ensuring UI consistency and catching visual bugs before production.
Outcomes
What it gets done
Generate SmartUI configuration files with browser and viewport matrices
Integrate screenshot capture into Playwright, Selenium, Cypress, or Puppeteer tests
Execute visual tests via CLI and compare against baseline screenshots
Review visual differences in the SmartUI dashboard and approve new baselines
Install
Add it to your toolbox
Run in your project directory:
curl -fsSL https://spark.entire.vc/get/ag-smartui-skill | bash Overview
SmartUI Visual Regression Skill
This skill generates framework-agnostic SmartUI visual regression configs (Playwright, Selenium, Cypress, Puppeteer) for screenshot comparison, covering CLI setup, browser/viewport config, Storybook integration, and the baseline-approval dashboard workflow. Use it whenever visual regression, screenshot comparison, or visual testing is needed, regardless of which browser automation framework the tests already use.
What it does
Generates SmartUI visual regression test configurations for screenshot comparison on TestMu AI cloud, framework-agnostic across Playwright, Selenium, Cypress, and Puppeteer. With Playwright, the @lambdatest/smartui-cli SDK's smartuiSnapshot(page, name) call captures a named screenshot at any point in the test flow; with Selenium, the equivalent is a smartui.takeScreenshot=<name> call via JavascriptExecutor. Execution runs through the SmartUI CLI: install @lambdatest/smartui-cli, generate smartui.config.json via npx smartui config:create, then wrap the actual test command with npx smartui exec -- <test command> (works with a plain Node script or npx playwright test). The config file sets which browsers to capture (chrome/firefox/safari), which viewports (e.g. 1920x1080 desktop, 1366x768 laptop, 375x812 mobile), and render-wait timing (waitForPageRender, waitForTimeout) so screenshots aren't taken mid-render. Storybook component libraries get their own command: npx smartui storybook <url> --config smartui.config.json captures every story as a snapshot. The approval workflow is fixed: the first run creates baseline screenshots, every subsequent run compares against that baseline, differences are highlighted in the SmartUI dashboard, a human approves or rejects each diff there, and approved screenshots become the new baseline. Four anti-patterns are called out: no viewport config misses responsive-layout issues (fix: configure multiple viewports); no render wait produces incomplete screenshots (fix: set waitForPageRender); screenshotting everything creates review noise (fix: capture only key pages/components); and skipping the dashboard approval step misses real regressions (fix: always review diffs before approving). Cloud authentication uses different environment variables depending on approach: the CLI path (npx smartui exec) reads PROJECT_TOKEN from the SmartUI dashboard, while the Selenium cloud-grid path reads LT_USERNAME/LT_ACCESS_KEY and passes them plus a smartUI.project name inside the LT:Options capabilities object when connecting to the LambdaTest remote hub.
const { chromium } = require('playwright');
const { smartuiSnapshot } = require('@lambdatest/smartui-cli');
(async () => {
const browser = await chromium.launch();
const page = await browser.newPage();
await page.goto('https://example.com');
await smartuiSnapshot(page, 'Homepage');
await browser.close();
})();
When to use - and when NOT to
Use it whenever a user mentions SmartUI, visual regression, screenshot comparison, or visual testing, regardless of which browser automation framework (Playwright, Selenium, Cypress, Puppeteer) they're already using.
Inputs and outputs
Input is a set of pages or components to snapshot, plus target browsers and viewports. Output is a smartui.config.json and framework-specific snapshot calls that, once run, produce baseline or comparison screenshots reviewable in the SmartUI dashboard.
Integrations
Integrates with Playwright, Selenium, Cypress, and Puppeteer via the @lambdatest/smartui-cli SDK or CLI wrapper, with Storybook for component-level snapshots, and with TestMu AI's LambdaTest cloud grid for cross-browser capture using LT_USERNAME/LT_ACCESS_KEY credentials.
Who it's for
QA engineers and developers setting up visual regression testing who want framework-agnostic screenshot comparison with a dashboard-based approval workflow, regardless of which browser automation tool their existing tests already use.
Source README
SmartUI Visual Regression Skill
When to Use
Use this skill when you need generates SmartUI visual regression test configurations for screenshot comparison on TestMu AI cloud. Framework-agnostic - works with Playwright, Selenium, Cypress, Puppeteer. Use when user mentions "SmartUI", "visual regression", "screenshot comparison", "visual testing". Triggers on:...
Core Patterns
Playwright + SmartUI SDK
const { chromium } = require('playwright');
const { smartuiSnapshot } = require('@lambdatest/smartui-cli');
(async () => {
const browser = await chromium.launch();
const page = await browser.newPage();
await page.goto('https://example.com');
await smartuiSnapshot(page, 'Homepage');
await page.goto('https://example.com/login');
await smartuiSnapshot(page, 'Login Page');
await browser.close();
})();
Selenium + SmartUI
// Take SmartUI screenshot
((JavascriptExecutor) driver).executeScript(
"smartui.takeScreenshot=Login Page"
);
CLI Execution
### Install
npm install @lambdatest/smartui-cli --save-dev
### Configure
npx smartui config:create smartui.config.json
### Execute
npx smartui exec -- node test.js
### or with Playwright
npx smartui exec -- npx playwright test
smartui.config.json
{
"web": {
"browsers": ["chrome", "firefox", "safari"],
"viewports": [[1920, 1080], [1366, 768], [375, 812]]
},
"waitForPageRender": 5000,
"waitForTimeout": 1000
}
SmartUI with Storybook
npx smartui storybook http://localhost:6006 --config smartui.config.json
Approval Workflow
- First run creates baseline screenshots
- Subsequent runs compare against baseline
- Differences highlighted in dashboard
- Approve/reject changes in LambdaTest SmartUI dashboard
- Approved screenshots become new baseline
Anti-Patterns
| Bad | Good | Why |
|---|---|---|
| No viewport config | Multiple viewports | Responsive issues |
| No wait for render | waitForPageRender |
Incomplete screenshots |
| Screenshot everything | Key pages/components | Noise reduction |
| No approval process | Review diffs in dashboard | Catch regressions |
Cloud Authentication
Set environment variables:
export PROJECT_TOKEN="your-smartui-project-token" # From SmartUI dashboard
export LT_USERNAME="your-username" # For Selenium/Playwright cloud
export LT_ACCESS_KEY="your-access-key" # For Selenium/Playwright cloud
CLI approach (uses PROJECT_TOKEN):
npx smartui exec -- npx playwright test
Selenium Cloud approach (uses LT_USERNAME/LT_ACCESS_KEY):
// Capabilities include SmartUI options
HashMap<String, Object> ltOptions = new HashMap<>();
ltOptions.put("user", System.getenv("LT_USERNAME"));
ltOptions.put("accessKey", System.getenv("LT_ACCESS_KEY"));
ltOptions.put("build", "SmartUI Build");
ltOptions.put("smartUI.project", "My SmartUI Project");
ChromeOptions options = new ChromeOptions();
options.setCapability("LT:Options", ltOptions);
WebDriver driver = new RemoteWebDriver(
new URL("https://hub.lambdatest.com/wd/hub"), options);
Quick Reference
| Task | Command |
|---|---|
| Install | npm install @lambdatest/smartui-cli |
| Init config | npx smartui config:create smartui.config.json |
| Run | npx smartui exec -- <test command> |
| Storybook | npx smartui storybook <url> |
| Dashboard | https://smartui.lambdatest.com |
Deep Patterns
For advanced patterns, debugging guides, CI/CD integration, and best practices,
see reference/playbook.md.
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.