You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by "Matt Sicker (JIRA)" <ji...@apache.org> on 2014/04/14 01:28:14 UTC
[jira] [Updated] (LOG4J2-602) Several unit tests are too spammy in
the build log
[ https://issues.apache.org/jira/browse/LOG4J2-602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Matt Sicker updated LOG4J2-602:
-------------------------------
Description:
When I build the project using {{mvn clean install}}, I get a ton of irrelevant information about various tests. There are a few tests that intentionally throw an exception (e.g., for testing the FailoverAppender) with messages like "always fail" or "test". Now as a human, I can tell that those tests work as expected. However, as a robot, I wouldn't be able to tell the difference between test exception stack traces and actual problems with the tests.
In fact, some CI systems will consider such error output to be a build problem and won't mark the build as successful. See, for instance, [my attempted build on travis-ci.org|https://travis-ci.org/jvz/logging-log4j2/jobs/22911866]. These debug messages, while useful in development, really ought to be a build profile setting (however that would be done in Maven; or if there's a way to mix in the string lookup plugins with a maven property).
I'm actually wondering if all the exception stack traces there are even expected. If they are, couldn't we use @Test(expected = SQLException.class) or whatever the syntax is?
was:
When I build the project using {{maven clean install}}, I get a ton of irrelevant information about various tests. There are a few tests that intentionally throw an exception (e.g., for testing the FailoverAppender) with messages like "always fail" or "test". Now as a human, I can tell that those tests work as expected. However, as a robot, I wouldn't be able to tell the difference between test exception stack traces and actual problems with the tests.
In fact, some CI systems will consider such error output to be a build problem and won't mark the build as successful. See, for instance, [my attempted build on travis-ci.org|https://travis-ci.org/jvz/logging-log4j2/jobs/22911866]. These debug messages, while useful in development, really ought to be a build profile setting (however that would be done in Maven; or if there's a way to mix in the string lookup plugins with a maven property).
I'm actually wondering if all the exception stack traces there are even expected. If they are, couldn't we use @Test(expected = SQLException.class) or whatever the syntax is?
> Several unit tests are too spammy in the build log
> --------------------------------------------------
>
> Key: LOG4J2-602
> URL: https://issues.apache.org/jira/browse/LOG4J2-602
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
> Affects Versions: 2.0-rc1
> Reporter: Matt Sicker
> Labels: build, logging, tests
>
> When I build the project using {{mvn clean install}}, I get a ton of irrelevant information about various tests. There are a few tests that intentionally throw an exception (e.g., for testing the FailoverAppender) with messages like "always fail" or "test". Now as a human, I can tell that those tests work as expected. However, as a robot, I wouldn't be able to tell the difference between test exception stack traces and actual problems with the tests.
> In fact, some CI systems will consider such error output to be a build problem and won't mark the build as successful. See, for instance, [my attempted build on travis-ci.org|https://travis-ci.org/jvz/logging-log4j2/jobs/22911866]. These debug messages, while useful in development, really ought to be a build profile setting (however that would be done in Maven; or if there's a way to mix in the string lookup plugins with a maven property).
> I'm actually wondering if all the exception stack traces there are even expected. If they are, couldn't we use @Test(expected = SQLException.class) or whatever the syntax is?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org