Question: Allure Report – Showing Dynamic Test Body Steps in Left Panel

[Dyadlapalli]

In my current Allure report setup, I have a test that dynamically iterates through multiple “views” based on the portal name. The test body (on the right panel) correctly captures all these views as steps.
However, in the left panel (Suites view), I only see a single test entry, and all the individual “View” steps are hidden inside the right-side Test body.
Current Behavior
LEFT PANEL (Suites) RIGHT PANEL (Test Details)

Portal: ASC Supply Planning ---> Test Body:
- View: Parts
- View: Products
- View: Customers
- View: Plants
...

Desired Behavior
LEFT PANEL (Suites)
Portal: ASC Supply Planning
├── View: Parts
├── View: Products
├── View: Customers
├── View: Plants
├── ...

RIGHT PANEL
(Details of selected item)

Important Constraint

The “View” steps are not statically defined tests.
They are generated dynamically at runtime based on the portal configuration.
I do not want to create separate test cases or explicit test steps for each view manually, since everything is driven dynamically once the portal name is passed.

👉 My goal is to understand if there’s a way to make these dynamically generated steps (currently visible under Test body) appear in the left-side hierarchy (as sub-tests or nodes) without restructuring the test into multiple explicit test cases.

[lMysticl]

This is a boundary in Allure's result model rather than a report setting.

A single Allure test result contains its steps in the nested steps array. Those steps belong to that result and are rendered in the test details. The Suites tree is built from labels on test results, such as parentSuite, suite, and subSuite; it does not turn nested steps into independently selectable test nodes.

So there is no option that can make the existing View steps appear as children in the left panel. If every view must be selectable there, the test adapter has to emit a separate test result for each view. This does not require writing the views manually: generate parameterized or dynamic tests from the portal configuration and assign the same portal suite labels to every generated result.

For example, with JUnit 5 this would usually be a @TestFactory producing one DynamicTest per configured view, or a @ParameterizedTest backed by a method source. Other frameworks have equivalent data-driven APIs.

If you keep one Portal test result, representing the runtime-generated views as nested steps under Test Body is the supported shape.

References: Allure test result format and suite-based hierarchy.