cucumber-reporting turns a Cucumber JSON run into a browsable HTML report

The JSON report is the only input the library needs

The dependency on the Cucumber JSON report is the thing to understand first, because it defines where this sits in your pipeline. The documentation says that in order for this to work you must generate a cucumber json report, and that the project converts the json report into an overview html linking to separate feature files with stats and results. So the library sits after the test run and before the publish step, and it does not run tests, parse feature files, or talk to a CI server on its own. That last point is why it was split out, since the readme says it has been split out into a standalone package so it can be used for Jenkins and maven command line as well as any other packaging that might be useful. The generated report has no dependency, so can be viewed offline, which is the property that makes it a good build artifact to keep.

Adding the dependency to a pom is the whole install

There is no plugin to configure and no server to run. You add a Maven dependency to your pom.

<dependency>
    <groupId>net.masterthought</groupId>
    <artifactId>cucumber-reporting</artifactId>
    <version>(check version above)</version>
</dependency>

The version placeholder in the documentation is a reminder that the library moves independently of the Cucumber version your project uses, and that the badge showing the Maven Central version is the thing to copy. The readme also points at the Jenkins plugin's detailed configuration page for the Jenkins flavour of the same project, which is a separate artefact with its own settings, and the readme is explicit that that page is for the Jenkins version. The library itself is on Maven Central under the net.masterthought group, and the repository carries a pom.xml, a src directory and an appveyor.yml, with GitHub Actions, AppVeyor, codecov, SonarQube, Codacy and Snyk badges at the top, so the build and quality tooling are part of the project rather than an afterthought.

The builder API is a configuration object and a list of JSON files

The usage example in the readme is the whole API surface, and it is built around two objects. You create a Configuration with an output directory and a project name, you hand it a list of JSON report files and a ReportBuilder, and the builder returns a Reportable. The Configuration object carries the metadata that appears on the main page, and the readme's example fills it in with a build number, classifications for platform, browser and branch, a set of not-failing statuses, and classification files read from properties.

File reportOutputDirectory=new File("target");
        List<String> jsonFiles=new ArrayList<>();
        jsonFiles.add("cucumber-report-1.json");
        jsonFiles.add("cucumber-report-2.json");

        String buildNumber="1";
        String projectName="cucumberProject";

        Configuration configuration=new Configuration(reportOutputDirectory,projectName);

The result of generateReports is a Reportable, and the last comment in the example is the one that matters operationally: you validate the result to decide what to do if the report has failed. That is the hook for a build to fail on a failed scenario, and it is how the library stays out of the business of deciding your build status.

Presentation modes and per-file qualifiers exist for parallel runs

Two configuration features handle the case that breaks naive reporting, which is several JSON files from a parallel test execution. The first is the presentation mode, and the documentation sets two in the example, RUN_WITH_JENKINS and PARALLEL_TESTING, added with addPresentationModes. The second is the qualifier, set with setQualifier for each JSON file, and the example gives them names, First report and Second report, so a reader can tell which shard produced which result. There is a third, quieter feature in the same object, setNotFailingStatuses, which takes a set of statuses and in the example is told not to make a scenario fail when a step has status SKIPPED. That last one is a reporting-fidelity decision: by default a skipped step is treated as a failure signal, and teams that expect skips in their suites have to say so explicitly. The documentation also mentions the javadoc for further detail on the configuration options.

The report is a set of pages: overview, features, tags and trends

The output structure is visible in the screenshots the readme links. There is a feature overview page, which is the landing page with the charts of run results, and there are feature specific results pages for the individual feature files, with separate pages shown for passing and failing runs so that the failure view can carry the extra detail. There is a tag overview, which appears when the features carry tags, and a tag report that drills down from that overview, plus a trends report. The distinction between the overview and the feature pages is the point of the design, because the readme describes the project as converting the JSON into an overview html linking to separate feature files with stats and results, and that linking is what turns a flat test run into something a team can browse rather than a wall of JSON. The failure page in particular exists to hold the information you need when something broke, which is the report's real job in a build.

A live demo is regenerated on every merge, so you can judge it first

The readme offers a way to evaluate the project before adopting it, and it is a good one. There is an online demo of the reports, and the documentation explains that the report is generated every time a new change is merged into the main development branch, so it always refers to the most recent version of the project. Sample configuration is provided in the test source, in a class named LiveDemoTest, which means the configuration that produces the demo is the same code path a user would write. The readme also notes that if you have tags in your cucumber features you can see a tag overview, which is a good indicator of how the report handles the metadata that real suites carry. Combined with the feature overview page link, the demo is a reasonable way to decide whether the report format suits your team before writing any integration code.

Where cucumber-reporting is the wrong choice

The first wrong case is a pipeline that already renders Cucumber results in a dashboard, because the value this library provides is the standalone HTML with charts and drill-downs, and if you already have that then you are adding a second rendering of the same data. The second is a project that wants live results rather than a run artifact, since the report is generated from a JSON file after the run, so it cannot show you a run in progress. The third is a team unwilling to add a reporting library to the build, because the library is invoked from the code that runs the tests, and any Maven build that also runs tests now carries this dependency and the output directory it writes into. The fourth is a project with very large runs where a single overview page with charts across thousands of scenarios becomes the thing people have to load in a browser, and the readme does not describe any pagination or lazy loading behaviour. The fifth is a project already standardised on Cucumber's own reporting plugins, since the integration path there is a plugin configuration rather than a library call in test code.

Editorial conclusion

Teams that run Cucumber in continuous integration and want a readable, archivable record of the run rather than a log file are the people cucumber-reporting is for, and the fact that the generated report has no dependency and can be viewed offline is what makes it usable as a build artifact. It is the wrong tool if your pipeline already has a dashboard that renders Cucumber results, since the value here is the standalone HTML rather than an integration. Check three things before you adopt it: that your Cucumber run actually produces a JSON report, because the library consumes that format and nothing else, that you check the Maven Central badge for the current version, and how you want parallel runs to be presented, since the report builder supports a parallel testing presentation mode and per-file qualifiers for exactly that case. The licence is LGPL-2.1, the last push was on 2026-10-21, and the repository publishes no GitHub releases, so the version on Maven Central is the marker to track.

Frequently asked questions

Official sources

1. damianszczepanik/cucumber-reporting on GitHub
2. Issues
3. License: LGPL-2.1
4. README