Automation with Cypress
Test reference in Squash TM
In order to bind a Squash TM test case to a Cypress automated test, the content of the Automated test reference field of the Automation block of a test case must have the following format:
[repository]/[project]#[test_file]
or
[repository]#[test_file]
(The reference always contains a single #
character.)
with:
-
[repository]
: Name of the Git repository. -
[project]
: Path to the Cypress project directory, i.e. the directory containing thecypress.json
/cypress.config.js
file and thecypress
directory.
This parameter is optional, i.e. if the Cypress project is at the root of the Git repository, this path is absent. -
[test_file]
: Path (relative to the previous directory) and name of the Cypress test file, from the root of the project (with the.spec.js
extension).
Example 1: my_repo/projects/second_project#cypress/integration/actions.spec.js
(the Cypress project is in a subfolder)
Example 2: my_repo#cypress/integration/actions.spec.js
(the Cypress project is at the root of the repository)
Old syntax
Old versions of Squash Orchestrator used the following format:
[repository]/[test_file]
with:
[repository]
: Name of the Git repository.[test_file]
: Path and name of the Cypress test file, from the root of the project (with the.spec.js
extension).
Example: my_repo/cypress/integration/actions.spec.js
This syntax is deprecated and should not be used. It is nevertheless still supported.
This syntax did not support Cypress tests which are not at the root of the source code repository.
Determination of the result of the test case
In this version of Squash, it is not possible to select a specific test in a .spec.js
file containing several ones: all tests in the file are therefore executed together.
The result of the Squash TM test case is calculated by taking into account the individual results of each test included in the .spec.js
file:
- If at least one test has an Error status (in case of a technical issue), the status of the execution will be Blocked.
- If at least one test fails functionally and none of the other ones has an Error status, the status of the execution will be Failed.
- If all tests succeed, the status of the execution will be Success.
Nature of the exploitable Squash TM parameters
The exploitable Squash TM parameters will differ depending on whether you're using the Community/Premium or Ultimate version of Squash.
Here is a table showing the exploitable parameters (these parameters are transmitted as test parameters, see below, Squash TM does not generate global parameters):
Nature | Key | Community/Premium | Ultimate |
---|---|---|---|
Name of the dataset | DSNAME | ✅ | ✅ |
Dataset parameter | DS_[name] | ✅ | ✅ |
Execution ID | TC_EXECUTION_ID | ❌ | ✅ |
Test case reference | TC_REFERENCE | ✅ | ✅ |
Test case internal UUID | TC_UUID | ✅ | ✅ |
Test case custom field | TC_CUF_[code] | ✅ | ✅ |
Iteration custom field | IT_CUF_[code] | ❌ | ✅ |
Campaign custom field | CPG_CUF_[code] | ❌ | ✅ |
Test suite custom field | TS_CUF_[code] | ❌ | ✅ |
Legend:
[code]
: Value of the "Code" of a custom field[name]
: Parameter name as filled in Squash TM
Availability of the execution ID
TC_EXECUTION_ID
is only available with Squash TM 8.0 or later.
As indicated, Squash TM adds a prefix to the code of the transmitted custom field. Make sure to take it into account.
Refer to the Squash TM documentation for more information about custom fields.
Parameters usage
It is possible, when running Cypress tests, to exploit parameters within it. A parameter can be a test parameter or a global parameter. Squash TM transmits only test parameters. Test parameters and global parameters can be used in the case of a launch from a CI/CD pipeline with the cypress/params
action.
The parameters are available as CYPRESS_VAR
environment variables and can be retrieved using the Cypress.env('VAR')
syntax (see the Cypress documentation). If the same name is used both for a global parameter and a test parameter, the last one is used.
Example
Below is an example of a Cypress test file and the corresponding Squash TM test case automation:
Adding parameters to the test launch command line
You can pass additional parameters to the cypress run
command using the
CYPRESS_EXTRA_OPTIONS
environment variable. Here
is an example of how to define an environment variable in Squash TM and associate
it with the orchestrator.
Some parameters are already defined in the cypress run
command used to
launch tests:
cypress run \
--project "{project_path}" --spec "{spec_path}" \
--config screenshotsFolder="{screenshots_folder_uuid}" --reporter junit \
--reporter-options "mochaFile={report_file_path}" $CYPRESS_EXTRA_OPTIONS
You must avoid passing, via the CYPRESS_EXTRA_OPTIONS
variable, the command line
parameters that conflict with the parameters already used, or the parameters
that impact the generation or alter the path of the reports expected by the orchestrator
(view the report list).
Non-support of the space character on Linux
Squash Orchestrator currently does not support the space character () in the
CYPRESS_EXTRA_OPTIONS
environment variable for tests executed in a Linux execution environment.
Generation of Allure reports with the cypress/cypress action
When using the cypress/cypress action💎 in a workflow, if you want the Cypress test results to appear in the Allure report generated for the workflow, you need to:
1) configure (in the cypress.yaml
configuration file of the cypress provider) a hook to capture the JUnit reports:
apiVersion: opentestfactory.org/v1alpha1
kind: ServiceConfig
current-context: allinone
contexts:
- context:
port: 7789
host: 127.0.0.1
ssl_context: disabled
trusted_authorities:
- /etc/squashtf/squashtf.pub
logfile: cypress.log
enable_insecure_login: true
eventbus:
endpoint: http://127.0.0.1:38368
token: reuse
name: allinone
hooks:
- name: capture JUnit reports
events:
- categoryPrefix: cypress
category: cypress
after:
- uses: actions/get-files
with:
pattern: test-output-*.xml
2) indicate in the workflow to generate a JUnit report per test using the following reporter
and reporter-options
values:
{
"apiVersion": "opentestfactory.org/v1alpha1",
"kind": "Workflow",
"metadata": {
"name": "Cypress"
},
"jobs": {
"execute": {
"runs-on": "cypress",
"steps": [
{
"uses": "actions/checkout@v2",
"with": {
"repository": "https://github.com/my-repo"
}
},
{
"uses": "cypress/cypress@v1",
"with": {
"reporter": "junit",
"reporter-options": "mochaFile=test-output-[hash].xml,toConsole=true",
"headless": "true"
},
"working-directory": "cypressDocCheck"
}
]
}
}
}
💎 This is not necessary for Cypress tests launched from Squash TM or via Squash TM test execution plan retrieval with a workflow.
Supported versions
Squash has been validated with Cypress 8.5.0. Any recent version should work properly.