Bug 58261 - [PATCH] Suppress messages written to System.out when running test suite
Summary: [PATCH] Suppress messages written to System.out when running test suite
Status: NEW
Alias: None
Product: POI
Classification: Unclassified
Component: POI Overall (show other bugs)
Version: unspecified
Hardware: PC Linux
: P2 enhancement (vote)
Target Milestone: ---
Assignee: POI Developers List
URL:
Keywords: PatchAvailable
Depends on:
Blocks:
 
Reported: 2015-08-18 20:33 UTC by Javen O'Neal
Modified: 2016-10-09 11:37 UTC (History)
0 users



Attachments
suppress ant test output patch (22.07 KB, patch)
2015-08-18 20:33 UTC, Javen O'Neal
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Javen O'Neal 2015-08-18 20:33:37 UTC
Created attachment 33012 [details]
suppress ant test output patch

There are several tests that write the System.out when running "ant test", including a hex dump of Container.dat from TestEscherDump. This output isn't useful when running the entire test suite.

I've modified several tests to temporarily change System.out to a NullOutputStream while the test is running to avoid this cruft. Is there a better way to hide this output unless just one test case is executed instead of the entire test suite?

I understand that there are some things that POI can't test for, such as if Microsoft Office thinks a file is corrupted but POI doesn't have a problem reading the file. There are several tests that write "Open <filename> in Excel". Are these asking someone to manually open the files in Excel and verify that the contents are displayed correctly? If so, perhaps we should have a decoration for tests where manual verification of output files is required, and the log should indicate what a person should look for in those files.
Comment 1 Nick Burch 2015-08-19 14:24:56 UTC
On the whole, I don't think out tests should be outputting things to System.err or System.out as they run, in the default config

However, I know there's some issues with getting the build to pass on at least one of the continuous integration systems, so it might be that some of those statements come from trying to track that down

There are some tests which output files for manual, visual checking. Those won't be checked on every build, but probably should be checked periodically, and especially before a release is done. If we could refactor things to make it easier to see what could be manually checked, and what to look for, that'd be great!

Maybe we could look at doing the manual check bits first, then blitz through the other output ones when the entries relating to the problematic CI system have been removed?
Comment 2 Javen O'Neal 2016-10-09 11:37:08 UTC
We could also find these by adding entries System.{out|err}.{print|println} to src/resources/devtools/forbidden-apis-prod.txt