Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve HTML test results reports #29054

Open
ianbrandt opened this issue May 7, 2024 · 2 comments
Open

Improve HTML test results reports #29054

ianbrandt opened this issue May 7, 2024 · 2 comments
Labels
a:feature A new functionality 🌳 help wanted Taking contributor PRs, might need existing Gradle knowledge in:testing

Comments

@ianbrandt
Copy link

Expected Behavior

It would be really handy if the columns of the HTML test results report were sortable, and if there was a "Tests" (i.e. a listing of the individual test methods) view in addition to the "Packages" and "Classes" views.

Then I could select the "Tests" view, sort by "Duration" descending, and quickly see my slowest tests across all my test suites. Combined with the Test Report Aggregation Plugin, I could see my slowest tests across all my suites for my entire build.

Current Behavior (optional)

I can't readily see my overall slowest tests via the HTML test results report.

Context

Regularly identifying and performance tuning my slowest tests could significantly reduce my overall build times. My CI server (Bamboo) doesn't seem to derive any such report from the XML test results. I'd have to find some other tooling, or somehow code something myself that would produce such a report.

@ianbrandt ianbrandt added a:feature A new functionality to-triage labels May 7, 2024
@ianbrandt
Copy link
Author

ianbrandt commented May 8, 2024

On concern I could foresee is that an aggregate "Tests" view that contains many hundreds of thousands of individual tests or more could start to become a problem for page rendering performance and memory consumption. The simplest way to address this might be to make the view optional, have it be disabled by default, and slap a "caveat emptor" sticker on it in the documentation. Alternatively, the results could written out to JSON (perhaps chunked), and a JavaScript pagination or top-N control could be used to only render a limited slice of the results at one time.

@ljacomet ljacomet added in:testing 🌳 help wanted Taking contributor PRs, might need existing Gradle knowledge and removed to-triage labels May 14, 2024
@ljacomet
Copy link
Member

This feature request is in the backlog of the relevant team and is prioritized by them.


If you are interested in contributing to Gradle, this issue is actionable and ready for contribution but might be challenging for first-time contributors.

See CONTRIBUTING.md for more information.


The request makes sense. The implementation should remain self-contained because that report is designed for external consumption.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
a:feature A new functionality 🌳 help wanted Taking contributor PRs, might need existing Gradle knowledge in:testing
Projects
None yet
Development

No branches or pull requests

2 participants