Go Testing configuration

The allure-go integration is configured through environment variables.

ALLURE_RESULTS_DIR

Overrides the default directory where the integration writes Allure results.

When unset, results are written to allure-results, resolved relative to the working directory of each test binary. Go runs each test binary in its package's source directory, so in a module with multiple test packages, set this variable to an absolute path to collect all results in one directory:

ALLURE_RESULTS_DIR=$PWD/allure-results go 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" \
go test ./...

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

Label names are normalized to Allure-style lower camel case: the name after the prefix is lowercased, and underscores and hyphens start a new capitalized word. For example, ALLURE_LABEL_MODULE=commons becomes the label module=commons, and ALLURE_LABEL_PARENT_SUITE=runtime becomes parentSuite=runtime. Variables with empty values are ignored.

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": "123" },
    { "selector": "example/login_test.go/TestLogin/logs_in_with_valid_credentials" }
  ]
}

Run the tests with:

ALLURE_TESTPLAN_PATH=./testplan.json go test ./...

Selection works as follows:

• entries with id match tests that declare an Allure ID, for example via allure.WithAllureID("123") or a @allure.id=123 tag,
• entries with selector match the test's full name: the test file's path relative to the module root, followed by the full Go test name, joined with /. For example, a test declared as allure.Test(t, "logs in", ...) inside TestLogin in example/login_test.go has the full name example/login_test.go/TestLogin/logs_in.

Tests not selected by the plan are skipped with t.Skip before their body runs. Only metadata known before the test body runs participates in the selection: static allure.With... options and ALLURE_LABEL_* variables. An Allure ID set at runtime with a.Label(...) is too late to affect filtering.

If ALLURE_TESTPLAN_PATH is unset or the file contains no test entries, all tests run normally. If the file cannot be read or contains invalid JSON, each reported test fails and is written to the results as broken, so a misconfigured test plan does not silently run or skip the whole suite.

Automatic labels and identifiers

The integration adds two labels to every test result automatically:

• language = go
• framework = go-test

It also derives suite labels from the test file's path relative to the module root (the directory containing go.mod):

• a single path segment becomes suite,
• two segments become parentSuite and suite,
• three or more segments become parentSuite, suite, and subSuite (the remaining segments joined with >).

For example, a test in commons/gotest/allure_test.go gets parentSuite = commons, suite = gotest, and subSuite = allure_test.go. Setting any of the parentSuite, suite, or subSuite labels explicitly — via options such as allure.WithSuite(...), runtime calls, or ALLURE_LABEL_* variables — disables the automatic derivation entirely.

Finally, unless set explicitly, each result's testCaseId is computed from the test's full name, and its historyId is computed from the testCaseId and the test's parameters (parameters marked as excluded do not affect it). These identifiers keep retries, history, and trend charts stable across runs.