Introducing New Build and Parmaterized Test Case Fields

New fields can now be uploaded to Tesults.

Jan 30, 2017

blog-title-image

Recently Tesults added support for two new field types to make your test results data reporting better.

Build

The new build field can be used to associate a test run to a build, version or source control revision number. This is intended to make it easier to identify where problems may have been introduced rather than relying on timestamps.

Parameterized Test Cases

Automated tests frequently include parameterized test cases, where the test suite and test case name may be the same and the only distinguishing feature is the parameters passed into a test case. Tesults now provides full support for these types of parameterized test cases.

Check out the updated docs for complete information about how you can now use these new fields. As always get in contact with us to tell how we could do even better.

Latest Posts

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

How to Report Go Test Results to a Dashboard

How to Report Go Test Results to a Dashboard

Go has no reporter plugin, so reporting go test results means parsing go test -json and uploading the cases yourself. Here is the whole pattern.

How to Report Jest Test Results to a Dashboard

How to Report Jest Test Results to a Dashboard

How to send Jest results somewhere they are kept, viewable by the team, and comparable across runs, without giving up the default reporter

How to View Playwright Test Results in CI

How to View Playwright Test Results in CI

How to get Playwright results out of the CI console and into a durable dashboard, including parallel shards, screenshots, and retained history

What Is a Test Results Dashboard and When Do You Need One

What Is a Test Results Dashboard and When Do You Need One

What a test results dashboard actually does, how it differs from your CI logs and your test framework report, and the point at which a team starts needing one

Diagnosing CI Failures Automatically With an AI Failure Diagnosis API

Diagnosing CI Failures Automatically With an AI Failure Diagnosis API

How to turn a red build into a root cause, a regression list, and a deploy gate without a human reading the logs