Devrions-nous l'unité de test de l'exploitation forestière?

Il est habituel de voir la fonctionnalité de journalisation dans le code:

public class A {

    private static final Log LOG = LogFactory.getLog(A.class);

et utilisation:

} catch (Exception e) {
    LOG.error(e.getMessage(), e);
    throw e;
}

mais je n'ai jamais vu, même seule unité de test pour tel code.

Bien entendu, j'ai fais le test de jeter exception et le type d'exception, mais dois-je écrire de test pour vérifier les informations de journalisation? J'ai tendance à penser que la journalisation est une autre partie du comportement du système, il est donc logiquement quitter pour le couvrir dans les tests.

En supposant que je doit le couvrir, signifie que je devrais changer mon code d'origine pour injecter de la maquette du journal et vérifier que "l'erreur" de la méthode est invoquée avec le message attendu. Mais que faire si ma classe d'origine, c'est le service et il est instancié par le printemps, doit-on injecter certains enregistreur ainsi que d'autres dépendances?

OriginalL'auteur Ruslan Dzhabbarov | 2012-08-17

10

Ce n'est pas à vous de tester l'enregistrement de la bibliothèque. Mais il peut être intéressant de tester que lorsqu'une exception est levée, votre classe enregistre un message, au bon niveau. Ce que vous faites des tests, c'est que votre code fait la bonne chose avec la bibliothèque de journalisation.

Pour rendre le code ci-dessus testable, utiliser l'injection de dépendance. Cela suppose que l'exploitant met en œuvre une interface, ILog. Vous voulez passer dans le journal comme un paramètre du constructeur de la classe A. Ensuite, le code de test serait de créer un simulacre de mise en œuvre de ILog, et le passer dans le constructeur. Pas indiqué dans le code ci-dessus est de savoir comment l'exception, mais il sera sans doute par l'entremise d'un objet dépendant. Afin de vous moquer de ça, et faire lever une exception. Ensuite, vérifiez que la fantaisie ILog invoqué la error méthode. Peut-être que vous voulez examiner le message qu'il enregistre, mais que peut-être aller trop loin, en rendant le code de test fragile.

c'est la même approche qui je l'ai mentionné dans ma question. Mais pour moi, c'est pas encore clair que faire en cas de printemps des services de car, généralement, JOURNAL créé pour chaque classe, il est donc de classe spécifique et je ne peux pas le faire comme un singleton.
Si vous n'avez pas de contrôle sur le code qui instancie l'objet Journal, il est difficile de tester le comportement, parce que vous ne pouvez pas utiliser une maquette du Journal. Vous pouvez laisser ce journal avec le Journal réel de l'objet, puis aller vérifier qu'un message a été enregistré. Cependant, c'est difficile à automatiser!
Non, je suis d'accord avec vous que le code de journalisation doit être testé. Que cela signifie que nous devrions avoir setter pour le JOURNAL, de sorte qu'il serait possible de passer la maquette du journal dans les tests, mais que faire en cas de printemps des services. Je suis en train de réfléchir 2 voies possibles: 1) avoir un setter mais appel uniquement à partir d'essais (peut-être difficile de limiter une telle visibilité depuis le printemps pourrait faire l'auto injection), 2) injecter de l'enregistreur à travers le printemps, mais dans ce cas, il est difficile d'instancier bon enregistreur.
Ne pas instancier ta classe sous test à l'aide de Printemps dans les tests unitaires? (J'ai tendance à penser que c'est une mauvaise idée de toute façon)
Ajout d'une méthode synthétique dans votre conception, car vous avez besoin de tester la journalisation est l'un des principaux odeur de code. Si vous avez besoin d'un enregistreur, il devrait être une classe de première le collaborateur et l'introduire en tant que tel par le constructeur de l'injection. Un enregistreur doit être traitée comme une notification par les pairs dans le sens qu'il a juste besoin d'être mis à jour avec l'objet de l'activité mais n'a aucune incidence sur l'objet de la fonctionnalité globale. C'est l'approche préconisée par Freeman et Pryce dans leur excellent livre, Croissance Orientée Objet des Systèmes par des Tests (GOOS)

OriginalL'auteur Carl Raymond
2

Je ne ferais pas de test de l'unité de code qui ne fait rien mais l'appel dans une bibliothèque qui vous avez confiance.

Faites-vous confiance à votre bibliothèque de journalisation? Si le test échoue, c'est parce qu'il y a un bug dans la bibliothèque, ou tout simplement parce que vous n'avez pas configuré de la bibliothèque correctement? Avez-vous soins sur le test de la configuration?

Je ne suis pas l'examen de la journalisation de la bibliothèque fonctionne, mon intention est de vérifier que mon code ne journalisation.

OriginalL'auteur Matt Ball
2

Oui, nous devrions tester enregistrement lorsque l'enregistrement est en train de faire quelque chose qui est nécessaire. Par exemple, vous avez des crochets en application externe qui analyse le journal pour certains événements. Dans ce cas, vous avez certainement envie d'en assurer l'enregistrement se fait.

Bien sûr, vous ne voulez pas tester tous les loging cas, et je pense que, la plupart du temps que de l'ERREUR (et pas tous d'entre eux) doivent être testés.

Moderne de la journalisation des frameworks tels que SLF4j vous pouvez simplement injecter un gestionnaire personnalisé qui stocke les événements dans la mémoire et qui peuvent être invoqués à l'encontre de la suite.

Il y en a deux qui me viennent à l'esprit en ce moment:

SLF4JTesting: Ne nécessite aucune modification de la configuration de la journalisation, mais nécessite d'injecter un enregistrement à l'usine qui pourrait conduire à une modification du code.

SLF4J Test: Pas aussi puissant que slf4jtesting et ne semble pas être développé, mais fonctionne bien avec du code existant. Aucune modification en outre, l'enregistreur de données de configuration pour le test.

Lors de l'utilisation de SLF4J Test, les assertions sont très strictes et vérifier l'ensemble de la manifestation pour l'égalité. Une correspondance personnalisée est sans doute intéressant dans un tel cas:
```
public static Matcher<LoggingEvent> errorMessageContains(final String s) {
    return new TypeSafeMatcher<LoggingEvent>() {
        @Override
        public void describeTo(final Description description) {
            description.appendText(" type " + Level.ERROR + " should contain ")
                    .appendValue(s);
        }

        @Override
        protected void describeMismatchSafely(final LoggingEvent item, final Description mismatchDescription) {
            mismatchDescription.appendText(" was type ").appendValue(l)
                    .appendText(" message ").appendValue(item.getMessage());
        }

        @Override
        protected boolean matchesSafely(final LoggingEvent item) {
            return item.getLevel().equals(Level.ERROR)
                    && item.getMessage().contains(s);
        }
    };
}
```
Ce vérifie seulement que le message contient un texte, mais pas si elle est égale. Ainsi, lorsque le message est modifié pour corriger une faute de frappe ou de donner plus de détail, le test ne permet pas de se briser si l'essentiel est encore contenue.

OriginalL'auteur kap

il existe une autre solution: vous pouvez vous moquer de LogFactory! par exemple:

import junit.framework.Assert;
import mockit.Mock;
import mockit.MockUp;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import org.junit.Test;

public class XXXTest {
    class MyLog implements Log {
        public static final String INFO = "info";

        private String logLevel;
        private Object logContent;

        public String getLogLevel() {
            return logLevel;
        }

        public Object getLogContent() {
            return logContent;
        }

        @Override
        public void info(Object o) {
            logLevel = "info";
            logContent = o;
        }

        //Implement other methods
    }

    @Test
    public void testXXXFunction() {
        final MyLog log = new MyLog();
        new MockUp<LogFactory>() {
            @Mock
            public Log getLog(String name) {
                return log;
            }
        };

        //invoke function and log by MyLog
        FunctionToBeTest.invoke();
        Assert.assertEquals("expected log text", log.getLogContent());
    }
}

bonne chance!

OriginalL'auteur Ming Cheng

0

Si la journalisation est une exigence de l'entreprise, et permettra de fournir de la valeur de l'entreprise (c'est à dire en cas de panne, le diagnostic de triage ou un problème), alors vous devez le traiter comme toute autre exigence. En tant que tel, vous devriez probablement écrire des tests unitaires de ne pas vérifier que votre bibliothèque de journalisation de travaux, mais de vérifier que, dans les attendus circonstances, votre code de journaux de ce qu'il devrait.

Plus sur ce sujet: https://ardalis.com/logging-and-monitoring-are-requirements

OriginalL'auteur ssmith

Vous devez vous connecter pour publier un commentaire.