Make org.junit.platform.console.tasks.*Listener classes public

[kriegfrj]

I have a project where it would be nice to be able to plug in arbitrary test listeners to get the output that you want.

It would be nice to be able to use the listeners in the console package to optionally produce nicely-formatted test output. Unfortunately, I can't do this easily because the classes are package private, so I have to use reflection if I want to use them.

It seems a pity that JUnit 5 now has all this nice modularity to facilitate plug-and-play code re-use like this, but the opportunity to re-use it is thwarted by hiding it away in a private package.

[kriegfrj]

Having played with it a little bit, I think it would also be nice if all the listener-related code were put in a different package to the executor code. I'm looking at an OSGi-type usage of it, and having this separation of packages would make it easier to manage the package dependencies.

[sbrannen]

Tentatively slated for 5.6 M1 for team discussion

[sormuras]

Iirc, we introduced the "reporting" module to contain such public listeners.

[marcphilipp]

Team Decision: Let's polish the listeners to keep the public API small and move them to the reporting module.

[marcphilipp]

@kriegfrj Would you like to submit a PR?

[kriegfrj]

I'll see if I can have a look next week some time. Can't promise anything. I have another couple of suggestions from my experience in trying to use the LegacyXmlGeneratingListener too which might tie in (eg, perhaps org.unit.platform.launcher.listeners.LegacyReportingUtils also belongs in the reporting module and in a different package.

[kriegfrj]

In terms of clarifying the scope of this feature, @sormuras suggested not including the color stuff in the reporting api. My vote (for what little it may be worth), as someone who might want to use this functionality, would be to include it. Anyone who wants to use these listeners may also want the output with color codes. I got one would like to. It might be useful to make it customizable somehow, but in wouldn't like the color functionality to remain part of the private api as that would mean having to reinvent it in my own code.

(Edited: a couple of autocorrect typos)

[sormuras]

My suggestion is to keep all console-only related code, like the "color stuff", reside in the console module. We should only move (read: re-implement) the target-agnostic data structures and their related listeners to the reporting module.

• I'd like to re-use the "color stuff" already imported by shading picocli library into the console module and get rid of our internal "color stuff".
• I'd like to make the color and the tiles themes configurable w/o being bound by "soon" published API.

[marcphilipp]

@kriegfrj We're having second thoughts about making the listeners with all their configuration options public. Would a class that contains a set of factory methods, e.g. createTreePrintingListener(boolean enableAnsiColors): TestExecutionListener, work in your use case?

[kriegfrj]

Possibly that could work. I was thinking of a sort of pluggable model where the listeners would be self-contained jars and the config passed in through property files, but I could work around that, possibly with another layer on top. Do as you see fit. :+1:

[kriegfrj]

Hi @marcphilipp and @sormuras, I pray that you guys are well.

Just touching base as this feature seems to have fallen off the radar. There's no particular urgency for it from my end so don't stress, but I wouldn't want the idea to get lost completely.

[marcphilipp]

@kriegfrj At this time, we don't think there's enough interest in making these public to justify the added maintenance burden by staying backward compatible.

[yschimke]

For context I'm trying to use junit 5 in a graal app that specifically runs our tests. The defaults do a lot of reflection, resource loading and a strictly controlled programmatic approach is a lot better than working around Consolelauncher.main()

[mythsunwind]

I'm also interested in this case. I'm working on my own custom test engine and used a launcher too. This launcher works well with LegacyXmlReportGeneratingListener, but when I want to use TreePrintingListener I have to copy the whole source code into my own project right now or use the workaround from https://github.com/junit-team/junit5/issues/2469.

Here is an example of my usage:

LauncherConfig launcherConfig = LauncherConfig.builder()
                .enableTestEngineAutoRegistration(false)
                .enableTestExecutionListenerAutoRegistration(false)
                .addTestEngines(new CustomEngine())
                .addTestExecutionListeners(new LegacyXmlReportGeneratingListener(xmlReportsDir, out))
                .addTestExecutionListeners(new TreePrintingListener(out, false, Theme.UNICODE))
                .addTestExecutionListeners(customListener)
                .addTestExecutionListeners(failedTestListener)
                .build();

I can understand the problem that this adds maintenance burden tough. But making the constructor and class public would help me a lot.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. Given the limited bandwidth of the team, it will be automatically closed if no further activity occurs. Thank you for your contribution.

[yschimke]

@marcphilipp does remove from General Backlog mean this is closed as won't fix?

[sbrannen]

@marcphilipp does remove from General Backlog mean this is closed as won't fix?

No. It's currently in the status: waiting-for-interest bucket. Otherwise, the team would have officially closed it.

[laeubi]

Team Decision: Let's polish the listeners to keep the public API small and move them to the reporting module.

What is the the progress here? It seems there is even a PR now so can it be considered?