Allure Report Integration in Cucumber

What Is Allure Report?

Allure Report is an advanced open-source reporting framework used to generate rich, interactive, and professional test execution reports. In Cucumber automation, it acts as a reporting layer that converts raw execution results into a browsable dashboard. Instead of giving only a basic pass or fail summary, Allure can show scenario history, execution time, graphs, screenshots, logs, attachments, API request and response details, environment data, categories of failures, and trend information.

Built-in Cucumber reports are useful for learning and for simple execution summaries. Allure is used when teams need deeper analysis. A failed Selenium scenario can include a screenshot inside the report. A failed REST Assured scenario can include the request body, response body, headers, and status details. A CI/CD execution can publish the report so testers, developers, leads, and managers can review the same evidence from the pipeline.

In simple terms, Allure converts Cucumber execution into an interactive test report that is easier to debug, easier to share, and easier to analyze across repeated runs. It does not replace good automation design, but it makes automation results far more visible and useful.

Why Use Allure?

Basic reports can tell the team that a scenario passed or failed. That is helpful, but often not enough. When a test fails in a real project, the first question is not only whether it failed. The team needs to know where it failed, what the application looked like, what data was used, what API response came back, what environment was running, and whether the same scenario failed before. Allure helps answer these questions in one place.

Basic Cucumber Report
  -> Scenario
  -> Passed or Failed

Allure Report
  -> Scenario
  -> Status
  -> Screenshot
  -> Execution Time
  -> Attachments
  -> History
  -> Environment
  -> Graphs

This richer information greatly improves debugging. A tester can inspect the failed scenario without searching through console logs. A developer can open the same report and see the failed step, stack trace, screenshot, and attached data. A lead can review failure categories and trends. Allure becomes valuable because it turns test results into evidence.

Allure Architecture

The Allure architecture has two main ideas: collection and generation. During test execution, an Allure adapter listens to test events and writes raw result files. After execution, the Allure generator reads those raw result files and creates the final HTML dashboard. This separation is important because running tests and generating the final report are two different stages.

Feature File
  -> Runner
  -> Cucumber
  -> Step Definitions
  -> Automation Code
  -> Allure Results
  -> Allure Report
  -> Browser

The Cucumber feature file describes behavior. The runner starts execution. Step definitions connect Gherkin steps to automation code. Selenium, REST Assured, database utilities, or service clients perform the real work. The Allure adapter collects execution details and writes them into the allure-results folder. The report generator then creates the final allure-report folder that can be opened in a browser or published in CI/CD.

Execution Flow

The execution flow starts when the team runs the automation suite from an IDE, Maven command, Gradle task, or CI pipeline. Cucumber executes the scenarios and Allure records the results. At this stage, Allure does not usually create the final browsable report immediately. It creates raw result files first. A separate command or CI step generates the final HTML report from those files.

Run Tests
  -> Generate Raw Results
  -> Store Results
  -> Generate HTML Report
  -> Open Dashboard

This distinction prevents confusion. Many beginners run tests, see an allure-results folder, and think the report is ready. The raw results are only the input. The final report must be generated using the Allure command-line tool, Maven plugin, Gradle plugin, or CI integration.

Allure Components

Allure integration usually contains an automation project, an Allure adapter, an allure-results directory, the Allure generator, and the final allure-report directory. The adapter is responsible for collecting test information. The result directory stores raw files. The generator converts those files into a browser-friendly dashboard.

Automation
  -> Allure Adapter
  -> allure-results
  -> Allure Generator
  -> allure-report

This model helps you troubleshoot reporting problems. If allure-results is missing, the adapter or plugin configuration is probably wrong. If allure-results exists but no browser report exists, the report generation step is missing. If the report exists but screenshots are missing, the attachment logic is probably not configured correctly.

Maven Dependencies

For Cucumber JVM projects, the Allure dependency must match the Cucumber version and the test runner style. A Cucumber 7 project commonly uses the Allure Cucumber 7 JVM adapter. If the project also uses TestNG, the Allure TestNG adapter may be added. For JUnit-based projects, the corresponding Allure JUnit integration should be used instead of the TestNG adapter.

<dependency>
    <groupId>io.qameta.allure</groupId>
    <artifactId>allure-cucumber7-jvm</artifactId>
    <version>2.x.x</version>
</dependency>

<dependency>
    <groupId>io.qameta.allure</groupId>
    <artifactId>allure-testng</artifactId>
    <version>2.x.x</version>
</dependency>

The exact version should be selected according to the project standards and compatibility. The important interview point is not the specific number, but the concept: Allure needs an adapter that connects the test framework execution events to Allure's result format.

Cucumber Plugin Configuration

In a Cucumber runner, Allure is commonly enabled through the plugin configuration. The plugin points to the Allure Cucumber adapter class. When Cucumber executes scenarios, the adapter receives execution events and writes raw Allure result files.

@CucumberOptions(
  plugin = {
    "io.qameta.allure.cucumber7jvm.AllureCucumber7Jvm"
  }
)

This configuration is essential. If the Allure plugin is not configured, test execution may still run successfully, but Allure result files will not be generated. When troubleshooting, always confirm that the runner being executed is the same runner where the Allure plugin is configured.

Result Directory

During execution, Allure writes raw files into the allure-results directory. This folder contains JSON files, attachments, metadata, and other files used by the Allure generator. These files are not the final report. They are the source data from which the final report is built.

Project
  -> allure-results
     -> JSON Files
     -> Attachments
     -> Metadata

The result directory should be cleaned carefully. If old result files remain, the next report may show stale data. If the directory is deleted before report generation, the final report cannot be created. CI/CD pipelines should manage this folder deliberately: clean before execution, generate fresh results, archive or generate the report, and preserve history when required.

Report Generation

After tests finish, the Allure generator reads allure-results and creates the final allure-report folder. Inside the generated report folder, an index.html file and supporting assets are created. This report can be opened in a browser or published through a CI tool.

allure-results
  -> Allure Generator
  -> allure-report
  -> index.html

Depending on setup, report generation may happen through the Allure command line, Maven plugin, Gradle plugin, Jenkins plugin, or another CI integration. The flow is the same: raw results first, final report second. Understanding this flow helps avoid one of the most common beginner mistakes in Allure integration.

Report Structure

The generated Allure report contains several views. The dashboard gives a high-level summary. Suites show tests organized by execution structure. Behaviors can show business-oriented grouping. Categories group failures. Graphs show visual health. Timeline helps analyze execution order and duration. Packages show code-oriented grouping. History shows trends when historical data is preserved.

Dashboard
  |-- Overview
  |-- Suites
  |-- Behaviors
  |-- Categories
  |-- Graphs
  |-- Timeline
  |-- Packages
  |-- History

These views make Allure more useful than a simple static report. Different users can approach the same execution from different angles. A tester may start in Suites. A manager may start in Overview. A framework engineer may inspect Timeline and Categories. A developer may open a failed scenario and examine attachments.

Dashboard

The dashboard is usually the first view users see. It summarizes total tests, passed tests, failed tests, broken tests, skipped tests, and execution time. It may also show widgets and charts depending on configuration. This view is useful for quickly understanding whether the run is healthy.

A dashboard should not be treated as the entire report. It tells the team what happened at a high level, but deeper investigation requires opening failed scenarios, reading stack traces, reviewing screenshots, and checking attachments. The dashboard is the starting point, not the final analysis.

Suites View

The Suites view organizes execution in a way that usually follows the test structure. In Cucumber, this often maps naturally to features, scenarios, and steps. This view is useful for navigating large test suites because it helps users find a specific feature or scenario quickly.

Feature
  -> Scenario
  -> Steps

Clear feature and scenario names make this view much more useful. If the suite contains vague names such as Test1 or Validation Scenario, the report becomes harder to understand. Allure displays what the automation suite provides. Good reporting depends on good test naming.

Behaviors View

The Behaviors view groups tests by business functionality. This is helpful when stakeholders want to understand quality by business area rather than by code package. For example, scenarios may be grouped under Authentication, Customer, Orders, Payments, and Reporting. This makes the report easier for non-technical stakeholders to read.

Authentication
  -> Customer
  -> Orders
  -> Payments

Behavior-oriented reporting is one of the reasons Allure fits well with BDD. Cucumber feature files describe business behavior, and Allure can present execution in a way that reflects those behaviors. The report becomes more valuable when feature organization, tags, and story labels are maintained consistently.

Timeline View

The Timeline view displays when tests started, how long they ran, and how execution overlapped. This is especially useful in parallel execution. If one scenario takes far longer than others, the timeline makes it visible. If parallel workers are not being used efficiently, the timeline can reveal idle periods or bottlenecks.

Scenario 1
  -> Scenario 2
  -> Scenario 3

Timeline analysis is practical for execution optimization. Long-running scenarios can be reviewed, split, moved to a different suite, or optimized. Slow hooks, expensive setup, repeated login, and unnecessary waits often become visible when execution timing is shown clearly.

Graphs and Charts

Allure includes visual summaries such as passed, failed, skipped, and broken results. Charts make execution health easier to understand than raw logs. They also help leads and managers quickly see the condition of a test run without opening every scenario.

Graphs are useful, but they should not hide the underlying details. A high pass percentage may still contain a failed critical payment scenario. A low pass percentage may be caused by one environment outage. Reports must be read with context. Allure gives helpful visualization, but the team still needs judgment when interpreting results.

Environment Information

Environment information helps connect a report to the exact conditions of execution. Useful details include browser, environment, operating system, Java version, framework version, base URL, API endpoint, build number, branch, commit ID, and execution timestamp. Without this information, a report can become difficult to interpret later.

Browser: Chrome
Environment: QA
OS: Windows
Java: 21
Framework: Cucumber

Environment details are especially important when tests run across multiple browsers or environments. A failure in Chrome on QA may require different investigation from a failure in Edge on staging. Adding environment information makes the report more useful for debugging and release review.

Screenshot Attachment

For Selenium tests, screenshot attachment is one of the most valuable Allure features. When a UI scenario fails, the framework can capture the current browser screen and attach it to the failed scenario. This helps the team see what the user would have seen at the moment of failure.

Scenario Failed
  -> Capture Screenshot
  -> Attach to Allure
  -> View in Report

Allure.addAttachment(
  "Failure Screenshot",
  new ByteArrayInputStream(screenshotBytes)
);

Screenshots should usually be attached on failure rather than for every step. Attaching screenshots for every passing step can make reports heavy and slow. Failure screenshots provide strong evidence without making every report unnecessarily large.

API Request Attachment

For REST Assured automation, request attachments make API failures easier to debug. If a scenario validates an order API and fails, the request body, headers, method, endpoint, and query parameters may be important. Attaching a sanitized request gives the developer enough context to reproduce the issue.

Allure.addAttachment(
  "Request",
  requestJson
);

Request attachments must be handled carefully because they can contain tokens, usernames, passwords, customer IDs, or other sensitive data. A good framework masks secrets before writing request details into a report. Useful reporting should not leak private information.

API Response Attachment

Response attachments help explain API assertion failures. If the expected status code is 201 but the API returns 400, the response body often explains why. It may contain validation messages, error codes, missing field details, or server errors. Attaching the response body gives immediate evidence.

Allure.addAttachment(
  "Response",
  response.asPrettyString()
);

For large API responses, attach only what is useful. Huge payloads can make reports hard to load and difficult to read. When possible, attach formatted and filtered responses that highlight relevant fields. The purpose of an attachment is to improve debugging, not to dump unlimited data.

Log Attachment

Logs can also be attached to Allure reports. A log attachment may include important framework actions, test data identifiers, retry information, browser details, API endpoint details, or custom debug messages. Logs are useful when screenshots or response bodies do not fully explain a failure.

Allure.addAttachment(
  "Execution Log",
  logText
);

Log attachments should be concise. If every test attaches a large execution log, reports become noisy and heavy. A better strategy is to attach focused logs for failed scenarios and archive full logs separately when needed.

Categories

Allure can group failures into categories. For example, teams may classify UI failures, API failures, database failures, infrastructure failures, assertion failures, timeout failures, and automation framework failures. Categories help identify recurring patterns across executions.

This is useful for automation health discussions. If most failures are infrastructure failures, the team should focus on environment stability. If most failures are locator failures, the team should improve UI locator strategy. If most failures are assertion mismatches, the application behavior or expected data may need review. Categories turn individual failures into trend information.

History and Trends

Allure can display execution history when history data is preserved between runs. History allows the report to show whether pass percentage is improving, whether failures are recurring, and how execution has changed over time. This is valuable in CI/CD because teams rarely care about one run in isolation. They care about quality direction.

Run 1: 95%
Run 2: 97%
Run 3: 100%

History requires deliberate preservation. If the CI workspace is cleaned on every build and the history folder is not carried forward, trend information will not appear. A mature pipeline copies the previous history into the new results before generating the report, then archives the updated report for future builds.

Cucumber, Selenium, and Allure

In a Cucumber and Selenium framework, Allure helps connect business-readable scenarios with UI evidence. A feature file describes the expected behavior. Step definitions call page objects or reusable actions. Selenium interacts with the browser. If a failure occurs, the framework can attach screenshots, browser logs, page state, or other evidence to Allure.

Feature
  -> Step Definition
  -> Page Object
  -> Selenium
  -> Screenshot
  -> Allure

This flow is powerful because it makes UI automation failures easier to discuss. Instead of saying "the Selenium test failed," the report can show that a specific business scenario failed at a specific step with a visible browser screenshot. This improves communication between QA, developers, and product teams.

Cucumber, REST Assured, and Allure

In a Cucumber and REST Assured framework, Allure helps expose API execution evidence. Feature files describe API behavior in business terms. Step definitions call API clients. REST Assured sends requests and receives responses. Allure can attach sanitized request and response details, making API failures easier to diagnose.

Feature
  -> API Client
  -> REST Assured
  -> Request
  -> Response
  -> Allure

This is especially useful in service-level automation. When an API scenario fails, the failure may be caused by request data, authentication, headers, environment configuration, contract changes, backend errors, or downstream service issues. Request and response attachments shorten investigation time.

CI/CD Flow

Allure is commonly published through CI/CD pipelines. A developer commits code. Jenkins, Azure DevOps, GitHub Actions, Bamboo, or another CI tool runs the automation suite. Cucumber and Allure generate raw results. A report generation step creates the final Allure report. The pipeline then publishes or archives the report for team review.

Git Commit
  -> Jenkins
  -> Maven Test
  -> Allure Results
  -> Generate Report
  -> Publish Report

The report should be generated and published even when tests fail. Failed runs are the most important runs to inspect. A pipeline that stops before report generation removes valuable failure evidence. CI scripts should handle report publishing in post steps or always-run sections where possible.

Allure Report in Jenkins

Jenkins has strong support for publishing test artifacts and reports. In a typical Jenkins setup, the build runs Maven tests, Allure result files are created, and a Jenkins post step publishes the Allure report. The published report can then be opened from the Jenkins build page.

For stable Jenkins reporting, the result path must match the path used by the project. If the framework writes to allure-results but Jenkins looks under target/allure-results, the report will appear missing. The build should also archive related artifacts such as screenshots, logs, JSON reports, and JUnit XML reports when useful.

Allure Report in API Automation

Allure is particularly helpful in API automation because API failures often require request and response inspection. A clear report can show the scenario name, endpoint, method, request body, response body, status code, headers, and assertion error. This turns the report into a debugging artifact rather than only a result summary.

However, API reporting must be disciplined. Sensitive headers, tokens, personal data, and internal identifiers should be masked. Reports may be shared across teams, stored in build systems, or attached to defects. Automation engineers should treat reports as shared documents and avoid exposing secrets.

Allure Report in UI Automation

In UI automation, Allure provides strong value through screenshots, step names, browser details, and failure evidence. A Selenium failure can be difficult to understand from a stack trace alone. A screenshot can reveal that a modal covered the button, the page did not load, the user was not logged in, or validation text appeared unexpectedly.

UI frameworks should usually attach screenshots on failure and optionally attach additional evidence such as current URL, page title, browser logs, or DOM snippets. The goal is to give enough context for quick triage without making every report unnecessarily large.

Common Mistakes

A common mistake is forgetting the Allure Cucumber plugin. Without the adapter plugin, Allure result files are not generated. Another mistake is stopping after test execution and expecting the final report to exist. Running tests creates raw results; report generation is a separate step.

Many beginners also generate beautiful reports but forget useful attachments. A report without screenshots, request details, response details, or logs may still leave the team guessing. On the other side, some frameworks attach too much data to every scenario. Large attachments can slow reports and make them harder to share.

Another important mistake is ignoring history. If history data is not preserved across CI runs, Allure cannot show useful trends. Finally, teams sometimes couple business logic to reporting code. Reporting should observe and document execution; it should not control core test behavior.

Best Practices

Use the official Allure adapter that matches your Cucumber version. Generate reports after every meaningful execution. Attach screenshots for failed UI tests. Attach sanitized requests and responses for API tests. Include environment information. Publish reports through CI/CD. Preserve history data for trend analysis. Organize tests using meaningful feature names, scenario names, and tags.

Keep attachments concise and relevant. Attach failure evidence by default, and attach passing evidence only when it provides clear value. Use stable output paths and predictable folder names. Clean old results before execution unless intentionally preserving history. Make report generation part of the pipeline, not a manual task that depends on one person remembering to run a command.

Enterprise Reporting Architecture

An enterprise reporting architecture usually has several layers. Cucumber runs the BDD scenarios. Selenium or REST Assured performs UI or API automation. The Allure adapter records execution data. The allure-results directory stores raw results. The Allure generator builds the interactive dashboard. CI/CD publishes the dashboard and archives supporting artifacts.

Feature File
  -> Runner
  -> Cucumber
  -> Selenium / REST Assured
  -> Allure Adapter
  -> allure-results
  -> Allure Generator
  -> Interactive Dashboard

This architecture supports different users. Testers review failures. Developers inspect evidence. Managers review health and trends. DevOps engineers publish reports in pipelines. Product owners can understand whether critical business flows passed. Allure becomes the presentation layer for automation feedback.

Built-In HTML vs Allure

Cucumber's built-in HTML report provides a basic execution summary. It is simple, easy to generate, and useful for small projects or learning. Allure provides richer dashboards, attachments, analytics, history, categories, timeline, and environment information. It is better suited for larger automation frameworks where debugging and reporting needs are broader.

The choice is not always either-or. Many teams generate built-in reports, JSON reports, JUnit XML reports, and Allure reports together. Each serves a different reporting need.

Allure vs Extent Reports

Allure and Extent Reports are both popular in automation frameworks. Allure is open-source and strong in interactive dashboards, history, categories, and ecosystem support. Extent Reports is popular in Selenium frameworks and is known for rich HTML customization and attractive custom reports. Both can support screenshots, logs, and detailed execution evidence.

The better tool depends on project standards, team skills, reporting expectations, and CI/CD integration needs. A strong automation engineer should understand both and choose based on maintainability rather than appearance alone.

Troubleshooting Allure Integration

If Allure does not generate results, check whether the correct adapter dependency is present. Then check whether the Cucumber plugin is configured in the runner that actually executes. If results exist but the final report is missing, check whether the report generation command ran. If screenshots are missing, check the failure hook and attachment code. If history is missing, check whether the history folder is being preserved between builds.

Also inspect output paths. Many reporting issues are simple path mismatches. The framework may write results in one folder while the CI job reads another. Parallel execution can also cause report problems if multiple workers write to the same result files incorrectly. Treat reporting paths as part of framework configuration and keep them consistent.

Security and Privacy in Allure Reports

Allure reports can contain rich evidence, and rich evidence can contain sensitive data. Screenshots may show customer names, account numbers, email addresses, or business data. API requests may include tokens, cookies, credentials, or personal information. Logs may include internal URLs and system identifiers. Because reports are often published and archived, they must be handled responsibly.

A mature framework masks sensitive values before attaching data. It avoids attaching full payloads when a small relevant excerpt is enough. It controls who can access report artifacts. It separates public summary reports from restricted debugging artifacts when required. Good reporting improves transparency without creating security risk.

Maintaining Allure Reports in a Team

Allure integration should be maintained as a shared framework feature, not as a personal utility added by one automation engineer. The team should agree on where result files are generated, which attachments are added, how screenshots are named, which environment fields are shown, and how long reports are retained. This avoids confusion when multiple people run the same suite locally or through different CI pipelines.

Consistency is especially important when a project contains both UI and API automation. UI failures may need screenshots, current URL, page title, and browser details. API failures may need endpoint, method, request payload, response payload, and status code. If every module attaches evidence differently, the report becomes difficult to read. A small reporting standard helps everyone understand failures quickly.

Using Allure Reports During Defect Triage

Allure reports can become a strong defect triage artifact. When a scenario fails, the tester can open the failed test, review the failed step, inspect screenshots or API attachments, and decide whether the problem is an application defect, automation issue, data issue, environment issue, or timing issue. This reduces the amount of manual explanation needed when raising a defect.

A useful defect report can reference the scenario name, feature name, build number, environment, failed step, screenshot, and relevant request or response attachment. Developers can then reproduce and investigate faster. The report does not replace a well-written bug, but it provides supporting evidence that makes the bug easier to understand.

When Allure May Be Too Much

Allure is powerful, but not every project needs advanced reporting from day one. For a small learning project, built-in HTML, JSON, and JUnit XML reports may be enough. Allure becomes more valuable when the team has many scenarios, multiple contributors, CI/CD execution, Selenium screenshots, API evidence, history requirements, or stakeholder reporting needs.

The decision should be practical. If the team spends too much time investigating failures from console logs, Allure can help. If CI users need a professional dashboard, Allure can help. If the project has only a few local scenarios, adding Allure may be unnecessary at first. Good engineering means choosing reporting based on real debugging and visibility needs.

Interview-Ready Summary

Allure Report is an advanced reporting framework that generates rich, interactive reports from Cucumber execution results. It integrates with Cucumber through an adapter plugin and can work with Selenium, REST Assured, TestNG, JUnit, Maven, Gradle, and CI/CD pipelines. Allure stores raw execution data in the allure-results directory and generates a browsable report from those results.

Allure improves debugging by supporting screenshots, logs, API request and response attachments, environment information, failure categories, execution timeline, graphs, and history. Compared with Cucumber's built-in HTML reports, Allure provides much richer visualization and diagnostics. Enterprise teams commonly publish Allure reports from CI/CD pipelines and preserve history data for trend analysis.

Golden Rules

Use the correct Allure adapter for your Cucumber version. Generate the Allure report after every test execution. Attach screenshots, API requests, responses, and logs only when they improve debugging. Publish Allure reports through CI/CD and preserve history for trend analysis. Keep the automation framework independent of the reporting tool so reporting can evolve without breaking test logic.

The practical takeaway is clear: Allure is a reporting layer that turns Cucumber execution into useful evidence. When configured correctly, it helps teams debug faster, communicate failures better, track quality over time, and present automation results professionally.