https://github.com/lambdatest/hyperexecute-klassijs-sample
Run Tests with HyperExecute on TestMu AI (Formerly LambdaTest).
https://github.com/lambdatest/hyperexecute-klassijs-sample
automation end-to-end-test-automation end-to-end-testing hyperexecute klassi-js selenium testmuai
Last synced: about 1 month ago
JSON representation
Run Tests with HyperExecute on TestMu AI (Formerly LambdaTest).
- Host: GitHub
- URL: https://github.com/lambdatest/hyperexecute-klassijs-sample
- Owner: LambdaTest
- License: mit
- Created: 2022-08-31T12:17:56.000Z (almost 4 years ago)
- Default Branch: master
- Last Pushed: 2026-05-17T11:30:54.000Z (about 1 month ago)
- Last Synced: 2026-05-17T12:31:24.245Z (about 1 month ago)
- Topics: automation, end-to-end-test-automation, end-to-end-testing, hyperexecute, klassi-js, selenium, testmuai
- Language: JavaScript
- Homepage: https://www.testmuai.com
- Size: 14.4 MB
- Stars: 1
- Watchers: 5
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
README
# Run Selenium Tests on HyperExecute Using TestMu AI (Formerly LambdaTest)
## Getting Started
[TestMu AI](https://www.testmuai.com/) (Formerly LambdaTest) is the world's first full-stack AI Agentic Quality Engineering platform that empowers teams to test intelligently, smarter, and ship faster. Built for scale, it offers a full-stack testing cloud with 10K+ real devices and 3,000+ browsers. With AI-native test management, MCP servers, and agent-based automation, TestMu AI supports Selenium, Appium, Playwright, and all major frameworks.
With TestMu AI (Formerly LambdaTest), you can run Selenium Tests on HyperExecute Using TestMu AI (Formerly LambdaTest) across real browsers and operating systems.
- [Sign up on TestMu AI](https://www.testmuai.com/register/) (Formerly LambdaTest).
- Follow the [TestMu AI Documentation](https://www.testmuai.com/support/docs/) for the full setup walkthrough.
### Prerequisites
- Node.js and npm (latest stable)
- A TestMu AI (Formerly LambdaTest) account with your username and access key
### Prerequisites
Before using HyperExecute, download the HyperExecute CLI for your OS and export the environment variables *LT_USERNAME* and *LT_ACCESS_KEY* from your TestMu AI (Formerly LambdaTest) Profile page.
* [Pre-requisites](#pre-requisites)
- [Download HyperExecute CLI](#download-hyperexecute-cli)
- [Configure Environment Variables](#configure-environment-variables)
* [Auto-Split Execution with Klassi-js](#auto-split-execution-with-Klassi-js)
- [Core](#core)
- [Pre Steps and Dependency Caching](#pre-steps-and-dependency-caching)
- [Artifacts Management](#artifacts-management)
- [Test Execution](#test-execution)
* [Run Klassi-js tests on Windows and Linux platforms](#run-Klassi-js-tests-on-windows-and-linux-platforms)
* [Secrets Management](#secrets-management)
* [Navigation in Automation Dashboard](#navigation-in-automation-dashboard)
## Download HyperExecute CLI
HyperExecute CLI is the CLI for interacting and running the tests on the HyperExecute Grid. The CLI provides a host of other useful features that accelerate test execution. In order to trigger tests using the CLI, you need to download the HyperExecute CLI binary corresponding to the platform (or OS) from where the tests are triggered:
Also, it is recommended to download the binary in the project's parent directory. Shown below is the location from where you can download the HyperExecute CLI binary:
* Mac: https://downloads.lambdatest.com/hyperexecute/darwin/hyperexecute
* Linux: https://downloads.lambdatest.com/hyperexecute/linux/hyperexecute
* Windows: https://downloads.lambdatest.com/hyperexecute/windows/hyperexecute.exe
## Configure Environment Variables
Before the tests are run, please set the environment variables LT_USERNAME & LT_ACCESS_KEY from the terminal. The account details are available on your TestMu AI (Formerly LambdaTest) Profile page.
For macOS:
```bash
export LT_USERNAME=LT_USERNAME
export LT_ACCESS_KEY=LT_ACCESS_KEY
```
For Linux:
```bash
export LT_USERNAME=LT_USERNAME
export LT_ACCESS_KEY=LT_ACCESS_KEY
```
For Windows:
```bash
set LT_USERNAME=LT_USERNAME
set LT_ACCESS_KEY=LT_ACCESS_KEY
```
## Auto-Split Execution with Klassi-js
Auto-split execution mechanism lets you run tests at predefined concurrency and distribute the tests over the available infrastructure. Concurrency can be achieved at different levels - file, module, test suite, test, scenario, etc.
For more information about auto-split execution, check out the Auto-Split Getting Started Guide
### Core
Auto-split YAML file (*HyperExecute-Yaml\.hyperexecuteStatic.yaml*) in the repo contains the following configuration:
```yaml
globalTimeout: 90
testSuiteTimeout: 90
testSuiteStep: 90
```
Global timeout, testSuite timeout, and testSuite timeout are set to 90 minutes.
The *runson* key determines the platform (or operating system) on which the tests are executed. Here we have set the target OS as Windows.
```yaml
runson: win
```
Auto-split is set to true in the YAML file.
```yaml
autosplit: true
```
*retryOnFailure* is set to true, instructing HyperExecute to retry failed command(s). The retry operation is carried out till the number of retries mentioned in *maxRetries* are exhausted or the command execution results in a *Pass*. In addition, the concurrency (i.e. number of parallel sessions) is set to 2.
```yaml
retryOnFailure: true
runson: win
maxRetries: 2
```
## Pre Steps and Dependency Caching
To leverage the advantage offered by *Dependency Caching* in HyperExecute, the integrity of *package-lock.json* is checked using the checksum functionality.
```yaml
cacheKey: '{{ checksum "package-lock.json" }}'
```
The caching advantage offered by *NPM* can be leveraged in HyperExecute, whereby the downloaded packages can be stored (or cached) in a secure server for future executions. The packages available in the cache will only be used if the checksum stage results in a Pass.
```yaml
cacheDirectories:
- node_modules
```
The *testDiscovery* directive contains the command that gives details of the mode of execution, along with detailing the command that is used for test execution. Here, we are fetching the list of Feature file scenario that would be further executed using the *value* passed in the *testRunnerCommand*
```yaml
testDiscovery:
type: raw
mode: static
command: grep -nri '@uattest' features -ir --include=\*.feature | awk '{print$1}' | sed 's/:.*//'
testRunnerCommand: yarn run ltlocal $test
```
Running the above command on the terminal will give a list of Feature Scenario lines that are located in the Project folder:
Test Discovery Result: 2
features/duckDuckGo-search.feature
features/getMethod.feature
The *testRunnerCommand* contains the command that is used for triggering the test. The output fetched from the *testDiscoverer* command acts as an input to the *testRunner* command.
```yaml
testRunnerCommand: yarn run ltlocal $test
```
### Artifacts Management
The *mergeArtifacts* directive (which is by default *false*) is set to *true* for merging the artifacts and combing artifacts generated under each task.
The *uploadArtefacts* directive informs HyperExecute to upload artifacts [files, reports, etc.] generated after task completion. In the example, *path* consists of a regex for parsing the directory (i.e. *reports* that contains the test reports).
```yaml
mergeArtifacts: true
uploadArtefacts:
- name: Reports
path:
- reports\
```
HyperExecute also facilitates the provision to download the artifacts on your local machine. To download the artifacts, click on *Artifacts* button corresponding to the associated TestID.
### Test Execution
The CLI option *--config* is used for providing the custom HyperExecute YAML file (i.e. *HyperExecute-Yaml/.hyperexecuteStatic.yaml*). Run the following command on the terminal to trigger the tests in JS files on the HyperExecute grid. The *--download-artifacts* option is used to inform HyperExecute to download the artifacts for the job.
```bash
./hyperexecute --config hyperexecute.yaml
```
Visit HyperExecute Automation Dashboard to check the status of execution
### Pre Steps and Dependency Caching
Dependency caching is enabled in the YAML file to ensure that the package dependencies are not downloaded in subsequent runs. The first step is to set the Key used to cache directories.
```yaml
cacheKey: '{{ checksum "yarn.lock" }}'
```
Set the array of files & directories to be cached. In the example, all the packages will be cached in the *CacheDir* directory.
```yaml
cacheDirectories:
- node_modules
```
Steps (or commands) that must run before the test execution are listed in the *pre* run step. In the example, the packages listed in *requirements.txt* are installed using the *npm install* command.
```yaml
pre:
- npm install
```
### Artifacts Management
The *mergeArtifacts* directive (which is by default *false*) is set to *true* for merging the artifacts and combing artifacts generated under each task.
The *uploadArtefacts* directive informs HyperExecute to upload artifacts [files, reports, etc.] generated after task completion. In the example, *path* consists of a regex for parsing the directory (i.e. *reports* that contains the test reports).
```yaml
mergeArtifacts: true
uploadArtefacts:
- name: Reports
path:
- reports\
```
HyperExecute also facilitates the provision to download the artifacts on your local machine. To download the artifacts, click on Artifacts button corresponding to the associated TestID.
### Secrets management
In case you want to use any secret keys in the YAML file, the same can be set by clicking on the *Secrets* button the dashboard.
All you need to do is create an environment variable that uses the secret key:
```yaml
env:
AccessKey: ${{.secrets.AccessKey}}
```
## Navigation in Automation Dashboard
HyperExecute lets you navigate from/to *Test Logs* in Automation Dashboard from/to *HyperExecute Logs*. You also get relevant get relevant Selenium test details like video, network log, commands, Exceptions & more in the Dashboard. Effortlessly navigate from the automation dashboard to HyperExecute logs (and vice-versa) to get more details of the test execution.
## TestMu AI (Formerly LambdaTest) Community
Connect with testers and developers in the [TestMu AI Community](https://community.testmuai.com/). Ask questions, share what you are building, and discuss best practices in test automation and DevOps.
## TestMu AI (Formerly LambdaTest) Certifications
Earn free [TestMu AI Certifications](https://www.testmuai.com/certifications/) for testers, developers, and QA engineers. Validate your skills in Selenium, Cypress, Playwright, Appium, Espresso and more. Industry-recognized, shareable on LinkedIn, and built by practitioners, not marketers.
## Learning Resources by TestMu AI (Formerly LambdaTest)
Learn modern testing through tutorials, guides, videos, and weekly updates:
* [TestMu AI Blog](https://www.testmuai.com/blog/)
* [TestMu AI Learning Hub](https://www.testmuai.com/learning-hub/)
* [TestMu AI on YouTube](https://www.youtube.com/@TestMuAI)
* [TestMu AI Newsletter](https://www.testmuai.com/newsletter/)
## LambdaTest is Now TestMu AI
On **January 12, 2026**, [LambdaTest evolved to TestMu AI](https://www.testmuai.com/lambdatest-is-now-testmuai/), the world's first fully autonomous **Agentic AI Quality Engineering Platform**.
Same team. Same infrastructure. Same customer accounts. All existing LambdaTest logins, scripts, capabilities, and integrations continue to work without change.
🔗 Find the new home for [LambdaTest](https://www.testmuai.com).
### How LambdaTest Evolved into TestMu AI
In 2017, we launched LambdaTest with a simple mission: make testing fast, reliable, and accessible. As LambdaTest grew, we expanded into Test Intelligence, Visual Regression Testing, Accessibility Testing, API Testing, and Performance Testing, covering the full depth of the testing lifecycle.
As software development entered the AI era, testing had to evolve, too. We rebuilt the architecture to be AI-native from the ground up, with autonomous agents that **plan, author, execute, analyze, and optimize tests** while keeping humans in the loop. The platform integrates with your repos, CI, IDEs, and terminals, continuously learning from every code change and development signal.
That evolution earned a new name: **TestMu AI**, built for an AI-first future of quality engineering. TestMu is not a new name for us. It is the name of our annual community conference, which has brought together 100,000+ quality engineers to discuss how AI would reshape testing, long before that became an industry norm.
What started as a high-performance cloud testing platform has transformed into an AI-native, multi-agent system powering a connected, end-to-end quality layer. That evolution defined a new identity: LambdaTest evolved into TestMu AI, built for an AI-first future of quality engineering.
## Support
Got a question? Email [support@testmuai.com](mailto:support@testmuai.com) or chat with us 24x7 from our chat portal.