This message was deleted.

The docs don't seem to address this, or I can't find where/if it's addressed.

i use this https://github.com/radarsh/gradle-test-logger-plugin

I'll check it out. It looks like it should work

showFailedStandardStreams true

is a option. hopeful.

all the output gets stashed in build/test-results/* by default

that looks like it's just a report of which tests passed or failed.

it does capture stdout/stderr and failed tests in my projects, I'm not sure what would make that not work

I also have jacoc code coverage plugin. likely some interaction.

works with jacoco enabled for me too

could be. I have a mix of standard junit tests and cucumber tests.

Unless you deactivated it, Gradle creates a nice html report for the tests where you can also see stdout / stderr. This works for me for all projects in had so far. Gradle imho is the non-plus-ultra when it comes to build tools. But to everyone his favorite tool. If you don't like, don't use it.

here are some settings i use that could be useful to you:

tasks {
    withType<Test>() {
        maxParallelForks = Runtime.getRuntime().availableProcessors()
        useJUnitPlatform()
        testLogging {
            setExceptionFormat("full")
            setEvents(listOf("passed", "skipped", "failed", "standardOut", "standardError"))
        }
    }
}
configure<com.adarshr.gradle.testlogger.TestLoggerExtension> {
    theme = com.adarshr.gradle.testlogger.theme.ThemeType.STANDARD
    showCauses = true
    slowThreshold = 1000
    showSummary = true
    showStandardStreams = true
}

@Peter vR Those settings will spit out stdout/stderr for every test. Also, since the failure is a timeout, and the tests are running in parallel (as you have set), it's pretty much useless. The error has exceeded the scrollback buffer in the terminal.

You confuse that with Maven actually, which is a big black uninvestigatable black box where you are absolutely lost if anything strange happens. If you blindly apply dubious plugins from which you don't know what they do, they can of course have unexpected effects. But that is not the fault of Gradle. I know what the plugins do that I apply and my builds do exactly what I expect. It's the same in any other build tool. If you use strange plugins, that do strange things, things might go unexpected and it is not the tools fault. But as I said, if your personal experience is different from most of your fellow developers, just don't use the tool, but use one that suites you better. :-)

what makes you think the plugins I'm using are dubious, or that I don't know how they work?

That’s some serious negative energy to use in a community support channel. Not sure what you’re trying to achieve with that.

I'm sorry if you felt offended, is was neither my intention to do so, nor to disparage you. It were just objective obeservations.

what makes you think the plugins I'm using are dubious

I said "dubious" because if a plugin magically unexpectedly disables both, the JUnit XML report and the HTML report on the test task, which by default are enabled, so that you can see the output you are missing, that's what I call dubious unless the plugin is specifically meant to do that.

or that I don't know how they work?

I said "you don't know how they work" because that is what you said yourself. You said you need to disable plugin by plugin to find out which disables the reports that are on by default, which implies you don't know what they do or you would know which plugin is the culprit and that it is not Gradles fault.

Have you ever worked on a modern large project with automated CI?

Yes, I do that on a daily basis

There are LOTS of plugins. artifactory, sonic qube, jenkins, jacoco... the list goes on. Do you go and read all the source code for all of those? of course you don't

You want to tell me with a straight face you understand exactly how all those plugins interact with each other? Of course you don't..

Of course I don't know all plugins I use inside-out codewise, but I know what they are supposed to do and whether they are supposed to disable absolutely useful reports or not. And I actually am not aware of any standard or common plugin that does that, as it does not really make much sense imho, which again comes down to the "dubious" part if it is some plugin that disables it. If a plugin is not "dubious" and disables such important reports, I expect it to have that in its documentation crystal clear or otherwise it is dubious. Actually indeed I know how many of the plugins I use do work internally, as I often want to know how they work or what they do to evaluate whether I want that in my builds or not. But very interesting that you seem to know exactly what I do or don't do. o_O