Re: Where does Wickets debug-output when running tests in Gradle come from?
Guten Tag Thorsten Schöning, am Mittwoch, 1. April 2020 um 11:46 schrieben Sie: >> 11:34:01.536 [Test worker] INFO org.apache.wicket.Application - >> [WicketTesterApplication-7fefbf5f-492f-4c7d-b276-522938b3242c] init: >> org.wicketstuff.event.annotation.Initializer@3456cd50 >> 11:34:01.546 [Test worker] INFO org.apache.wicket.Application - >> [WicketTesterApplication-7fefbf5f-492f-4c7d-b276-522938b3242c] init: Wicket >> core library initializer >> 11:34:01.569 [Test worker] DEBUG o.a.w.p.h.servlet.ServletWebRequest - >> Calculating context relative path from: context path '/context', >> filterPrefix 'servlet/', uri '/context/servlet/' > Any idea why that output is triggered? Things were easier than expected: Logback was simply available on the classpath for some reason, loaded, didn't find a configuration and therefore configured itself to its defaults: Using the console. Making a logback-test.xml available in "src/test/resources" with higher log levels easily resolved those debugging messages and the generated reports of Gradle or small again. Though already available, it might make sense to require logback to be available during running tests always: > testRuntimeOnly 'ch.qos.logback:logback-classic:1.1.3', > 'ch.qos.logback:logback-core:1.1.3', > 'org.junit.jupiter:junit-jupiter-engine:5.1.0' I tried a different approach before: Expactation was that in case tests fail, at least the last X log statements might be of use to debug the problem, but really only then. While Gradle doesn't provide anything like that on its own, there are examples to do so on SO and other places: https://stackoverflow.com/a/51786839/2055163 The basic approach is using some listener to log into some cache in the background and only print those contents when the tests have failed. Logging in the background needs to be implemented, but additonally its important to tell Gradle that really only some statements should be logged at all: > tasks.withType(Test) { > testLogging { > events 'failed' // TestLogEvent.FAILED > } > } While that should work in theory, I ran into two problems: Whatever I did I wasn't able to reduce what Gradle logs on STDOUT. It's important to note that the implemented logging cache int he background DOES NOT prevent logging, it's only for additional maintenance. The events-part is what prevents logging of some sort in theory. That is even for multiple different log level, but things didn't change even for setting all of those to "failed" for some reason. Even if things have succeeded, I might only not have recognized, becuase at some point I disabled Gradle's logging again, so wouldn't see a difference anway. Nevetheless, the generated test-reports were always still huge and always contained the whole output of STDOUT. Might be that Gradle simply works that way and doesn't support anything else at all: https://discuss.gradle.org/t/disabling-stdout-stderr-generated-by-unit-tests-and-captured-in-the-test-results-xml-files/6546 So things simply didn't work in the end and falling back to logback-test.xml was the best I coud do. In case anyone is interested, I added my PoC. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail: thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow logback-test.xml Description: XML document - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Where does Wickets debug-output when running tests in Gradle come from?
Guten Tag Thorsten Schöning, am Mittwoch, 1. April 2020 um 11:46 schrieben Sie: >> 11:34:01.536 [Test worker] INFO org.apache.wicket.Application - >> [WicketTesterApplication-7fefbf5f-492f-4c7d-b276-522938b3242c] init: >> org.wicketstuff.event.annotation.Initializer@3456cd50 >> 11:34:01.546 [Test worker] INFO org.apache.wicket.Application - >> [WicketTesterApplication-7fefbf5f-492f-4c7d-b276-522938b3242c] init: Wicket >> core library initializer >> 11:34:01.569 [Test worker] DEBUG o.a.w.p.h.servlet.ServletWebRequest - >> Calculating context relative path from: context path '/context', >> filterPrefix 'servlet/', uri '/context/servlet/' > Any idea why that output is triggered? Things were easier than expected: Logback was simply available on the classpath for some reason, loaded, didn't find a configuration and therefore configured itself to its defaults: Using the console. Making a logback-test.xml available in "src/test/resources" with higher log levels easily resolved those debugging messages and the generated reports of Gradle or small again. I tried a different approach before: Expactation was that in case tests fail, at least the last X log statements might be of use to debug the problem, but really only then. While Gradle doesn't provide anything like that on its own, there are examples to do so on SO and other places: https://stackoverflow.com/a/51786839/2055163 The basic approach is using some listener to log into some cache in the background and only print those contents when the tests have failed. Logging in the background needs to be implemented, but additonally its important to tell Gradle that really only some statements should be logged at all: > tasks.withType(Test) { > testLogging { > events 'failed' // TestLogEvent.FAILED > } > } While that should work in theory, I ran into two problems: Whatever I did I wasn't able to reduce what Gradle logs on STDOUT. It's important to note that the implemented logging cache int he background DOES NOT prevent logging, it's only for additional maintenance. The events-part is what prevents logging of some sort in theory. That is even for multiple different log level, but things didn't change even for setting all of those to "failed" for some reason. Even if things have succeeded, I might only not have recognized, becuase at some point I disabled Gradle's logging again, so wouldn't see a difference anway. Nevetheless, the generated test-reports were always still huge and always contained the whole output of STDOUT. So things simply didn't work in the end and falling back to logback-test.xml was the best I coud do. In case anyone is interested, I added my PoC. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail: thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow logback-test.xml Description: XML document - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Where does Wickets debug-output when running tests in Gradle come from?
Hi all, I'm using Gradle and recently started to run tests using Wicket rendering some contents. Things work pretty well, but Wicket provides a lot of DEBUG-output on STDOUT or STDERR, which Gradle puts into its own HTML-reports for results of tests. This makes those reports pretty large in my case, e.g. ~24 MiB, and therefore takes a pretty long time to view in the browser. As well, when running those tests using the integration into Eclipse, that blocks for around half a minute as well, because each individual line of Wicket DEBUG-output is added to some GUI-tree view. Output looks e.g. like the following, only 10 thousands of lines more: > 11:34:01.536 [Test worker] INFO org.apache.wicket.Application - > [WicketTesterApplication-7fefbf5f-492f-4c7d-b276-522938b3242c] init: > org.wicketstuff.event.annotation.Initializer@3456cd50 > 11:34:01.546 [Test worker] INFO org.apache.wicket.Application - > [WicketTesterApplication-7fefbf5f-492f-4c7d-b276-522938b3242c] init: Wicket > core library initializer > 11:34:01.569 [Test worker] DEBUG o.a.w.p.h.servlet.ServletWebRequest - > Calculating context relative path from: context path '/context', filterPrefix > 'servlet/', uri '/context/servlet/' Any idea why that output is triggered? I thought it might be bound to Gradle's own log levels somehow, but switching between "--quiet" and "--debug" really only changes how much Gradle logs on STDOUT, not what Wicket does. Additionally, I don't see any other debugging output, besides some of my own classes using SLF4J as well. This leaves some logging-backend with some explicit configuration only, doesn't it? Something like log4j2, Logback or else with some config, but couldn't find some yet. Is there something embedded in Wicket used automatically when the teser is used? Thanks for your ideas! Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail: thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org