Dart and Flutter configuration

The Allure Dart and Flutter integration 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.

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.

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.

ALLURE_RESULTS_DIR=build/allure-results dart test

ALLURELABEL*

Adds global labels to every test result.

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

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:

{
  "version": "1.0",
  "tests": [{ "id": "AUTH-1" }, { "selector": "test/auth_test.dart#authentication#login works" }]
}

Run the tests with:

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 override when set
• thread — the current process ID, or the ALLURE_LABEL_thread 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.