Download the PHP package qase/php-commons without Composer

Qase PHP Commons

This module is an SDK for developing test reporters for Qase TMS. You should use it if you're developing your own test reporter for a special-purpose framework.

To report results from tests using a popular framework or test runner, don't install this module directly and use the corresponding reporter module instead:

• PHPUnit

Installation

Configuration

Qase PHP Reporters can be configured in multiple ways:

• using a config file qase.config.json
• using environment variables

All configuration options are listed in the table below:

Example qase.config.json config

Environment Variables Example

You can also configure configurations using environment variables:

The QASE_TESTOPS_CONFIGURATIONS_VALUES should be a comma-separated list of key=value pairs.

Result Delivery

Results are sent to Qase in batches of testops.batch.size. A batch stays in the reporter buffer until the API confirms it, so a failed request never destroys the results it was carrying:

• Transient failures (connection errors, 408, 429, 5xx) are retried testops.api.retries times with an exponential backoff. When a 429 response carries a Retry-After header, that value is used instead of the computed delay.
• Permanent failures (400, 401, 403, 404, 413, 422, 507) are not retried — they fail the same way on a second attempt.
• Retrying is safe because every result carries an idempotency key, so a batch that was accepted but whose response was lost is not duplicated.
• If a batch is still undeliverable after the retries, the reporter logs how many results could not be sent, hands them to the fallback reporter, and does not complete the test run — an incomplete run is a visible signal that the data in Qase is partial.

How Configurations Work

Configurations in Qase TestOps work as follows:

• name field represents the configuration group (e.g., "browser", "environment")
• value field represents the configuration item within that group (e.g., "chrome", "staging")
• When createIfNotExists is true, the system will:
  1. Create a configuration group with the specified name if it doesn't exist
  2. Create a configuration item with the specified value in that group
  3. Associate the configuration item ID with the test run

Status Filtering

You can filter out test results with specific statuses using the statusFilter configuration option:

Config file example:

Environment variable example:

Available statuses:

• passed - Test passed successfully
• failed - Test failed
• skipped - Test was skipped
• blocked - Test was blocked
• untested - Test was not tested

When statusFilter is configured, results with the specified statuses will be excluded from being sent to Qase TestOps.

Status Mapping

You can map (transform) test result statuses using the statusMapping configuration option. This is useful when you need to convert statuses from your testing framework to match Qase's expected statuses.

Config file example:

Environment variable example:

Available statuses for mapping:

• passed - Test passed successfully
• failed - Test failed due to assertion error
• skipped - Test was skipped
• blocked - Test was blocked
• invalid - Test failed due to non-assertion error (network issues, syntax errors)

How status mapping works:

• Status mapping is applied before status filtering
• Mapping is applied to both test results and individual test steps
• Invalid mappings are ignored with a warning message
• Mapping is applied centrally for all reporters regardless of testing framework
• Changes are logged for debugging purposes

Example scenarios:

1. Convert invalid to failed: Map invalid status to failed to treat infrastructure issues as test failures
2. Convert skipped to passed: Map skipped status to passed to include skipped tests in pass rate calculations
3. Multiple mappings: Apply different mappings for different statuses in a single configuration

Validation rules:

• Source and target statuses must be valid (from the list above)
• Source and target cannot be the same (redundant mappings are ignored)
• Case-sensitive validation (e.g., PASSED is invalid, use passed)
• Non-string values are ignored

External Issue Integration

You can link test runs to external issues (like Jira tickets) by configuring the externalLink option:

Config file example:

Environment variables example:

Supported external issue types:

• jiraCloud - For Jira Cloud instances
• jiraServer - For Jira Server/Data Center instances

When an external link is configured, the system will automatically associate the test run with the specified external issue after the run is created.

Technical Details:

• External issue functionality uses the Qase API v1 client
• The system automatically maps internal enum values to API enum values:
  • jiraCloud → jira-cloud
  • jiraServer → jira-server
• API calls are made using the official Qase API client models (RunexternalIssues and RunexternalIssuesLinksInner)