Skipped Count Shown in HTML Report Despite No Skipped Testcases (Serenity BDD 4.2.34 + JUnit5 Parallel)

[VinothiniPalaniswamy]

We are encountering a reporting issue in Serenity BDD version 4.2.34 when using JUnit5 with parallel execution and tag filtering.

Setup:
Serenity BDD version: 4.2.34
Test framework: JUnit5
Execution mode: Parallel
Command used: mvn clean verify -Dcucumber.filter.tags=@test

Total test cases executed: 197
Actual results:
Passed + Failed + Broken = 197
Skipped = 3 (shown in HTML report)
However, no test cases are actually skipped, and .json reports confirm this.

Observations:
The skipped count appears in the HTML report summary, but when clicking into the skipped section, it shows 0 test cases.
This affects the overall percentage calculation, misleading stakeholders reviewing the report.
The skipped entries seem to be steps within failed scenarios, not entire test cases.

What’s Verified:
.json files in target/site/serenity do not contain any skipped test cases.
All scenarios are either passed, failed, or broken.
No use of Assume.assumeTrue() or conditional skipping in hooks.

Request:
Please investigate whether this is a known issue with the HTML report rendering logic in Serenity BDD 4.2.34, especially under parallel execution with JUnit5. If possible, provide a workaround or confirm if a fix is planned in future releases.

[wakaleo]

I have never seen this behaviour before, so it may indeed be project specific. Have you tried mvn clean verify?

[VinothiniPalaniswamy]

yes. Command used: mvn clean verify -Dcucumber.filter.tags=@test

[wakaleo]

I would need to look at the project or a sample project reproducing the issue - this isn't something I have come across. A test that isn't executed because of a Cucumber filter will not produce any json reports, and therefore will not appear in the reports or test count at all (it won't be flagged as skipped). A test skipped because of the @Skip annotation or because of a failing assumption will appear in the reports.

[VinothiniPalaniswamy]

Learnt from Issue#3691 that this is fixed in version 5.0.4. Will verify post the release and will confirm. Thanks!