After upgrade to v3: Allure Runtime and testMapper no longer supported for custom labels

[bionikokex]

After upgrading allure-cucumberjs and allure-js-commons from v2 to v3, we noticed that support for directly using AllureRuntime with testMapper is no longer available.

In v2, we used a custom reporter to inject additional labels (e.g., layer, allure_id, etc.) into each test via testMapper. This worked reliably for transforming Cucumber tags into Allure metadata:

import { AllureRuntime } from 'allure-js-commons';
import { CucumberJSAllureFormatter } from 'allure-cucumberjs';

export default class extends CucumberJSAllureFormatter {
  constructor(options) {
    super(options, new AllureRuntime({
      resultsDir: './allure-results',
      testMapper: (test) => ({
        ...test,
        labels: [
          ...test.labels,
          { name: 'layer', value: 'ui tests' },
        ],
      }),
    }), {
      labels: [
        { pattern: [/@feature:(.*)/], name: 'epic' },
        { pattern: [/@Project\/Product:(.*)/], name: 'project' },
        { pattern: [/@target_id:(.*)/], name: 'target_id' },
        { pattern: [/@allure_id:(.*)/], name: 'allure_id' },
        { pattern: [/@AT_Section:(.*)/], name: 'auto_section' },
      ],
    });
  }
}

In v3, we followed the documented approach by defining formatOptions.labels in the cucumber.js configuration:

formatOptions: {
  resultsDir: 'allure-results',
  labels: [
    { pattern: [/@allure_id:(.*)/], name: 'allure_id' },
    { pattern: [/@target_id:(.*)/], name: 'target_id' },
    { pattern: [/@AT_Section:(.*)/], name: 'auto_section' },
    { pattern: [/@feature:(.*)/], name: 'epic' },
  ],
}

However, these custom labels no longer appear in the Allure report. The tags themselves are still parsed by Cucumber, but the mapped labels are missing from the output in allure-results.

Is there an alternative to testMapper in v3? Or a new, supported way to programmatically inject labels based on tags?

This was an important part of our reporting integration, and losing this capability is currently blocking us from migrating fully to v3.

[delatrie]

Hi, @bionikokex

The feature seems to work as expected to me. I've created a demo repository. Here is the config I used:

module.exports = {
  default: {
    parallel: 4,
    format: ["allure-cucumberjs/reporter:./out/ignore"],
    formatOptions: {
      resultsDir: "./out/allure-results",
      labels: [
        { pattern: [/@allure_id:(.*)/], name: 'allure_id' },
        { pattern: [/@target_id:(.*)/], name: 'target_id' },
        { pattern: [/@AT_Section:(.*)/], name: 'auto_section' },
        { pattern: [/@feature:(.*)/], name: 'epic' },
      ],
    }
  },
}

The feature file is as follows:

@target_id:MyTarget @feature:MyFeature
Feature: sample feature
	@AT_Section:My_AT_Section @allure_id:1020
	Scenario: sample scenario
		Then sample step

You may check: the labels are present in the result file.

Compare the setup in the repo with yours and note any differences.

Hope that will help.

[bionikokex]

Hi, thanks for the update:)
FYI:
In v3, the formatOptions.labels configuration only works when defined inside the named profile (e.g., under default). If you define it at the top level of the config file, it's silently ignored - no errors or warnings. Took me a while to figure that out, so sharing here in case it helps others.

[bionikokex]

@delatrie how to put a layer in the configuration itself so that it applies to all features at once? If you put it down as written in the documentation, then I need to put name and value in the label, but in this case, an error occurs at startup
v2 example:
testMapper: (test) => ({ ...test, labels: [...test.labels, { name: 'layer', value: 'ui tests' }] }),

[delatrie]

The globalLabels property of formatOptions solves exatly that:

module.exports = {
  default: {
    format: ["allure-cucumberjs/reporter:./out/ignore"],
    formatOptions: {
      resultsDir: "./out/allure-results",
      globalLabels: {
        layer: "UI",
        tag: ["foo", "bar"],
      },
    },
  },
}

It's yet missing in the documentation. We'll fix that soon.