Allure Reports: Building Meaningful Test Reports

1. Why a dedicated reporting tool makes sense

The native console output of most test frameworks works well for immediate feedback during development, but falls short once several people on a team regularly need an overview of the entire test suite's state without running every single test locally themselves. Without a processed, shared dashboard, the actual state of the test suite stays largely invisible to everyone except whoever kicked off the last CI run.

Allure Report addresses this by generating a complete, static HTML dashboard from a machine-readable, framework-independent JSON intermediate format, which can easily be published as a CI artifact and shared across the entire team, without anyone needing to install a special tool locally to view the report. The key architectural advantage of this intermediate format is that practically every common test framework, from Cypress to Playwright to PHPUnit, can produce the same format, letting Allure serve as a shared, cross-framework reporting layer for a heterogeneous test ecosystem.

2. Setup for Playwright

Integrating Allure into an existing Playwright project boils down to installing an additional reporter package and registering it in the Playwright configuration, after which every test run automatically produces the JSON result files Allure needs in a dedicated output directory.

npm install --save-dev allure-playwright allure-commandline

3. Configuration and report generation in detail

After installation, the reporter needs to be registered in the Playwright configuration file, where several reporters can be registered in parallel, say the native `list` reporter for the console alongside the `allure-playwright` reporter for the later HTML generation. After every test run, the `allure generate` command builds the complete, interactive HTML dashboard from the collected raw data.

// playwright.config.js
module.exports = {
  reporter: [
    ['list'],
    ['allure-playwright', { resultsDir: 'allure-results' }],
  ],
  use: {
    screenshot: 'only-on-failure',
    video: 'retain-on-failure',
    trace: 'retain-on-failure',
  },
};

4. Embedding screenshots and videos meaningfully

For a screenshot in the Allure report to actually provide context, it should ideally be captured not just at the final failure but after every single relevant test step, for which a custom attachment call within the test code is well suited. Playwright also supports recording a full trace, which alongside screenshots contains the DOM state, network requests, and console logs at every point in the test run and can be opened directly in the trace viewer, without having to run the test locally again.

Videos are especially well suited for test cases with complex, multi-step user interactions, where a single screenshot doesn't sufficiently capture the sequence of events, say a multi-step checkout process with several form fields, while for simple, short test cases a meaningful screenshot is usually enough and saves storage space.

import { test } from '@playwright/test';
import { allure } from 'allure-playwright';

test('cart shows correct subtotal', async ({ page }) => {
  await page.goto('/checkout/cart');
  await allure.step('Screenshot before price calculation', async () => {
    await page.screenshot({ path: 'before-calculation.png' });
  });
  await page.click('[data-testid="apply-coupon"]');
  await allure.attachment('Cart state', await page.screenshot(), 'image/png');
});

5. A trend view across multiple test runs

Allure's real added value over a simple, one-off HTML report lies in its history feature, which merges previous results with the current run and automatically generates trend charts, say for the development of the success rate, average execution duration, and the number of unstable, repeatedly failing tests across recent runs.

For this history feature to actually work, the `history` directory of the previous report has to be copied into the current result directory before every new run, which in a CI pipeline usually means transferring this directory as its own, persistent artifact between successive pipeline runs, instead of letting it get lost on every run. Without this extra step, the trend history restarts from zero on every CI run, practically negating the feature's biggest benefit.

6. Building a team dashboard from the Allure report

For a team wanting to view the generated HTML report permanently and centrally, hosting it via Allure's server mode or automatically publishing it as a static page after every CI run, say on GitLab Pages or a comparable internal hosting service, is preferable to only offering the report as a transient, downloadable CI artifact.

An additional, practical building block is integrating a status badge or a short summary comment directly in the pull request, showing the most important metrics of the associated test run, say success rate and number of newly occurring failures, without a click into the full report, lowering the barrier for regularly viewing test results across the whole team.

7. Using categories, labels, and severity effectively

Allure lets you enrich tests with structured metadata like severity level, feature area, or epic, allowing the report to be filtered and grouped afterward, say to view only tests with `critical` severity or summarize all tests of a particular feature area at a glance, instead of manually scanning the entire list, often several hundred test cases long.

Additionally, custom categories let failures be grouped by cause class, say "known, not-yet-fixed bug" versus "new, genuine regression failure", which helps during the daily review of CI results to distinguish actually new problems from already known and accepted limitations, without having to redo the same manual classification on every run.

8. Distinguishing it from other reporting tools

Besides Allure, other common reporting tools exist, say Mochawesome for Mocha-based projects or the native Cucumber HTML reports, which also turn raw test results into a readable report, but are usually limited to a single test framework and typically don't come with a built-in history feature across multiple runs, meaning trend analysis would have to be built from scratch rather than available out of the box.

Plain JUnit XML output, which many CI systems can render directly in their own interface, also provides some basic functionality for success and failure, but stays limited to the textual error message and offers neither screenshots nor videos nor structured categorization by cause, making it considerably less practical than a dedicated tool like Allure for a team wanting to regularly perform deeper failure analysis. Allure's decisive advantage over these alternatives therefore lies less in the plain HTML presentation itself and more in the combination of cross-framework support, built-in history, and rich attachments in a single, consistent place, instead of having to piece these three aspects together across several, separately maintained tools.

9. Allure features at a glance

The table below summarizes the Allure features presented.

10. Summary

11. FAQ: Allure Reports: The Essentials at a Glance