Skip to main content

Hybrid Strategy in HyperExecute

HyperExecute’s Hybrid Strategy is a combination of AutoSplit and Matrix Strategy. You can run all of the combinations of Matrix Strategy, and use the AutoSplit Strategy to run them in parallel on our virtual machines.

Why do you need the Hybrid Strategy?​

  • Addressing Long-Running Matrix Jobs : For Matrix jobs involving numerous combinations, execution time might be longer. Hybrid Strategy mitigates this by distributing tests across specified machines.

  • Time-Saving Potential of Hybrid Approach : The Hybrid Strategy is a time-saving solution for matrix-intensive jobs. By harnessing parallelism, you can expedite testing without compromising coverage.

Image

Based on the above instructions passed as parameters in your YAML file, HyperExecute will now generate Virtual Machines.

  • 1 VM for Win + Chrome
  • 1 VM for Win + Firefox
  • 1 VM for Linux + Chrome
  • 1 VM for Linux + Firefox

Now the given parallelism is 2, hence it will create the same set of the above combination, and since Hybrid Mode is the combination of Autosplit and Matrix method, HyperExecute will intelligently distribute tests over these Virtual Machines.

Using Hybrid Strategy with HyperExecute​

Pre-requisites:​

  • The version of the YAML file that you are using is 0.1.
  • The test discovery mode has to be dynamic.

You can run your tests in Hybrid Strategy by configuring the following flags in your YAML file.

  • autosplit: To use HyperExecute’s AutoSplit Strategy, you need to set this flag to true. Similarly, this flag should be set to true in Hybrid Strategy too.
autosplit: true
  • parallelism: This key indicates the number of tests that can run in parallel. 
parallelism: 5
  • You can define the parallelism for each operating system. If you have not defined the parallelism for any particular OS, then the value for that OS will be set to the global parallelism value.
Parallelism: 4 
winParallelism: 2 
macParallelism: 3
  • In the example given above, the parallelism for Linux tests is not defined and if any tests are run on Linux OS, then they will be run in 4 different virtual machines because the global value of parallelism is set to 4.
  • matrix: This flag is used to define the combination of tests you want to run in your job. You can use the matrix flag to define combinations of browsers, operating systems, and even custom parameters like files, folders, tags, scenarios, and more. 
matrix:
  os: [mac, win, linux] 
  var: [1,2,3] 
runson: ${matrix.os}
  • If you want to run a combination of different operating systems in Hybrid Strategy, then you can configure the runson key as ${matrix.os}. This will only work if you have added some input for the os flag under matrix in your YAML file.
  • testDiscovery: The testDiscovery command is used to list down all the values that have to be distributed. It can be used to split tests over files, modules, or any level supported by your language and framework. 
testDiscovery:
  type: raw
  mode: dynamic
  command: snooper --featureFilePaths=src/main//Features/ --frameWork=java
  • It can also be defined selectively for every platform. If you have not defined the testDiscovery command for a specific OS, then it takes the global value of the command. 
testDiscovery:
  type: raw
  mode: dynamic
  command: snooper --featureFilePaths=src/main//Features/ --frameWork=java 
    winCommand: snooper --featureFilePaths=src/main//Features/ --frameWork=java 
    macCommand: snooper --featureFilePaths=src/main/**/Features/ --frameWork=java
  • In the example given above, the testDiscovery command for Linux will be: snooper --featureFilePaths=src/main//Features/ --frameWork=java
  • testRunnerCommand: The testRunnerCommand tells the system how to run a single test entity in isolation. This entity could be a file, module, feature or scenario. It will run over each of the values extracted from the testDiscovery command. 
testRunnerCommand: mvn test -Dcucumber.options="$test" -Dscenario="$test" -DOs="win 10"
  winTestRunnerCommand: mvn test -Dcucumber.options="$test" -Dscenario="$test" -DOs="win 10"
  macTestRunnerCommand: mvn test -Dcucumber.options="$test" -Dscenario="$test" -DOs="Mac"
  linuxTestRunnerCommand: mvn test -Dcucumber.options="$test" -Dscenario="$test" -DOs="linux"
  • If the testRunnerCommand is not defined for a particular OS, then it takes the global value of the parameter that is defined. In the example given above, if the testRunnerCommand was not defined for macOS, then it would have taken the value: mvn test -Dcucumber.options="$test" -Dscenario="$test" -DOs="win 10"

Sample YAML file​

A sample YAML file used to run a job on Hybrid Strategy for your reference below:

---
version: 0.1
globalTimeout: 150
testSuiteTimeout: 150
testSuiteStep: 150

runson: ${matrix.os}
retryOnFailure: false
autosplit: true
maxRetries: 1
parallelism: 2
concurrency: 3

matrix:
  os: [mac, win, linux]

env:
  CACHE_DIR: m2_cache_dir

cacheKey: '{{ checksum "pom.xml" }}'
cacheDirectories:
  - ${CACHE_DIR}

testDiscovery:
  type: raw
  mode: dynamic
  macCommand: |
    grep 'test name' xml/testng_mac.xml | awk '{print$2}' | sed 's/name=//g' | sed 's/\x3e//g'
  winCommand: | 
    grep 'test name' xml/testng_win.xml | awk '{print$2}' | sed 's/name=//g' | sed 's/\x3e//g'
  linuxCommand: |
    grep 'test name' xml/testng_linux.xml | awk '{print$2}' | sed 's/name=//g' | sed 's/\x3e//g' ${param}

pre:
  - mvn -Dmaven.repo.local=${CACHE_DIR} -Dmaven.test.skip=true clean install

post:
  - cat yaml/${matrix.os}/testng_hyperexecute_matrix_sample.yaml

mergeArtifacts: true

uploadArtefacts:
  - name: XmlReports
    path:
      - target/surefire-reports/html/**

linuxTestRunnerCommand: mvn test -Dplatname=linux -Dmaven.repo.local=./.m2 dependency:resolve -DselectedTests=$tests
winTestRunnerCommand: mvn test `-Dplatname=win `-Dmaven.repo.local=.m2 dependency:resolve `-DselectedTests=$tests
macTestRunnerCommand: mvn test -Dplatname=mac -Dmaven.repo.local=./.m2 dependency:resolve -DselectedTests=$tests
Last updated on