Log4j 2
  1. Log4j 2
  2. LOG4J2-602

Several unit tests are too spammy in the build log

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0-rc1
    • Fix Version/s: None
    • Component/s: Core
    • Labels:

      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. 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?

        Activity

        Matt Sicker created issue -
        Matt Sicker made changes -
        Field Original Value New Value
        Description 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?
        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?
        Hide
        Ralph Goers added a comment -

        There are one or two unit tests where I wanted to leave on the debug but really once the unit tests work the status level should be set to error.

        Show
        Ralph Goers added a comment - There are one or two unit tests where I wanted to leave on the debug but really once the unit tests work the status level should be set to error.
        Hide
        Matt Sicker added a comment -

        Build is a lot less verbose now, thanks guys!

        Show
        Matt Sicker added a comment - Build is a lot less verbose now, thanks guys!
        Matt Sicker made changes -
        Status Open [ 1 ] Closed [ 6 ]
        Resolution Fixed [ 1 ]
        Transition Time In Source Status Execution Times Last Executer Last Execution Date
        Open Open Closed Closed
        20d 23h 59m 1 Matt Sicker 05/May/14 00:25

          People

          • Assignee:
            Unassigned
            Reporter:
            Matt Sicker
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development