In that case compaction makes much more sense. My experience was when a single test in a suite fails, I end up seeing lots of logs (usually proto dumps) from unrelated tests.
*From: *Pablo Estrada <[email protected]> *Date: *Wed, May 8, 2019 at 3:48 PM *To: *dev My impression - and I might be wrong [see meme at 1], is that these are > logged in debug mode, but when the test fails, the test runner dumps them > all to stdout. > Best > -P. > > [1] > https://i1.wp.com/gifrific.com/wp-content/uploads/2015/02/Chris-Farley-Oh-God-Theyre-Gonna-Know-Im-Dumb-Conan-Interview.gif?ssl=1 > > *From: *Ahmet Altay <[email protected]> > *Date: *Wed, May 8, 2019 at 3:13 PM > *To: *dev > > +1 It is hard to debug with lots logs messages. And if anybody is using >> them for development we can make those logs debug logs and hide them by >> default. >> >> *From: *Robert Bradshaw <[email protected]> >> *Date: *Wed, May 8, 2019 at 3:01 PM >> *To: *dev >> >> +1 to making them significantly more compact in most cases. >>> >>> From: Pablo Estrada <[email protected]> >>> Date: Wed, May 8, 2019 at 11:35 PM >>> To: dev >>> >>> > Hello all, >>> > Some tests in Python have the problem that when they fail, lots of >>> internal logging is dumped onto stdout, and we end up having to scroll way >>> up to find the actual stack trace for the failed test. This logging, as far >>> as i can tell, is dumping of fn api protos. >>> > >>> > Does anyone use these logs to look into the test failure? I would like >>> to find a way to make these more compact, or maybe just stop logging them >>> (people who need them can choose to log them in their local setup?). >>> > >>> > I lean towards making them more compact (by, for instance, writing >>> functions that log their information in a more compact fashion); but I >>> would like to hear thoughts from others. >>> > >>> > So thoughts? : ) >>> > -P. >>> >>
