Allure Report

Visit Website

Introduction

Allure Report is a multi-language HTML report for automated tests. A framework adapter writes result files while the suite runs. The Allure command then builds a static site with suites, steps, attachments, failures, retries, and history. The same report can show pytest, JUnit, Cucumber, Jest, and other runners side by side if each one writes Allure results.

Allure 3 is the current CLI, written in TypeScript and published from allure-framework/allure3 under Apache-2.0. Allure 2, the Java CLI, is still what many CI jobs install. Adapters from the Allure 2 era still feed Allure 3. Allure TestOps, the commercial test-management product from Qameta, is a different product and is not this entry.

Features

1. Framework adapters: Official and community adapters exist for JUnit 5, TestNG, pytest, Cucumber, SpecFlow-style .NET runners, Jest, and others. The adapter’s job is to emit result files, not to run the tests.
2. Steps and attachments: Tests can record named steps, screenshots, logs, and request bodies. Those show up on the test page inside the report.
3. Static HTML: allure generate writes a directory you can open locally or upload as a CI artifact. No Allure server is required to read it.
4. History and trends: If previous report history is copied into the next run, the report shows status over time, flaky retries, and duration changes.
5. Categories: A categories file maps failure traces to labels such as “product defect” or “test defect.”
6. BDD view: Cucumber and other Gherkin runners show features and scenarios, not only a flat list of test names.
7. Allure 3 CLI: npx allure generates, serves, and can watch a run. Configuration is a single file. Plugins change the UI.
8. CI upload: GitHub Actions, Azure DevOps, and Jenkins plugins publish the HTML. The report is still files; the plugin only stores them.

Pros

1. One report for a polyglot suite: Java API tests and Python service tests can land in the same HTML if both write Allure results.
2. Nothing to host: A static build is an artifact. You can archive it next to the CI job.
3. Steps make failures readable: A screenshot and a step name beat a single stack trace when the audience is not the person who wrote the test.
4. Free: Apache-2.0 for Allure 3. Adapters are free as well.
5. History is optional: You can start with a single-run report and add trend data later by preserving the history directory.

Cons

1. Two CLIs are in the wild: Allure 2 (allure from a Java install) and Allure 3 (npx allure) both appear in docs and blog posts. CI should pin one.
2. Trends need plumbing: History only appears if the job downloads the previous history and feeds it back. A fresh agent with an empty workspace shows a single run.
3. Adapters are per framework: Installing the CLI does not instrument pytest or JUnit. Each runner needs its own listener or plugin, and versions must match the result format.
4. The report is not a test manager: Cases, assignments, and requirements live elsewhere. Allure TestOps covers that and is paid; this page does not.
5. Large attachments: Screenshots and logs on every test inflate the artifact. CI retention and upload time become the limit.

Usage and Links (Example)

Allure 3, without a global install:

npx allure run -- pytest
npx allure generate --output ./allure-report
npx allure open

The run command executes the test command and then builds the report when the adapter wrote allure-results. For pytest that means pip install allure-pytest and --alluredir=allure-results if you generate in a separate step. Allure 2 jobs use allure generate allure-results from the Java distribution instead.

Resources:

• Allure Report website
• Allure 3 documentation
• GitHub: allure-framework/allure3
• GitHub: allure-framework/allure2

Pricing

1. Free: Allure Report, including the Allure 3 CLI and the framework adapters, is open source (Apache-2.0 for Allure 3). There is no seat fee.
2. Allure TestOps is separate: Qameta sells a test-ops platform under the Allure name. Do not budget that product as part of the HTML report. It is not listed in this directory yet.
3. CI storage: The only ongoing cost for the report itself is artifact storage and the minutes to generate it.

Recommended for?

1. Multi-framework CI that needs one HTML page for Java, Python, and JavaScript results.
2. Teams who attach screenshots and steps and are tired of digging through raw JUnit XML.
3. BDD suites that want features and scenarios rendered, not only a flat pass/fail list.
4. Pipelines that can store a directory as a build artifact. If you need cross-run analytics with logins and quality gates, look at a server such as ReportPortal instead of stretching history files.

Conclusion

Allure Report is the straightforward open-source HTML report for automated tests. Pin Allure 3 or Allure 2 in CI, install the adapter for each runner, and publish the static site as an artifact. Add history only when a job can actually pass the previous history directory forward. Keep Allure TestOps as a separate buying decision.