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.

tesults-test Rust test reporting

tesults-test is a Rust crate that replaces #[test] with #[tesults_test::test] to add enhanced test reporting to Tesults — timing, descriptions, steps, custom fields, and file uploads — with no changes to how you run tests.

note
tesults-test works for: Rust's built-in test framework (#[test]), cargo-nextest, and rstest.

How it works

The #[tesults_test::test] proc macro wraps each test function to capture timing and pass/fail automatically. When the test binary exits, all results are uploaded to Tesults in a single request. Optionally call tesults_test::description(), tesults_test::step(), and other helpers inside any test body for richer reporting.

Installation

Add tesults-test to your [dev-dependencies] in Cargo.toml:

[dev-dependencies]
tesults-test = "1"

Or with cargo add:

cargo add --dev tesults-test

Configuration

Replace #[test] with #[tesults_test::test] — no imports needed:

#[cfg(test)]
mod tests {
  #[tesults_test::test]
  fn it_adds() {
    assert_eq!(2 + 2, 4);
  }
}

Set TESULTS_TARGET to your target token and run tests as usual:

TESULTS_TARGET=token cargo test

Basic configuration complete

That's it. Results are uploaded once after all tests complete. If TESULTS_TARGET is not set, nothing is uploaded and your tests run as normal.

Config file (optional)

Keep tokens out of scripts by using a key name and pointing to a config file:

TESULTS_TARGET=my-target TESULTS_CONFIG=/path/to/tesults.cfg cargo test
tesults.cfg
# Tesults target tokens
my-target = eyJ0eXAiOiJ...
staging = eyJ0eXAiOiK...

cargo-nextest

cargo-nextest is a popular alternative test runner for Rust. tesults-test is compatible with nextest — run your tests with cargo nextest run and set TESULTS_TARGET as usual.

TESULTS_TARGET=token cargo nextest run

rstest

rstest adds fixture-based and parameterized testing to Rust. Since rstest generates standard #[test] functions under the hood, tesults-test is fully compatible — use #[tesults_test::test] alongside rstest's own attributes:

use rstest::rstest;

#[tesults_test::test]
#[rstest]
#[case(1, 2, 3)]
#[case(4, 5, 9)]
fn test_addition(#[case] a: i32, #[case] b: i32, #[case] sum: i32) {
  assert_eq!(a + b, sum);
}

Enhanced reporting

Call these helpers inside a test body to enrich the result sent to Tesults:

#[tesults_test::test]
fn checkout_flow() {
  tesults_test::description("Verifies the full checkout flow");
  tesults_test::custom("env", "staging");
  tesults_test::custom("build", "1.4.2");

  tesults_test::step("open cart", "pass", "Cart page loads", "");
  tesults_test::step("enter address", "pass", "Address form submits", "");

  tesults_test::file("/tmp/screenshot.png");

  assert!(place_order());
}

tesults_test::description(text)Optional

Set a free-text description for the test result shown in Tesults.


tesults_test::custom(key, value)Optional

Attach a custom key-value field to the test result. Call multiple times for multiple fields.


tesults_test::step(name, result, desc, reason)Optional

Record a named step with its own pass/fail result. result must be "pass" or "fail". Call multiple times to build a step list.


tesults_test::file(path)Optional

Attach a file (screenshot, log, etc.) to the test result. The file is uploaded to Tesults. Call multiple times to attach multiple files.

#[should_panic]

Works exactly as with #[test]. tesults-test records the correct pass/fail and re-panics so the test runner sees the expected behavior:

#[tesults_test::test]
#[should_panic(expected = "overflow")]
fn panics_on_overflow() {
  let _: u8 = 200u8 + 200u8;
}

Suite names

The suite for each test is derived automatically from its Rust module path. A test in my_crate::tests is reported under suite tests. Tests in integration test files (tests/my_test.rs) use the file stem as the suite name.

Build

TESULTS_BUILD_NAMEOptional

Use this to report a build version or name for reporting purposes.

TESULTS_BUILD_NAME=1.0.0 cargo test

TESULTS_BUILD_RESULTOptional

Use this to report the build result, must be one of [pass, fail, unknown].

TESULTS_BUILD_RESULT=pass cargo test

TESULTS_BUILD_DESCRIPTIONOptional

Use this to report a build description for reporting purposes.

TESULTS_BUILD_DESCRIPTION="Release build" cargo test

TESULTS_BUILD_REASONOptional

Use this to report a build failure reason.

TESULTS_BUILD_REASON="failed to compile crate foo" cargo test

Result Interpretation

Result interpretation is not currently supported by this integration. If you are interested in support please contact help@tesults.com.

Go to the Configuration menu.

Configuration menu

Select Build Consolidation.

When executing multiple test runs in parallel or serially for the same build or release, results are submitted to Tesults separately and multiple test runs are generated on Tesults. This is because the default behavior on Tesults is to treat each results submission as a separate test run.

This behavior can be changed from the configuration menu.

Build Consolidation

Click 'Build Consolidation' from the Configuration menu to enable and disable consolidation for a project or by target.

When build consolidation is enabled multiple test runs submitted at different times, with the same build name, will be consolidated into a single test run by Tesults automatically.

This is useful for test frameworks that run batches of test cases in parallel. If you do not have a build name to use for consolidation, consider using a timestamp set at the time the test run starts.

Build Replacement

When build consolidation is enabled, an additional option, build replacement can optionally be enabled too. Just as with build consolidation, when multiple test runs are submitted with the same build name the results are consolidated, but with replacement enabled, if there are test cases with the same suite and name received multiple times, the last received test case replaces an existing test case with the same suite and name. This may be useful to enable in situations where test cases are re-run frequently and you do not want new test cases to be appended and instead want them to replace older test cases. This option is generally best left disabled, unless test cases are often re-run for the same build and you are only interested in the latest result for the run.

Dynamically created test cases

If you dynamically create test cases, such as test cases with variable values, we recommend that the test suite and test case names themselves be static. Provide the variable data information in the test case description or other custom fields but try to keep the test suite and test name static. If you change your test suite or test name on every test run you will not benefit from a range of features Tesults has to offer including test case failure assignment and historical results analysis. You need not make your tests any less dynamic, variable values can still be reported within test case details.

Proxy servers

Does your corporate/office network run behind a proxy server? Contact us and we will supply you with a custom API Library for this case. Without this results will fail to upload to Tesults.

Have questions or need help? Contact us