SmartUI Capture Onboarding with HyperExecute
This comprehensive guide will walk you through setting up and running SmartUI Capture tests on HyperExecute. SmartUI Capture allows you to perform visual regression testing by capturing screenshots of static URLs across multiple browsers and devices, all orchestrated through HyperExecute's powerful test execution platform.
Prerequisites
Before you begin, ensure you have the following:
- Node.js v20.3 or higher (required for SmartUI CLI v4.x.x)
- npm or yarn package manager
- TestMu AI account with active subscription
- HyperExecute CLI installed (Download Guide)
- Basic understanding of:
- Command Line Interface (CLI)
- YAML configuration files
- JSON file structure
- Visual regression testing concepts
If you face any problems executing tests with SmartUI-CLI versions >= v4.x.x, upgrade your Node.js version to v20.3 or above.
Overview
SmartUI Capture on HyperExecute combines the power of:
- SmartUI CLI Capture: Captures screenshots of static URLs across browsers and devices
- HyperExecute: Orchestrates and executes tests at scale with parallel execution
- Visual Regression Testing: Compares screenshots to detect UI changes
This integration is ideal for:
- Testing production and staging environments
- Monitoring website visual consistency
- Detecting UI regressions across multiple pages
- Running large-scale visual tests in parallel
Step 1: Create a SmartUI Project
The first step is to create a SmartUI project in the dashboard. This project will contain all your builds and visual comparisons.
- Go to SmartUI Projects page
- Click on the New Project button
- Select the platform as CLI for executing your capture tests
- Add the following details:
- Project Name: A descriptive name (e.g., "Example Company Visual Tests")
- Approvers: Team members who can approve visual changes
- Tags: Optional tags for filtering and organization
- Click on Submit or Continue
After creating the project, you will receive a PROJECT_TOKEN. Save this token securely as you'll need it in the next steps. The token format looks like: 123456#1234abcd-****-****-****-************
Step 2: Set Up Your Project Structure
Create a new directory for your SmartUI Capture project or use an existing one. Here's the recommended structure:
smartui-capture-project/
├── config.json # SmartUI configuration
├── urlTest.json # Test environment URLs
├── urlProd.json # Production environment URLs
├── test/ # Optional: Split test URLs
│ ├── urls_test_1.json
│ ├── urls_test_2.json
│ └── ...
├── prod/ # Optional: Split production URLs
│ ├── urls_prod_1.json
│ ├── urls_prod_2.json
│ └── ...
├── hyperexecute.yaml # HyperExecute configuration
└── package.json # Node.js dependencies
Initialize Your Project
If you're starting fresh, initialize a new Node.js project:
mkdir smartui-capture-project
cd smartui-capture-project
npm init -y
Step 3: Install Dependencies
Install the required SmartUI CLI package. You can install it globally or locally in your project.
Global Installation (Recommended)
npm install -g @lambdatest/smartui-cli@4.1.54-beta.0
Local Installation
npm install @lambdatest/smartui-cli@4.1.54-beta.0
You can also clone the sample repository to get started quickly:
git clone https://github.com/LambdaTest/smartui-playwright-sample
cd smartui-playwright-sample
Step 4: Configure Environment Variables
Set up your environment variables for authentication and configuration.
Set Project Token
The PROJECT_TOKEN is required for SmartUI CLI capture commands.
- MacOS/Linux
- Windows - CMD
- PowerShell
export PROJECT_TOKEN="123456#1234abcd-****-****-****-************"
set PROJECT_TOKEN="123456#1234abcd-****-****-****-************"
$env:PROJECT_TOKEN="123456#1234abcd-****-****-****-************"
Set HyperExecute Credentials
For HyperExecute, you'll need your LambdaTest username and access key.
- MacOS/Linux
- Windows - CMD
- PowerShell
export LT_USERNAME="${YOUR_LAMBDATEST_USERNAME}"
export LT_ACCESS_KEY="${YOUR_LAMBDATEST_ACCESS_KEY}"
set LT_USERNAME="${YOUR_LAMBDATEST_USERNAME}"
set LT_ACCESS_KEY="${YOUR_LAMBDATEST_ACCESS_KEY}"
$env:LT_USERNAME="${YOUR_LAMBDATEST_USERNAME}"
$env:LT_ACCESS_KEY="${YOUR_LAMBDATEST_ACCESS_KEY}"
- Username and Access Key: Available in your LambdaTest Profile
- Project Token: Available in your SmartUI project settings after creation
Step 5: Create URL Configuration Files
Create JSON files containing the URLs you want to test. Each URL entry should have a name, URL, and optional wait timeout.
Create URL File Using CLI
You can generate a sample URL file using the SmartUI CLI:
npx smartui config:create-web-static urls.json
Manual URL File Creation
Alternatively, create your URL file manually. Here's the structure:
[
{
"name": "homepage",
"url": "https://test.example.com/",
"waitForTimeout": 5000
},
{
"name": "about_page",
"url": "https://test.example.com/about/",
"waitForTimeout": 5000
},
{
"name": "contact_page",
"url": "https://test.example.com/contact/",
"waitForTimeout": 5000
}
]
URL File Structure
Each URL object supports the following properties:
| Property | Type | Required | Description |
|---|---|---|---|
name | string | Yes | Unique identifier for the screenshot (used in SmartUI dashboard) |
url | string | Yes | The URL to capture |
waitForTimeout | number | No | Wait time in milliseconds before capturing (useful for lazy-loaded content) |
Splitting URLs for Parallel Execution
For large test suites, you can split URLs into multiple files for better parallel execution:
[
{
"name": "product_category_feature_a",
"url": "https://test.example.com/product-category/feature-a/",
"waitForTimeout": 5000
},
{
"name": "product_category_feature_b",
"url": "https://test.example.com/product-category/feature-b/",
"waitForTimeout": 5000
}
]
Step 6: Create SmartUI Configuration
Create a config.json file to configure browsers, viewports, and other SmartUI settings.
Generate Configuration File
npx smartui config:create config.json
Manual Configuration
Create config.json with your desired settings:
{
"web": {
"browsers": [
"safari",
"chrome"
],
"viewports": [
[1367]
]
},
"mobile": {
"devices": [
"iPhone 14",
"iPad 10.2 (2021)",
"Pixel 8"
],
"orientation": "portrait"
},
"cliEnableJavaScript": true,
"lazyLoadConfiguration": {
"enabled": true,
"jumpBackToTop": true,
"scrollDelay": 250,
"scrollStep": 250
},
"waitForTimeout": 5000
}
Configuration Options Explained
Web Configuration
- browsers: Array of browser names (
"chrome","firefox","safari","edge") - viewports: Array of viewport sizes
[1367]- Full page screenshot at 1367px width[1920, 1080]- Viewport screenshot at 1920x1080
Mobile Configuration
- devices: Array of device names (e.g.,
"iPhone 14","Galaxy S24","Pixel 8") - orientation:
"portrait"or"landscape" - fullPage:
trueby default for mobile
Lazy Loading Configuration
- enabled: Enable lazy loading detection
- jumpBackToTop: Scroll back to top after capturing
- scrollDelay: Delay between scroll steps (milliseconds)
- scrollStep: Pixels to scroll per step
For more configuration options, refer to the SmartUI SDK Config Options documentation.
Step 7: Create HyperExecute YAML Configuration
Create a hyperexecute.yaml file to configure HyperExecute execution settings.
Basic HyperExecute YAML
---
version: 0.1
globalTimeout: 150
testSuiteTimeout: 150
testSuiteStep: 150
runson: win
retryOnFailure: true
maxRetries: 1
concurrency: 1
env:
CACHE_DIR: node_modules_cache
PROJECT_TOKEN: ${PROJECT_TOKEN}
# Dependency caching
cacheKey: '{{ checksum "package.json" }}'
cacheDirectories:
- ${CACHE_DIR}
pre:
# Install SmartUI CLI and dependencies
- npm install @lambdatest/smartui-cli@4.1.54-beta.0
- npm install playwright@1.57.0
- npx playwright install
testSuites:
- npx smartui capture urlTest.json --config config.json --buildName "Test-Release-v1.0"
jobLabel: ['HYP', 'SmartUI', 'Capture']
Advanced HyperExecute YAML with Multiple Test Suites
For running multiple URL files in parallel:
---
version: 0.1
globalTimeout: 300
testSuiteTimeout: 300
testSuiteStep: 150
runson: win
retryOnFailure: true
maxRetries: 1
concurrency: 3
env:
CACHE_DIR: node_modules_cache
PROJECT_TOKEN: ${PROJECT_TOKEN}
cacheKey: '{{ checksum "package.json" }}'
cacheDirectories:
- ${CACHE_DIR}
pre:
- npm install @lambdatest/smartui-cli@4.1.54-beta.0
- npm install playwright@1.57.0
- npx playwright install
matrix:
urlFile: ["urlTest.json", "urlProd.json"]
testSuites:
- npx smartui capture ${urlFile} --config config.json --buildName "Build-${urlFile}"
jobLabel: ['HYP', 'SmartUI', 'Capture', 'Parallel']
HyperExecute YAML Parameters
| Parameter | Description | Example |
|---|---|---|
version | YAML schema version | 0.1 |
globalTimeout | Maximum time for entire job (minutes) | 150 |
testSuiteTimeout | Maximum time per test suite (minutes) | 150 |
runson | Operating system (win, mac, linux) | win |
concurrency | Number of parallel test executions | 3 |
retryOnFailure | Retry failed tests | true |
maxRetries | Maximum retry attempts | 1 |
pre | Commands to run before test execution | Installation commands |
testSuites | Test commands to execute | SmartUI capture commands |
matrix | Matrix for parallel execution | Multiple URL files |
For detailed YAML configuration options, refer to the HyperExecute YAML Documentation.
Step 8: Execute Tests on HyperExecute
Download HyperExecute CLI
Download the HyperExecute CLI for your operating system:
Set Execute Permissions (MacOS/Linux)
chmod u+x ./hyperexecute
Run Tests
Execute your tests using the HyperExecute CLI:
./hyperexecute --config hyperexecute.yaml
Or with explicit credentials:
./hyperexecute --user ${YOUR_LAMBDATEST_USERNAME} --key ${YOUR_LAMBDATEST_ACCESS_KEY} --config hyperexecute.yaml
Capture Command Options
You can enhance your capture commands with additional options:
# With custom build name
npx smartui capture urlTest.json --config config.json --buildName "Release-v1.0"
# With results export
npx smartui capture urlTest.json --config config.json --fetch-results results.json
# With parallel execution
npx smartui capture urlTest.json --config config.json --parallel 3
# Combined options
npx smartui capture urlTest.json --config config.json --buildName "Release-v1.0" --fetch-results results.json --parallel 3
Step 9: Monitor Test Execution
HyperExecute Dashboard
- Visit the HyperExecute Dashboard
- Find your job in the job list
- Click on the job to view detailed execution logs
- Monitor test progress in real-time
SmartUI Dashboard
- After test execution completes, navigate to SmartUI Dashboard
- Select your project
- View the build with your specified build name
- Review captured screenshots
- Compare with baseline images (if available)
Understanding Results
- Baseline Build: First build in a project (reference images)
- Comparison Build: Subsequent builds compared against baseline
- Mismatches: Visual differences detected between builds
- Approved: Manually approved visual changes
- Rejected: Visual changes that need fixing
Using SmartUI Reporter Tool
The SmartUI Reporter is a web-based tool that provides a comprehensive tabular view of your test results with statistics and export capabilities.
Step 1: Export Results JSON
From CLI Capture Command:
npx smartui capture urlTest.json --config config.json --fetch-results results.json
From CLI Exec Command:
npx smartui --config config.json exec --fetch-results results.json -- <execution-command>
From SmartUI API: You can also fetch results using the Fetch Build Screenshots API endpoint:
GET /build/screenshots?project_id=YOUR_PROJECT_ID&build_id=YOUR_BUILD_ID
Step 2: Upload to Reporter
- Visit SmartUI Reporter
- Upload your
results.jsonfile (drag & drop or click to upload) - View results in a tabular format with:
- Screenshot statistics
- Browser and viewport information
- Mismatch percentages
- Status indicators
- Direct links to baseline, captured, and diff images
Step 3: Export Options
- Export to PDF: Generate a comprehensive PDF report for sharing
- Export to CSV: Export data for analysis in spreadsheet applications
For detailed information, see the Fetch Results Documentation.
Best Practices
1. URL Organization
- Environment Separation
- URL Splitting
- Naming Conventions
Separate Test and Production URLs
Keep test and production URLs in separate files:
urlTest.json- Staging/test environmenturlProd.json- Production environment
This allows you to test both environments independently.
Split Large URL Lists
For projects with many URLs, split them into multiple files:
test/
├── urls_test_1.json (10 URLs)
├── urls_test_2.json (10 URLs)
└── urls_test_3.json (10 URLs)
This enables better parallel execution and easier management.
Use Descriptive Names
Use clear, descriptive names for your URLs:
{
"name": "product_category_feature_a",
"url": "https://example.com/product-category/feature-a/"
}
Avoid generic names like "page1" or "test".
1.1. URL Grouping Strategies for Large Test Suites
When working with large numbers of URLs (e.g., 1000+ URLs) that can be logically divided into sections or groups (e.g., Section 1: Product Category A, Section 2: Product Category B, Section 3: Product Category C, etc.), you have two primary strategies for organizing your SmartUI projects:
- Strategy 1: Single Project with Branching
- Strategy 2: Separate Projects
Single Project with Branching Strategy
Use a single SmartUI project and leverage SmartUI's branching capabilities to organize different URL groups within the same project.
How It Works
- Single Project: All URL groups/sections are managed in one SmartUI project
- Branching Strategy: Use SmartUI's Smart Git feature to create separate branches for each section/group
- Unified Tracking: All URLs and automation are tracked in a single project dashboard
- Independent Baselines: Each branch maintains its own baseline and comparison history
Implementation
Step 1: Create URL Groups
Organize your URLs into logical groups:
project/
├── sections/
│ ├── section1_category_a.json (200 URLs)
│ ├── section2_category_b.json (200 URLs)
│ ├── section3_category_c.json (200 URLs)
│ ├── section4_category_d.json (200 URLs)
│ └── section5_category_e.json (200 URLs)
├── config.json
└── hyperexecute.yaml
Step 2: Configure HyperExecute with Matrix
Use HyperExecute matrix to run each section:
---
version: 0.1
globalTimeout: 300
testSuiteTimeout: 150
runson: win
concurrency: 5
env:
PROJECT_TOKEN: ${PROJECT_TOKEN}
SMART_GIT: true # Enable Smart Git for branch management
pre:
- npm install @lambdatest/smartui-cli@4.1.54-beta.0
matrix:
section: ["section1_category_a", "section2_category_b", "section3_category_c", "section4_category_d", "section5_category_e"]
testSuites:
- npx smartui capture sections/${section}.json --config config.json --buildName "${section}-Build"
Step 3: Use Branching for Organization
Each section can run in its own branch or use build names to group:
# Option A: Use Smart Git with branches
export SMART_GIT=true
git checkout -b section1-category-a
npx smartui capture sections/section1_category_a.json --config config.json --buildName "Section1-CategoryA"
# Option B: Use build names for grouping (single branch)
npx smartui capture sections/section1_category_a.json --config config.json --buildName "Section1-CategoryA-Build"
Use Cases
✅ Best for:
- Teams that want centralized project management
- Organizations needing unified reporting and analytics
- Projects where sections share common configuration
- Teams that want to track all URLs in one dashboard
- Scenarios requiring cross-section comparisons
✅ Benefits:
- Single project dashboard for all sections
- Unified baseline management
- Easier cross-section analysis
- Simplified project administration
- Single project token to manage
❌ Not ideal for:
- Teams requiring completely isolated section management
- Organizations with different approval workflows per section
- Projects where sections have vastly different configurations
Separate Projects Strategy
Create individual SmartUI projects for each URL group/section, providing complete isolation and independent management.
How It Works
- Multiple Projects: Each section/group has its own dedicated SmartUI project
- Independent Management: Each project operates independently with its own baseline, approvals, and settings
- Minimal Projects: Each project contains only one branch (typically
mainormaster) - Clear Separation: Complete bifurcation between different sections
Implementation
Step 1: Create Separate Projects
Create a SmartUI project for each section:
- Project 1: "Product Category A Visual Tests" →
PROJECT_TOKEN_1 - Project 2: "Product Category B Visual Tests" →
PROJECT_TOKEN_2 - Project 3: "Product Category C Visual Tests" →
PROJECT_TOKEN_3 - Project 4: "Product Category D Visual Tests" →
PROJECT_TOKEN_4 - Project 5: "Product Category E Visual Tests" →
PROJECT_TOKEN_5
Step 2: Organize URL Files
project/
├── category_a/
│ ├── urls_category_a.json
│ ├── config.json
│ └── hyperexecute_category_a.yaml
├── category_b/
│ ├── urls_category_b.json
│ ├── config.json
│ └── hyperexecute_category_b.yaml
└── category_c/
├── urls_category_c.json
├── config.json
└── hyperexecute_category_c.yaml
Step 3: Configure Each Project Separately
Each project has its own configuration and HyperExecute YAML:
---
version: 0.1
globalTimeout: 150
testSuiteTimeout: 150
runson: win
concurrency: 2
env:
PROJECT_TOKEN: ${PROJECT_TOKEN_CATEGORY_A} # Unique token per project
pre:
- npm install @lambdatest/smartui-cli@4.1.54-beta.0
testSuites:
- npx smartui capture urls_category_a.json --config config.json --buildName "CategoryA-Build"
Step 4: Execute Projects Independently
Run each project separately or in parallel:
# Execute category A project
cd category_a
export PROJECT_TOKEN="${PROJECT_TOKEN_CATEGORY_A}"
./hyperexecute --config hyperexecute_category_a.yaml
# Execute category B project
cd ../category_b
export PROJECT_TOKEN="${PROJECT_TOKEN_CATEGORY_B}"
./hyperexecute --config hyperexecute_category_b.yaml
Use Cases
✅ Best for:
- Teams requiring complete section isolation
- Organizations with different approval workflows per section
- Projects where sections have independent release cycles
- Teams needing separate access controls per section
- Scenarios where sections have different configurations
✅ Benefits:
- Complete isolation between sections
- Independent baseline management
- Separate approval workflows
- Individual project settings per section
- Clear project boundaries
❌ Not ideal for:
- Teams wanting unified reporting
- Organizations needing cross-section analysis
- Projects with shared configurations
- Teams preferring centralized management
Decision Matrix
Use this matrix to decide which strategy fits your needs:
| Requirement | Single Project with Branching | Separate Projects |
|---|---|---|
| Unified Dashboard | ✅ Yes | ❌ No |
| Cross-Section Analysis | ✅ Yes |