DevOps test tool integration
Summarize
Summary of DevOps Test Tool Integration
DevOps test tool integration in ServiceNow enables customers to view unit, functional, and performance test results directly within the DevOps environment. Supported tools include Jenkins, Azure DevOps (ADO), GitHub, GitHub Enterprise, and GitLab, with specific test type compatibility per tool. This integration centralizes test reporting, facilitating better visibility and management of test outcomes across CI/CD pipelines.
Show less
Key Features
- Test Types and Tool Support:
- JUnit is supported across all tools, but GitLab and Jenkins only support JUnit test type integration.
- ADO, GitHub, and GitHub Enterprise support JUnit, NUnit, XUnit, and generic Unit tests.
- Functional test categories include Integration, Regression, Smoke, System, and User Acceptance tests, alongside Performance and Load tests.
- Selenium tests published with TestNG are supported via the Jenkins plugin.
- Test Type Mapping:
- Test type mappings link test types and entities (such as pipelines and steps) to ensure accurate categorization and display of test results.
- Only DevOps Step and Pipeline tables are supported as entities for linking test results.
- Jenkins test file paths can be specified to handle non-standard test reports (e.g., Apache JMeter) using Workflow Studio subflows.
- Custom Payload Transformation:
- Raw or non-standard test payloads (e.g., JMeter) can be transformed using custom Workflow Studio subflows triggered via DevOps Test Subflow Policy decision tables.
- Multiple test types within a single performance test stage can be managed using the DevOps Test Type Policy decision table to ensure proper transformation and reporting.
- Viewing Test Results:
- Test summaries are accessible via the DevOps Test Results module, DevOps change request related lists, and the Pipeline UI Quality tile.
- Standard JSON Payloads for Test Results:
- Functional and performance test results must follow a structured JSON format with attributes such as test counts, durations, pass percentages, and artifact/package/build identifiers.
- Only one attribute combination (packages, artifacts, or build/stage/pipeline) should be sent to associate test results correctly.
- Pipeline and stage names in payloads must correspond exactly to values in the DevOps orchestration pipeline and step tables.
- API Integration:
- Test results can be added to DevOps change requests via the DevOps - POST /devops/tool/{capability} API, supporting all test types.
- Test report XML files can be attached to change requests using the attachment API.
Practical Application for ServiceNow Customers
By configuring test tools within DevOps, customers can consolidate test results from multiple CI/CD tools and test frameworks into ServiceNow. Accurate test type mapping and use of policy decision tables ensure proper transformation and categorization, allowing teams to monitor quality metrics effectively across pipelines. The integration supports automation by leveraging APIs to link test results and attachments to change requests, enhancing traceability and collaboration.
For test tools producing non-standard result formats, customers can implement custom Workflow Studio subflows to transform payloads without modifying existing pipelines. This flexibility allows integration of diverse testing tools such as Apache JMeter alongside traditional unit test frameworks.
Test tool integration lets you view test results in DevOps for Jenkins, Azure DevOps, GitHub, GitHub Enterprise, and GitLab unit, functional, and performance tests.
For GitLab and Jenkins, only JUnit test type integration is supported.
- Selenium tests run and published using TestNG are reported by the Jenkins plugin for ServiceNow DevOps.
- Test type categorization is supported.
- Additional tests results reported by tools, such as Apache JMeter, can be processed in DevOps using custom Workflow Studio subflows (no pipeline changes required).
| Category | Test type |
|---|---|
| Unit | JUnit (default) NUnit XUnit Unit test Note:
You can change the default test type by modifying the [sn_devops.default_test_type] DevOps property. |
| Functional |
|
| Performance | Load |
Test type mapping
The test type mapping connects the test type and entity being tested with the DevOps tool ( module.)
An accurate test type mapping ensures that the test type always appears as intended in the test summary results.
| Field | Description | |
|---|---|---|
| Test type |
|
|
| DevOps Entity Id | Table name | DevOps table name that contains the entity linked to the test results (in the test report payload).
Note: Only DevOps Step and Pipeline tables are supported. |
| Document | Name of the entity specified in the selected table. For example, the name of the step, pipeline, artifact, or package. |
|
Test File Paths (Jenkins tests only) |
Path to the generated test result file on the Jenkins server. This is useful so test reports with attributes that don't conform to JUnit or TestNG implementation, such as JMeter for example, can still be leveraged by DevOps. Separate multiple files by a comma. Note: You must use a Workflow Studio subflow to transform a raw test payload. |
|
| Tool integration | Tool that's running the test. |
|
| DevOps Table | DevOps table that corresponds to the table name in the DevOps Entity Id setting. |
|
Transforming a raw test payload
If there is more than one test type in a performance stage, you can use the DevOps Test Type Policy decision table to configure the test type for each test so the test result payloads are transformed correctly.
| Decision table | Purpose | Configuration |
|---|---|---|
| DevOps Test Subflow Policy | To automatically call a custom subflow that transforms the raw payload received by the tool. Decision inputs:
|
Create a decision that specifies the custom subflow to call when the raw payload is received. Set the conditions to contain fields that would be included in the raw payload. For example, to call Jenkins BZ Performance Test custom subflow: Conditions:
Answer: FLow: Jenkins BZ Performance Test |
| DevOps Test Type Policy | To automatically set test types when more than one type of test is configured in a performance test stage. This is necessary so the results for the second test type get transformed correctly. For example, when both a Load performance test and a JUnit performance test are mapped in the same DevOps step, the JUnit test results won't get formatted correctly unless a decision is created. Decision inputs:
|
Create a decision for each type of test in the performance test stage to set the test type. Load test:
JUnit test:
|
Test summary results
- module (Test Summaries and Performance Test Summaries).
- DevOps change request - Test Results related list.
- DevOps Pipeline UI - Quality tile.
Expected standard JSON Notification capability payload - Test tool
{
"name": "CorpSite-selenium#55",
"duration": 78.802,
"passedTests": 4,
"failedTests": 0,
"skippedTests": 0,
"blockedTests": 0,
"totalTests": 4,
"startTime": "2020-06-30T18:12:31Z",
"finishTime": "2020-06-30T18:12:31Z",
"passingPercent": 100,
// Use Artifact OR Package OR Build + Stage + PipelineName Attributes
Send only one Attribute combination. For example, send Attributes of either Artifact or Package, or the combination of Build + Stage + PipelineName.
If you send more than one Attribute, priority is given in the following order and the low priory one is ignored. For example, if you send attribute for both packages and artifacts, then attribute of package is considered and the attribute of artifacts is ignored.
1.packages
2.artifcats
3.buildNumber + stageName + pipelineName
"packages": [{"name": "CorpSite-pkg1"}],
"artifacts": [{"name": "CorpSite-artifact", "version": "1.0.0"}],
"buildNumber": "55",
"stageName": "test",
"pipelineName": "CorpSite-selenium",
}
Notes:
- The pipelineName attribute value must be same as the value in the Orchestration pipeline field of the Pipeline [sn_devops_pipeline] table.
- The stageName attribute value must be same as the value in the Orchestration stage field of the Step [sn_devops_step] table.{
"name": "Performance Tests",
"url": "http://abc.com",
"startTime": "2020-06-30T18:12:31Z",
"finishTime": "2020-06-30T18:12:31Z",
"duration": 78.802,
"maximumVirtualUsers": "",
"throughput": "",
"maximumTime": "",
"minimumTime": "",
"averageTime": "",
"ninetyPercent": "",
"standardDeviation": "",
// Use Artifact OR Package OR Build + Stage + PipelineName Attributes
Send only one Attribute combination. For example, send Attributes of either Artifact or Package, or the combination of Build + Stage + PipelineName.
If you send more than one Attribute, priority is given in the following order and the low priory one is ignored. For example, if you send attribute for both packages and artifacts, then attribute of package is considered and the attribute of artifacts is ignored.
1.packages
2.artifcats
3.buildNumber + stageName + pipelineName
"packages": [{"name": "CorpSite-pkg1"}],
"artifacts": [{"name": "CorpSite-artifact", "version": "1.0.0"}],
"buildNumber": "55",
"stageName": "test",
"pipelineName": "CorpSite-Performance",
}
Notes:
- The pipelineName attribute value must be same as the value in the Orchestration pipeline field of the Pipeline [sn_devops_pipeline] table.
- The stageName attribute value must be same as the value in the Orchestration stage field of the Step [sn_devops_step] table.