Skip to content

Automation with Postman

Test reference in Squash TM

Info

The result of each executed Squash TM test case is calculated by taking into account the individual results of each test included in the bound collection file or in a specific folder level of the collection:

  • 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 has an Error status, the status of the execution will be Failed.

  • If all tests succeed, the status of the execution will be Success.

In order to bind a Squash TM test case to a Postman automated test, the content of the Automated test reference field of the Automation block of a test case must have the following format:

[1] / [2] # [3] # [4]

With:

  • [1]: Name of the project on the source code repository.

  • [2]: Path and name of the Postman collection file, from the root of the project (with the .postman_collection.json extension).

  • [3]: Name of a specific folder containing requests in the Postman collection file (Newman's --folder option). This parameter is optional.

  • [4]: Name of a specific request to parse for which you want to obtain a particular result. This parameter is optional.

Automated test reference and execution

The request [4] precision in the test reference has no impact on the execution, but only on test result determination.
So, even when defining the specific level of the request, all requests defined in the folder will be executed (this means, for example, that if several Squash TM test cases point toward the same folder but toward different requests, then all the requests of the folder will be executed several times).
The test reports include the traces of all executed requests. But, only the Error / Failed / Success status corresponding to the specific request is used to determinate the test case result.

Unicity of the specified folder

If the root directory of the project contains several folders with the name [3], Newman will only execute the first found one. So, it is strongly advised to use unique names for the deepest directories.

Nature of the exploitable Squash TM parameters

The exploitable Squash TM parameters in a Postman script will differ depending on whether you're using the Community or Premium version of Squash DEVOPS.

Here is a table showing the exploitable parameters:

Nature Key Community Premium
Name of the dataset DSNAME OK OK
Dataset parameter DS_[name] OK OK
Test case reference TC_REF OK OK
Test case custom field TC_CUF_[code] OK OK
Iteration custom field IT_CUF_[code] KO OK
Campaign custom field CPG_CUF_[code] KO OK
Test suite custom field TS_CUF_[code] KO OK

Legend:

  • [code]: Value of the "Code" of a custom field
  • [name]: Parameter name as filled in Squash TM

Squash TM parameters usage

When executing a Squash TM automated test case with Postman, it is possible to exploit the Squash TM parameters inside the test.

In order to achieve this, you'll have to follow these steps:

  • Create custom fields in Squash TM and bind them to the project bearing the test plan to execute.

  • Make sure that the code fields of the parameters correspond to the names of the existing environment variables present in the Postman requests.

Info

Squash TM adds a prefix to the code of the transmitted custom field. Make sure to take it into account.
Please refer to the Squash TM documentation for more information.

Below is an example of a Postman collection file and the corresponding Squash TM test case automation:

postman-params-1

postman-params-2

postman-params-3

postman-params-4

Supported versions

Squash AUTOM and Squash DEVOPS have been validated with Postman 8.12.1. Any recent version should work properly.

Back to top