---
title: Dart and Flutter configuration
description: Configuration options for the Allure Dart and Flutter integration | Change the results directory | Set global labels | Select tests via a test plan
---

# Dart and Flutter configuration

The [Allure Dart and Flutter integration](/docs/dart/) is configured through an optional `allure-dart.yaml` config file and a set of environment variables. Where both define the same setting, such as the results directory, the environment variable wins.

## allure-dart.yaml

Sets checked-in project defaults: the results directory, labels applied to every test, and environment information for the report.

The integration searches for `allure-dart.yaml` (or `allure-dart.yml`) from the current working directory upward, stopping after it checks the directory that contains `pubspec.yaml`. This way, each package in a repository can have its own config file.

```yaml
resultsDir: build/allure-results
labels:
  module: checkout
  layer:
    - api
environment:
  target: local
```

The supported keys:

- `resultsDir` (alias: `resultsDirectory`) — the directory where the result files are written.
- `labels` — labels added to every test result in the run. Either a map of label names to values (a list value adds one label per item), or a list of `{name: ..., value: ...}` entries.
- `environment` — a map of key-value pairs written to `environment.properties` in the results directory and shown on the report's Environment widget.

## ALLURE_CONFIG

Points to an explicit config file, instead of searching for `allure-dart.yaml` in the directory tree. The path can be absolute or relative to the current working directory.

```bash
ALLURE_CONFIG=./configs/allure-ci.yaml dart test
```

If the file does not exist, the integration throws an error.

## ALLURE_RESULTS_DIR

Overrides the directory where the integration writes Allure results. This takes precedence over `resultsDir` from the config file.

When neither is set, the integration uses `allure-results` in the current working directory.

```bash
ALLURE_RESULTS_DIR=build/allure-results dart 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" \
dart test
```

This applies the `epic` and `owner` labels to every test in the run. The name after the `ALLURE_LABEL_` prefix is used verbatim (case-sensitive) — prefer Allure’s usual names (`epic`, `owner`, `parentSuite`, …). `ALLURE_LABEL_host` and `ALLURE_LABEL_thread` are special-cased: instead of adding a second, conflicting label, they override the automatic `host` and `thread` values described below.

## 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": [{ "id": "AUTH-1" }, { "selector": "test/auth_test.dart#authentication#login works" }]
}
```

Run the tests with:

```bash
ALLURE_TESTPLAN_PATH=./testplan.json dart test
```

Selection works as follows:

- entries with `id` match tests that declare an Allure ID, for example via the `@allure.id:AUTH-1` inline marker,
- entries with `selector` match the test's full name — the test file path relative to the package root, the group names, and the test name, joined with `#`.

How excluded tests are handled depends on the integration style:

- with the drop-in `test`, `group`, and `testWidgets` wrappers, excluded tests are declaration-skipped: the body does not run, and no Allure result is written (unlike a drop-in `skip: true`, which is reported as skipped),
- with `installAllure()` and the original framework imports, excluded tests still run, but their results are not written to the results directory.

If `ALLURE_TESTPLAN_PATH` is unset, the file does not exist, or the JSON is malformed, the integration prints a warning, skips filtering, and runs the tests normally. An empty `"tests": []` list is valid and selects no tests.

## Automatic labels and identifiers

The integration adds a few labels to every test automatically:

- `language` = `dart`
- `framework` = `dart-test`, `flutter-test`, or `flutter-integration-test`, depending on the adapter and the active Flutter binding
- `host` — the local host name, or the [`ALLURE_LABEL_host`](#allure-label) override when set
- `thread` — the current process ID, or the [`ALLURE_LABEL_thread`](#allure-label) override when set
- `package` — the test file path relative to the package root
- `testClass` — the innermost group name, or the test file name when the test is not in a group
- `testMethod` — the test name

It also derives suite labels from the `group()` hierarchy:

- a single group becomes `suite`,
- two nested groups become `parentSuite` and `suite`,
- three or more nested groups become `parentSuite`, `suite`, and `subSuite` (the remaining group names joined with `` ` > ` ``).

Explicit calls to `allure.parentSuite(...)`, `allure.suite(...)`, or `allure.subSuite(...)` override the automatically derived labels.

Finally, the integration derives stable identifiers used for history and retries:

- `testCaseId` — a hash of the test's full name,
- `historyId` — a hash of the test's full name and its non-excluded parameter values, so that the same test with different parameters is tracked as separate history entries.

Both can be overridden from the test body via `allure.testCaseId(...)` and `allure.historyId(...)`.

When `package:test` retries a test (`retry: N`), each attempt is written as its own result, and all attempts share the same `testCaseId`/`historyId` — the report groups them as retries of one test. Every attempt after the first carries an excluded `retry` parameter with the 1-based attempt number, so it doesn't affect the shared history ID.