Posso eseguire automaticamente i test JUnit una volta con tutte le registrazioni abilitate e una volta con tutte le registrazioni disabilitate?

Question

Ho trovato una soluzione, vedere la mia risposta qui sotto. Qualcuno ha uno più elegante?

Voglio fare questo per aumentare la copertura del codice e trovare bug sottili.

Assumere il seguente classe da testare:

public class Foo { 
    private final Logger logger = LoggerFactory.getLogger(Foo.class); 
    public void bar() { 
     String param=[..]; 
     if(logger.isInfoEnabled()) logger.info("A message with parameter {}", param); 

     if(logger.isDebugEnabled()) { 
      // some complicated preparation for the debug message 
      logger.debug([the debug message]); 
     } 
    } 
} 

e la seguente prova di classe:

public class FooTest { 
    @Test 
    public void bar() { 
     Foo foo=new Foo(); 
     foo.bar(); 
    } 
} 

Uno strumento in codice di copertura come ad esempio Cobertura riferirà correttamente che solo alcuni dei rami condizionali sono stati controllati.

info e debug sono attivati ​​o disattivati ​​per il logger.

Oltre ad avere un aspetto negativo nel punteggio di copertura, questo rappresenta un rischio reale.

Cosa succede se c'è qualche effetto collaterale causato dal codice interno se (logger.isDebugEnabled())? Cosa succede se il tuo codice funziona solo se DEBUG è abilitato e fallisce miseramente se il livello di log è impostato su INFO? (Questo è effettivamente accaduto in uno dei nostri progetti: p)

Quindi la mia conclusione è che il codice che contiene le dichiarazioni logger dovrebbe sempre essere provato una volta con tutta la registrazione attivata e una volta con tutta la registrazione disabilitata ...

Is c'è un modo per fare qualcosa del genere con JUnit? So come abilitare o disabilitare globalmente tutte le mie registrazioni in Logback, quindi il problema è: come posso eseguire i test due volte, una volta con la registrazione abilitata, una volta con la registrazione disabilitata.

p.s. Sono a conoscenza di this question ma non penso che questo sia un duplicato. Sono meno preoccupato per i valori di copertura assoluti, ma per i bug sottili e difficili da trovare che possono essere contenuti in un if (logger.isDebugEnabled()).

Answer 1

Ho risolto questo problema implementando una classe base che le classi di test dovrebbero estendere se tale funzionalità è desiderata.

L'articolo Writing a parameterized JUnit test conteneva la soluzione.

Vedere LoggingTestBase per la classe di base di registrazione e LoggingTestBaseExampleTest per un semplice esempio che lo utilizza.

Ogni metodo di prova contenuta viene eseguito tre volte:

1. è eseguito utilizzando la registrazione come definito logback-test.xml come al solito. Questo dovrebbe aiutare durante la scrittura/debug dei test.

2. Viene eseguito con tutte le registrazioni abilitate e scritte in un file. Questo file viene eliminato dopo il test.

3. Viene eseguito con tutte le registrazioni disabilitate.

Sì, LoggingTestBase ha bisogno di documentazione;)

Answer 2

Si consiglia di passare da JUnit a TestNG. TestNG ha molte funzionalità avanzate su JUnit. Ti consente di eseguire i test più volte con una configurazione diversa e credo sia quello che ti serve

Answer 3

Hai provato semplicemente il mantenimento di due file di configurazione di registro separati? Ognuno dovrebbe accedere a diversi livelli dal root logger.

Tutti accedendo disabilitato:

... 
<root> 
    <priority value="OFF"/> 
    <appender-ref ref="LOCAL_CONSOLE"/> 
</root> 
... 

Tutti attivata la registrazione:

... 
<root> 
    <priority value="ALL"/> 
    <appender-ref ref="LOCAL_CONSOLE"/> 
</root> 
... 

esecuzione sarebbe specificare configurazioni differenti sul percorso di classe tramite un parametro di sistema:

-Dlog4j.configuration=path/to/logging-off.xml 
-Dlog4j.configuration=path/to/logging-on.xml 

Answer 4

suggerimento di eqbridges di eseguire semplicemente i test due volte con diversi contesti di registrazione sembra il più semplice. Non devi ricordare di codificare la logica in ogni test benedetto, per un grande vantaggio. L'altro è che puoi vedere quale livello di registrazione è da incolpare molto facilmente.

Detto questo, ci sono un paio di strategie se dovessi fare questo in un giro di prova.

Per 3.8 inserire tutto in suite e creare due suite, una per ogni livello di registrazione, che imposta il livello di registrazione prima dell'esecuzione dei test. Questo è funzionalmente la stessa cosa che eseguire l'intera suite di test due volte con parametri della riga di comando diversi, tranne che si ottiene con una corsa.

In JUnit 4.x un paio di opzioni aggiuntive vengono in mente:

Uno è un corridore personalizzato. Anche se non riesco a pensare a tutto ciò che dovresti fare per farlo funzionare, ma un corridore che esegue il test due volte e commentando il test con @RunWith, il tuo runner personalizzato potrebbe funzionare.

L'altro è test parametrizzati. Anche se in realtà dovresti impostare ogni test per prendere i parametri (questo richiede un costruttore che accetta gli argomenti) e quindi impostare il livello di log in base al parametro.

MODIFICA: in risposta alla richiesta di un how-to sui test parametrici, here è la javadoc sul runner per iniziare, e here è una guida più pratica.

Answer 5

Se ritieni di avere troppa registrazione se si accende tutto, forse si potrebbe provare a ridurre la quantità di registrazione. Non è molto utile se è troppo per il computer non elaborare un essere umano da leggere.