The Tesults web app is designed for desktop browsers. Sign up and configure your project on a laptop or desktop. Use the iOS app or Android app to view results on the go.

Test reporting and continuous integration and deployment

Make deployment decisions and report test failures in your continuous deployment pipelines with Tesults

blog-title-image

When triggering tests in a continuous integration and deployment (CI/CD) pipeline there may be times you want to make a deployment decision based on test results. You may also want to share build and test failures with your team. This post explains how to do this with Tesults.

The assumption for this post is that you have already signed up, created a project and integrated your tests to report results with Tesults. If you have not please take look at getting started. You should also have your continuous integration system set up to trigger your tests at the appropriate time in your build pipeline.

To make a deployment decision based on test results, or to share build and test failures, your continuous integration system needs to be able to access the relevant test results for the current build. This is done using the Tesults API.

To make it easier to retrieve results data it is recommended you pass in a build name and build result as part of your Tesults integration. This build name should also be available to your continuous integration pipeline. Instructions on how to pass in build information to Tesults are dependent on the test framework integration or language library you are using, please review the documentation for your language or test framework. It is possible to retrieve results without using a build name but this is less straight forward because it requires checking the timestamp for the test run to determine which results you are interested in.

Create a Tesults API token

Go to the configuration menu and select API Token from the menu.

create-api-token-1

Click the Create API Token button to create an API token.

create-api-token-2

Copy the token for use with API requests.

Retrieve results data

Utilize the /api/results endpoint (reference documentation) to retrieve results data after your test run step in the continuous integration pipeline has completed. To do this make a GET request to https://www.tesults.com/api/results. Pass your API token as an authorization header and specify the target id for which to fetch results.

A curl request to fetch data looks like this:

curl https://www.tesults.com/api/results
?target=target_id&build=build_name;
-H "Authorization: Bearer token"

Replace token with the API token
Replace target_id with a target ID
Replace build_name with a build name

The request above assumes you are using a build name (any string value) to retrieve results. If you are not using a build name, omit the build parameter to instead fetch the latest results data for the target. You can utilize the limit parameter to fetch more than one set of results. Please view the Results API documentation for a full list of parameters. View Targets API documentation to learn how to retrieve target IDs.

A successful response will retrieve results data:

{
    "data": {
        "code": 200,
        "message": "Success",
        "results":{
            "runs": [
                {
                    "created_time": 1631398688540,
                    "pass": 149,
                    "total": 150,
                    "build_name": "1.0.0",
                    "build_result": "pass",
                    "build_raw_result": "passed",
                    "cases": [
                        {
                            "name": "Sign in successfully",
                            "desc": "Signs in to site",
                            "suite": "Authentication",
                            "result": "pass",
                            "duration": 11122000,
                            "num": 0,
                            "hash": "7c95f9b7-578d92c19fdd",
                            "_CustomField": "Custom value",
                            "params": {
                                "terrain": "land",
                                "climate": "warm",
                                "temperature": "25C"
                             },
                            "files": [
                                "screenshot1.png", "test.log"
                            ],
                            "files_base_path": "/files/base/path"
                        },
                        {... more test cases}
                    ]
                ]
            },
           "cursor": cursor_value
       }
}

Parse the JSON and retrieve the run object. Use the pass and total fields to determine if all test cases passed and if you want more detailed information on specific failures retrieve the cases array from the response object.

What you ultimately base a deployment decision on is up to you and your team. This may be as simple as ensuring all tests have passed (pass == total) or you may have additional checks such as ensuring that the total number of test cases is larger than zero. Whatever the criteria you use you now have the data you need to make an informed deployment decision and provide success and failure feedback.

Please contact help@tesults.com if you have questions or require assistance.

- Tesults Team

Test automation reporting and failure intelligence

Consolidated test reporting for engineering teams. Store, track, and understand test results across every run and system.

Latest Posts

How to Group Failing Tests by Root Cause
How to Group Failing Tests by Root Cause
Why a flat list of failures is the wrong thing to triage, and how grouping failures by their underlying cause turns twenty red tests into a few real problems
How to Share Test Results With Your Team
How to Share Test Results With Your Team
Why screenshotting results into chat does not scale, and how to give a whole team live access to test results with roles, notifications, and one shared dashboard
How to Detect Test Regressions Between Builds
How to Detect Test Regressions Between Builds
How to find exactly which tests newly failed from one build to the next, instead of comparing two runs by eye, and tell a real regression from a flake
Why Do Flaky Tests Only Fail in CI
Why Do Flaky Tests Only Fail in CI
The CI conditions that turn a test flaky when it never flakes locally, and how to confirm a CI-only failure is flakiness rather than a real bug
Why Do Tests Pass on Retry but Fail the First Time
Why Do Tests Pass on Retry but Fail the First Time
What a test passing on retry is really telling you, why automatic retries hide flakiness rather than fix it, and how to see the pattern across runs
Why Cypress Tests Pass Locally but Fail in CI
Why Cypress Tests Pass Locally but Fail in CI
The environment differences that cause Cypress failures in CI, and how to tell a real bug from an environment flake
How to Track Test Pass Rate Over Time
How to Track Test Pass Rate Over Time
Why a single run cannot tell you if your test suite is getting healthier or worse, and how to track pass rate as a trend across runs so you can see the direction
How to Report WebdriverIO Test Results to a Dashboard
How to Report WebdriverIO Test Results to a Dashboard
Send WebdriverIO results somewhere durable and team-visible using the Tesults service, with the wdio.conf.js setup, enhanced reporting, and parallel run consolidation
How to Report Cypress Test Results to a Dashboard
How to Report Cypress Test Results to a Dashboard
Send Cypress results somewhere durable and team-visible using the Cypress Module API, with screenshots and videos attached and runs consolidated across CI
Why Playwright Tests Pass Locally but Fail in CI
Why Playwright Tests Pass Locally but Fail in CI
The real reasons Playwright tests go green on your machine and red in CI, how to debug each one, and how to tell a genuine failure from an environment flake
How to Detect and Handle Flaky Tests
How to Detect and Handle Flaky Tests
What makes a test flaky, how to detect flaky tests automatically instead of by memory, and how to handle them without disabling coverage
How to Report Vitest Test Results to a Dashboard
How to Report Vitest Test Results to a Dashboard
Send Vitest results somewhere durable and team-visible, with the setup details specific to Vitest, so multiple test jobs consolidate into one history you can act on