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 2015/10/21 07:21:27 UTC

[jira] [Resolved] (LOG4J2-495) As a unit test developer, I want a JUnit rule to handle specific external configuration files.

     [ https://issues.apache.org/jira/browse/LOG4J2-495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matt Sicker resolved LOG4J2-495.
--------------------------------
    Resolution: Fixed

This can be closed by now. Gary has even [written a blog post|https://garygregory.wordpress.com/2015/09/08/the-art-of-test-driven-development-per-test-logging/] about how to use this feature.

> As a unit test developer, I want a JUnit rule to handle specific external configuration files.
> ----------------------------------------------------------------------------------------------
>
>                 Key: LOG4J2-495
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-495
>             Project: Log4j 2
>          Issue Type: Story
>          Components: API, Core
>    Affects Versions: 2.0-rc1
>         Environment: Inside any JUnit test that relies on a specific log4j2.xml file. For example, FileConfigTest in core.
>            Reporter: Matt Sicker
>            Assignee: Matt Sicker
>            Priority: Minor
>
> There are many unit tests that have the same boilerplate code over and over again:
> {code:java}
>     private static final String CONFIG = "...";
>     private static LoggerContext ctx;
>     @BeforeClass
>     public static void setupClass() {
>         System.setProperty(ConfigurationFactory.CONFIGURATION_FILE_PROPERTY, CONFIG);
>         ctx = (LoggerContext) LogManager.getContext(false);
>     }
>     @AfterClass
>     public static void cleanupClass() {
>         System.clearProperty(ConfigurationFactory.CONFIGURATION_FILE_PROPERTY);
>         ctx.reconfigure();
>         StatusLogger.getLogger().reset();
>     }
> {code}
> This sort of pattern can be replaced with a quick implementation of {{org.junit.rules.ExternalResource}} like so:
> {code:java}
> package org.apache.logging.log4j.test.rule;
> import org.apache.logging.log4j.LogManager;
> import org.apache.logging.log4j.core.LoggerContext;
> import org.apache.logging.log4j.core.config.ConfigurationFactory;
> import org.apache.logging.log4j.status.StatusLogger;
> import org.junit.rules.ExternalResource;
> public class ExternalConfig extends ExternalResource {
>     private final String configFileName;
>     private LoggerContext ctx;
>     public ExternalConfig(String configFileName) {
>         this.configFileName = configFileName;
>     }
>     @Override
>     protected void before() throws Throwable {
>         System.setProperty(ConfigurationFactory.CONFIGURATION_FILE_PROPERTY, this.configFileName);
>         this.ctx = (LoggerContext) LogManager.getContext(false);
>     }
>     @Override
>     protected void after() {
>         System.clearProperty(ConfigurationFactory.CONFIGURATION_FILE_PROPERTY);
>         this.ctx.reconfigure();
>         StatusLogger.getLogger().reset();
>     }
>     public LoggerContext getContext() {
>         return this.ctx;
>     }
> }
> {code}
> Now, instead of a class using the same {{@BeforeClass}} and {{@AfterClass}} template, it can use something like the following:
> {code:java}
>     private static final String CONFIG = "...";
>     @ClassRule
>     public static ExternalConfig config = new ExternalConfig(CONFIG);
> {code}
> This helps reduce a lot of repeated code. I'll submit a patch that cleans up the unit tests with this in a little while.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org