Skip to content
Allure report logoAllure Report
Main Navigation ModulesDocumentationStarter Project

English

Español

English

Español

Appearance

Sidebar Navigation

Allure 3

Install & Upgrade

Install Allure

Upgrade Allure

Configure

Create Reports

How to generate a report

How to view a report

Improving readability of your test reports

Improving navigation in your test report

Reading Allure charts

Migrate from Allure 2

Allure 2

Install & Upgrade

Install for Windows

Install for macOS

Install for Linux

Install for Node.js

Upgrade Allure

Create Reports

How to generate a report

How to view a report

Improving readability of your test reports

Improving navigation in your test report

Features

Agent Mode

Test steps

Attachments

Test statuses

Assertion diffs

Sorting and filtering

Environments

Multistage Builds

Categories

Visual analytics

Test stability analysis

History and retries

Self-hosted storage

Quality Gate

Global Errors and Attachments

Timeline

Export to CSV

Export metrics

Guides

JUnit 5 parametrization

JUnit 5 & Selenide: screenshots and attachments

JUnit 5 & Selenium: screenshots and attachments

Setting up JUnit 5 with GitHub Actions

Pytest parameterization

Pytest & Selenium: screenshots and attachments

Pytest & Playwright: screenshots and attachments

Pytest & Playwright: videos

Playwright parameterization

Publishing Reports to GitHub Pages

Deploying Self-Hosted Storage with Docker

Deploying Self-Hosted Storage on Cloudflare Workers

Allure Report 3: XCResults Reader

How it works

Overview

Glossary

Test result file

Container file

Categories file

Environment file

Executor file

History files

Test Identifiers

Integrations

Azure DevOps

Bamboo

GitHub Action

Gradle

Jenkins

JetBrains IDEs

Maven

TeamCity

Visual Studio Code

Frameworks

AVA

Getting started

Configuration

Reference

Axios

Getting started

Configuration

Reference

Behat

Getting started

Configuration

Reference

Behave

Getting started

Configuration

Reference

Bun

Getting started

Configuration

Reference

Chai

Getting started

Reference

Codeception

Getting started

Configuration

Reference

CodeceptJS

Getting started

Configuration

Reference

Cucumber.js

Getting started

Configuration

Reference

Cucumber-JVM

Getting started

Configuration

Reference

Cucumber.rb

Getting started

Configuration

Reference

Cypress

Getting started

Configuration

Reference

Dart and Flutter

Getting started

Configuration

Reference

Diesel

Getting started

Configuration

Reference

Fetch

Getting started

Configuration

Reference

Go

Getting started

Configuration

Reference

Jasmine

Getting started

Configuration

Reference

JBehave

Getting started

Configuration

Reference

Jest

Getting started

Configuration

Reference

JUnit 4

Getting started

Configuration

Reference

JUnit 5

Getting started

Configuration

Reference

Mocha

Getting started

Configuration

Reference

Newman

Getting started

Configuration

Reference

Node.js Test Runner

Getting started

Configuration

Reference

NUnit

Getting started

Configuration

Reference

PHPUnit

Getting started

Configuration

Reference

Playwright

Getting started

Configuration

Reference

Playwright Java

Getting started

Configuration

Reference

pytest

Getting started

Configuration

Reference

Pytest-BDD

Getting started

Configuration

Reference

Reqnroll

Getting started

Configuration

Reference

Reqwest

Getting started

Configuration

Reference

REST Assured

Getting started

Configuration

Robot Framework

Getting started

Configuration

Reference

Rust Cargo Test

Getting started

Configuration

Reference

RSpec

Getting started

Configuration

Reference

Selenide

Getting started

Configuration

Reference

Selenium BiDi

Getting started

Configuration

Reference

SpecFlow

Getting started

Configuration

Reference

Spock

Getting started

Configuration

Reference

TestCafe

Getting started

Configuration

Reference

TestNG

Getting started

Configuration

Reference

Vitest

Getting started

Configuration

Reference

WebdriverIO

Getting started

Configuration

Reference

xUnit.net

Getting started

Configuration

Reference

On this page

Rust Cargo Test configuration ​

The allure-cargotest integration is configured through environment variables.

ALLURE_RESULTS_DIR ​

Overrides the default directory where #[allure_test] writes Allure results.

When unset, allure-cargotest uses target/allure-results.

bash
ALLURE_RESULTS_DIR=./allure-results cargo test

ALLURE_HOST_NAME ​

Overrides the host label that allure-cargotest adds automatically.

If this variable is not set, the integration tries to detect the host name from the current machine.

bash
ALLURE_HOST_NAME=ci-linux-01 cargo test

ALLURE_THREAD_NAME ​

Overrides the thread label that allure-cargotest adds automatically.

If this variable is not set, the integration uses the current thread name or thread ID.

bash
ALLURE_THREAD_NAME=worker-1 cargo test

ALLURE_LABEL_* ​

Adds global labels to every test result.

Any environment variable whose name starts with ALLURE_LABEL_ becomes an Allure label. For example:

bash
ALLURE_LABEL_epic="Web interface" \
ALLURE_LABEL_owner="QA Team" \
cargo test

This applies the epic and owner labels to every test in the run.

allure.label.* ​

Adds global labels using the alternative naming scheme that some CI tools already use.

Any environment variable whose name starts with allure.label. is treated the same way as ALLURE_LABEL_*.

bash
allure.label.layer=e2e cargo test

ALLURE_TESTPLAN_PATH ​

Points to a JSON file that defines which tests should run.

The file uses the standard Allure test plan shape:

json
{
  "version": "1.0",
  "tests": [{ "selector": "auth::tests::login_works" }]
}

Run the tests with:

bash
ALLURE_TESTPLAN_PATH=./testplan.json cargo test

Entries with selector match the full Rust test name, including its module path, and work with #[allure_test].

WARNING

Entries with id are intended to match tests that expose an explicit Allure ID (for example via #[allure_test(id = "AUTH-1")]), but #[allure_test] does not currently forward its id into test-plan matching, so id entries have no effect on macro-based tests — use selector entries for them instead. id matching does work for integrations that call CargoTestReporter::run_test_with_metadata directly with an explicit allure_id.

If ALLURE_TESTPLAN_PATH is unset, the file does not exist, or the JSON is malformed, allure-cargotest skips filtering and runs the tests normally.

ALLURE_LOG_ASSERTS ​

Controls whether assert!, assert_eq!, assert_ne!, debug_assert!, debug_assert_eq!, and debug_assert_ne! calls inside #[allure_test] and #[step] function bodies are logged as Allure steps.

Assertion logging is enabled by default. Set it to false to disable it for a run, overriding any package-level setting:

bash
ALLURE_LOG_ASSERTS=false cargo test

You can also disable assertion logging for a whole package with Cargo metadata instead of an environment variable — see log_asserts below.

Configure labels in Cargo.toml ​

Use Cargo package metadata to add labels for local and CI runs without environment variables. A package is the Cargo package defined by the relevant Cargo.toml.

Add labels for all tests in a package ​

Add labels under [package.metadata.allure.labels]:

toml
[package.metadata.allure.labels]
a = "a-value"
b = ["b-value1", "b-value2"]

This adds a=a-value, b=b-value1, and b=b-value2 to every #[allure_test] in the package. String array values add the same label multiple times.

You can also disable assertion logging for the whole package here:

toml
[package.metadata.allure]
log_asserts = false

Add labels for only some Rust modules ​

Add one [[package.metadata.allure.modules]] entry per Rust module path. The module value matches the current Rust module_path!() exactly, or any module below it.

toml
[[package.metadata.allure.modules]]
module = "org::example"
labels = { a = "a-value", b = ["b-value1", "b-value2"] }

This applies to tests whose module path is org::example, org::example::api, org::example::api::v1, and so on.

For integration tests in tests/api.rs, the test file is its own crate, so module paths usually start with the file stem:

toml
[[package.metadata.allure.modules]]
module = "api::org::example"
labels = { a = "a-value" }

Add labels for only test files ​

Add one [[package.metadata.allure.modules]] entry per file and use path. The path is relative to the package root and uses the same element-wise file path that appears in titlePath.

toml
[[package.metadata.allure.modules]]
path = "tests/payments.rs"
labels = { a = "a-value", b = ["b-value1", "b-value2"] }

This applies to every #[allure_test] in tests/payments.rs. You can also match a source file or a directory:

toml
[[package.metadata.allure.modules]]
path = "src/payments.rs"
labels = { component = "payments" }

[[package.metadata.allure.modules]]
path = "tests/api/"
labels = { layer = "api" }

The directory form (a path ending in /) matches every test file whose relative path starts with that directory.

Automatic labels added by allure-cargotest ​

When you use #[allure_test] or CargoTestReporter, allure-cargotest adds a few labels automatically:

  • language = rust
  • framework = cargo-test
  • host
  • thread

It also derives suite labels from the Rust module path:

  • a single module segment becomes suite,
  • two segments become parentSuite and suite,
  • three or more segments become parentSuite, suite, and subSuite.

Explicit calls to allure.parent_suite(...), allure.suite(...), or allure.sub_suite(...) override the automatically derived labels with the same name.

Pager
Previous pageGetting started
Next pageReference
Powered by

Subscribe to our newsletter

Get product news you actually need, no spam.

Subscribe
Allure TestOps
  • Overview
  • Why choose us
  • Cloud
  • Self-hosted
  • Success Stories
Company
  • Documentation
  • Blog
  • About us
  • Contact
  • Events
© 2026 Qameta Software Inc. All rights reserved.
A Markdown version of this page is available at /docs/rust-configuration.md