Integrate Merv Report in Your Cucumber Project

Use the merv-client Cucumber plugin to capture every scenario, step, tag, and timing into local HTML and JSON. With Merv-Local, execution data stays on disk — you get a full suite report, a multi-run dashboard (index.html), consolidated history per test case, and KPI charts built from your report folders.

1. Merv-Local with Cucumber

If merv.local is omitted, the client follows its default (see merv-client); set it explicitly to avoid surprises.

2. Add the dependency

Include merv-client-api in the same Maven module where Cucumber runs (or a shared test module):

<dependency>
  <groupId>io.github.techelliiptica</groupId>
  <artifactId>merv-client-api</artifactId>
  <version>3.0.0</version>
</dependency>

Use the current version from Maven Central if newer.

3. Configure merv.properties

Copy merv.properties.example from the client JAR sources to your project root (working directory) as merv.properties. For local reports, the essentials are:

• merv.local=true — enable Merv-Local.
• merv.regression_suite=… — title shown on the suite report.
• merv.report.folder=… — optional; root directory for all runs (see MervConfig). Each run creates a folder like dd-MM-yyyy HH-mm-ss Merv-Report.
• merv.execution.parallel=true|false — matches how you run Cucumber; used for suite behaviour.
• merv.screenshot=on — optional; captures per-step screenshots when you bind your driver via MervCucumberHandler.setAutomationToolObject(…).

4. Register the Cucumber plugin

Register the class org.teche.merv.client.plugin.MervCucumberHandler as a Cucumber plugin so it receives test-run events:

• JUnit 4 — @CucumberOptions(plugin = { "org.teche.merv.client.plugin.MervCucumberHandler" }) on your runner.
• JUnit Platform / Cucumber 7+ — use @ConfigurationParameter(key = PLUGIN_PROPERTY_NAME, value = "org.teche.merv.client.plugin.MervCucumberHandler") or the equivalent in junit-platform.properties / Gradle, per your setup.
• CLI — --plugin org.teche.merv.client.plugin.MervCucumberHandler (plus your other options).

The handler implements ConcurrentEventListener, so it is safe to use with parallel scenarios; step and case IDs are tracked per thread.

5. What gets generated on disk (Merv-Local)

Under your configured report root:

Opening index.html in a browser (file or static server) is the recommended entry point for operators and leads.

6. Per-run suite report (HTML)

Each run’s HTML report is designed for drill-down debugging and sign-off:

• Sidebar — all scenarios with pass / fail / skip / active chips; search and status filters.
• Summary & charts — pass/fail/skip counts, pie chart, collapsible block.
• Failure reasons — grouped messages with quick navigation to related cases and screenshot thumbnails.
• Run timing — suite start, end, and duration.
• Test case detail — status, duration, machine, tags, error text, test steps with status pills (PASS / FAIL / SKIP / IN PROGRESS), step-level duration (gap from previous step end), screenshots, and optional log excerpts.
• Smart step status — pending or never-reached steps after a hard failure are shown as SKIP; true in-flight steps use IN PROGRESS styling.
• Screenshot movie — optional strip that plays step screenshots in order.
• Trend chart (live view) — pass/fail throughput in time buckets while the suite runs.

7. Local dashboard: Test Suites view

The Test Suites tab on index.html lists every run folder with title, pass/fail/skip counts, tag pills, and badges for Completed vs In progress. From each card you can open the suite HTML or copy paths. A live execution chart at the top shows pass (green) and fail (red) activity over a selectable time window (1 hour to custom range), aggregated across listed runs, with periodic refresh while you develop.

8. Consolidated Report

The consolidated views roll up all merv-report.json files under the report root so you see history without opening each run separately.

8.1 TestCase Summary (TestCase View)

A searchable table with one row per logical test case name:

• Current status (last run) — outcome of the newest matching execution.
• Last 5 runs — compact status history.
• Last passed / last failed — timestamps for triage.
• Total pass / total fail — cumulative counts across discovered runs.

Expand rows to see per-suite, per-folder breakdowns and deep links where applicable.

8.2 Tag / Group Based Summary

Groups rows by Cucumber tags. A scenario with multiple tags appears under each tag section. Clicking a tag can filter the consolidated search. This matches how teams slice regression (@smoke, @regression, @wip, etc.).

9. KPIs (Chart.js analytics)

The KPIs tab turns the same JSON snapshots into management-friendly charts. You can limit the scope to the last 20 / 30 / 50 / all / custom N builds so trends stay readable in busy pipelines.

• Test execution summary — totals for cases passed, failed, skipped; overall pass percentage; doughnut and stacked bar charts for outcome mix and per-build counts.
• Execution time & performance — total suite time, average case duration, P95 / P99 suite duration across builds, and charts for suite duration and slowest cases.
• Slow test cases — ordered list of the heaviest scenarios (by recorded duration) to target for optimisation.
• Flaky test detection — surfaces tests that both passed and failed across builds in scope, with failed-run counts, pass counts, stability, and flip counts (retry semantics are approximated from outcomes stored in JSON).
• Trend analysis — build-wise pass % over time, failures per build, and execution time trend (oldest left, newest right).

10. Deleting runs and refreshing the index

The dashboard can integrate with a small local delete API so stale folders can be removed and index.html regenerated; see ReportsDeleteServer and MervReportsIndexHtmlWriter in the merv-client source. After manual folder deletes, regenerate or rerun a suite so the index writer runs, or re-open processes documented in LOCAL_REPORTS_CONTEXT.md.

11. Further reading

• merv-client/README.md — client usage, auth, and API overview.
• merv-client/LOCAL_REPORTS_CONTEXT.md — report layout, JSON contract, and how other frameworks (e.g. TestNG) should reuse the same dashboard.
• Documentation — links to UI, API, and deployment docs.
• Documentation — running MERV services locally and choosing framework docs.

← Back to home