opt: junit support split out; optimize display format

[yeshan333]

Features:

• Support outputting Junit XML reports in suite dimension. When the scale of test cases is large, combining with some CI systems (eg: Jenkins CI JUnit Realtime Test Reporter) can enable real-time viewing of test reports.

Optimizations:

• The current implementation is not friendly to the display of CI systems, and the hierarchy is not clear enough.
  • Demo Link: https://jenkins.shan333.cn/job/busted_junit_demo/2/testReport/busted_demo.spec/
  • 
• Reason: CI System use the last one . to distinguish between package name and class name.

After optimizations:

• Demo Link: https://jenkins.shan333.cn/job/busted_junit_demo/3/testReport/spec/
• 

Reproduction demo: https://github.com/yeshan333/busted_junit_demo

[alerque]

Are there any junit consumers that would not benefit from this? As in, is there an argument for this being the default?

[yeshan333]

Are there any junit consumers that would not benefit from this? As in, is there an argument for this being the default?
@alerque

This is very useful for users who use web UI to view test reports in CI System（eg：Jenkins. Junit is one of the most widely used testing frameworks in the Java ecosystem, while Jenkins is the most widely used automation system in the Java ecosystem.）, But this will not have any impact on users who enjoy using terminals to view results.

Java's classes use （.） De-district the hierarchical structure of the project.

The original implementation resulted in an ugly use case hierarchy for CI splitting.

the element.trace.short_src are usually forms such as case_spec.lua. This means that lua has been recognized as a class in the Java ecosystem.

busted/busted/outputHandlers/junit.lua

Line 106 in 02f31a9

classname = element.trace.short_src .. ':' .. element.trace.currentline,

For outputting test cases in the suiteEnd stage, when the scale of test cases is very large, it is convenient to view some results in real time (perhaps you may ask: is it not good to directly specify the execution of a certain test case, but for projects where some test cases will affect each other, this helps to identify problem cases or test small earlier)
For outputting test cases in the xx stage, when the scale of test cases is very large, it is considered to view some results in real time (per hats you may ask, it is not good to directly specify the execution of a certain test case, but for projects where some test cases will affect each other, this helps to identify problem cases or find test smells problems earlier)

[alerque]

Yes I get how this improves output for web UIs setup for Java, my question was about whether the output would be worse anywhere else if we made it the default. Is junit ever useful on a terminal for example? Or would folks normally be using other outputters there anyway?

[yeshan333]

Yes I get how this improves output for web UIs setup for Java, my question was about whether the output would be worse anywhere else if we made it the default. Is junit ever useful on a terminal for example? Or would folks normally be using other outputters there anyway? @alerque

The impact is minimal. The junit terminal output works well. I have some tests on Github Actions and Gitlab CI, you can take a look:

• GitHub Actions:
  • terminal output: https://github.com/yeshan333/busted_junit_demo/actions/runs/7539484235/job/20522081046
  • get report: https://github.com/yeshan333/busted_junit_demo/actions/runs/7539484235/job/20522085626
• GitLab CI Demo：https://gitlab.com/yeshan333/busted_junit_demo/-/pipelines/1139567228/test_report?job_name=golang