Avons-nous besoin de journalisation lorsque vous utilisez TDD?


41

Lors du cycle Rouge, Vert et Refactor, nous devrions toujours écrire le code minimum pour réussir le test. C'est la façon dont on m'a enseigné le TDD et la façon dont presque tous les livres décrivent le processus.

Mais qu'en est-il de la journalisation?

Honnêtement, j’ai rarement utilisé la journalisation dans une application, sauf s’il se passait quelque chose de vraiment compliqué. Cependant, j’ai vu de nombreux posts qui traitent de l’importance d’une bonne journalisation.
Donc, hormis la journalisation d'une exception, je ne pouvais pas justifier l'importance réelle de la journalisation dans une application correctement testée (tests unitaires / d'intégration / d'acceptation).

Donc mes questions sont:

  1. Avons-nous besoin de nous connecter si nous faisons du TDD? un test en échec ne révélera-t-il pas ce qui ne va pas avec l'application?
  2. Devrions-nous ajouter un test pour le processus de journalisation dans chaque méthode de chaque classe?
  3. Si, par exemple, certains niveaux de journalisation sont désactivés dans l'environnement de production, cela ne crée-t-il pas une dépendance entre les tests et l'environnement?
  4. Les gens expliquent comment les journaux facilitent le débogage, mais l'un des principaux avantages de la TDD est que je sais toujours ce qui ne va pas à cause d'un test qui a échoué.

Y a-t-il quelque chose qui me manque là-bas?


5
Je pense que la journalisation est le cas particulier de tant de règles. Une classe / fonction devrait faire une chose et une seule chose ... sauf pour la journalisation. Les fonctions doivent de préférence être pures, sauf pour la journalisation. Etc., etc. La journalisation enfreint les règles.
Phoshi

1
La journalisation n’est-elle pas principalement orthogonale à une méthodologie de développement de logiciel utilisée? Alors peut-être devriez-vous simplement préciser et demander: Avons-nous besoin de cas de test pour la journalisation lorsque vous utilisez TDD?
Hyde

Réponses:


50

1) Avons-nous besoin de nous connecter si nous faisons du TDD? un test en échec ne révélera-t-il pas ce qui ne va pas avec l'application?

Cela suppose que vous ayez tous les tests possibles pour répondre aux besoins de votre application, ce qui est rarement le cas. Les journaux vous aident à localiser les bogues pour lesquels vous n'avez pas encore écrit de tests.

2) Devrions-nous ajouter un test pour le processus de journalisation dans chaque méthode de chaque classe?

Si le consignateur est lui-même testé, il n’aurait pas besoin de le retester dans chaque classe, comme pour les autres dépendances.

3) Si, par exemple, certains niveaux de journalisation sont désactivés dans l'environnement de production, cela ne crée-t-il pas une dépendance entre les tests et l'environnement?

Les humains (et les agrégateurs de journaux) dépendent des journaux, les tests ne doivent pas en dépendre. En règle générale, il existe plusieurs niveaux de journalisation, dont certains sont utilisés en production et d'autres, en développement, similaires, par exemple:

"Le niveau de journalisation des rails est une information en mode production et un débogage en développement et test" - http://guides.rubyonrails.org/debugging_rails_applications.html

D'autres applications utilisent une approche similaire.

4) Les gens discutent de la façon dont les journaux facilitent le débogage, mais l’un des principaux avantages de la TDD est que je sais toujours ce qui ne va pas à cause d’un test qui a échoué.

Les bogues de production ayant passé tous les tests, vous aurez peut-être besoin d'une autre référence pour étudier ces problèmes.


26
Même un TDD parfaitement exécuté de manière rigoureuse n’empêchera pas les problèmes de production liés aux performances, à l’interaction système, aux interactions avec des tiers. Les problèmes de concurrence sont également très difficiles à couvrir complètement par test. Une couverture de test à 100% "uniquement" signifie que 100% de votre code a été exécuté, ce n'est pas le cas dans tous les états ou environnements.
Holstebroe

34

La journalisation est utile pour expliquer le comportement non exceptionnel d'une application:

Les journaux d' événements enregistrent les événements se produisant lors de l'exécution d'un système afin de fournir une trace d'audit pouvant être utilisée pour comprendre l'activité du système et diagnostiquer les problèmes. Ils sont essentiels pour comprendre les activités de systèmes complexes, en particulier dans le cas d'applications avec peu d'interaction de l'utilisateur (telles que les applications serveur ) ...

Quelle que soit la façon dont l’application a été testée, les utilisateurs peuvent demander, quelle que soit la qualité de la journalisation des exceptions.

la sortie de votre programme est 0 alors que nous nous attendions à 1, pourquoi?

Vous devez vous connecter pour vérifier ce qu’était la configuration d’application, les paramètres et d’autres détails d’exécution pour expliquer son comportement (non exceptionnel).

Dans l’optique ci-dessus, l’exploitation forestière est davantage axée sur le soutien que sur le développement. Après la mise en production de l'application, il est souhaitable de laisser une autre personne répondre aux questions des utilisateurs, afin de permettre aux programmeurs de se concentrer sur leur développement.

La journalisation de l'application permet à quelqu'un d'autre de comprendre le comportement du programme sans fouiller dans le code et sans distraire les développeurs par des demandes d'explication de ce qui se passe.


5
+1 pour "la journalisation est plus orientée sur le support". Vraiment frappé le clou sur la tête.
Tibos

1
+1 pour "comportement non exceptionnel" et aussi pour "la journalisation est davantage orientée sur le support". Mais pourriez-vous modifier votre réponse afin d’indiquer la source du paragraphe que vous citez?
logc

@logc la source de la citation est référencée par le lien dans le tout premier mot ici, "Journalisation" - si vous cliquez dessus, vous apporterez à l'article Wikipedia: en.wikipedia.org/wiki/Logfile
gnat

16

La plupart des réponses se concentrent ici sur l'aspect de la correction. Mais la journalisation a également un objectif différent: la journalisation peut être un moyen de rassembler des données pertinentes pour la performance. Ainsi, même lorsque le système fonctionne sans erreur, un journal peut indiquer pourquoi il est lent. Même avec une couverture de test complète de tous les aspects, une suite de tests ne le dira pas.

Bien sûr, un système critique en termes de performances peut / devrait fournir des mesures de performances clés à certains tableaux de bord opérationnels, mais la journalisation "classique" peut fournir un niveau de détail différent.


2
N'oubliez pas non plus de vous connecter à des fins de piste d'audit. Ou facturation. Ou différents types de statistiques. Ou journalisation d'événements pour la mise en correspondance avec d'autres types de statistiques d'autres systèmes.
PlasmaHH

Est-ce que le profilage n'est pas quelque chose que vous feriez sans vous connecter? Ou voulez-vous simplement dire que vous pouvez enregistrer en permanence les résultats du profilage?
Bergi

@ Bergi: cela dépend entièrement du fonctionnement de votre application. S'il s'agit, par exemple, d'une application Web, consigner l'heure du service de chaque demande, puis tenter ultérieurement de regrouper ces événements en cluster pour les "mauvais exécutants" peut également fonctionner.
PlasmaHH

Le profilage @Bergi est en cours de développement, mais il faut garder à l'esprit certains effets sur les systèmes actifs, l'utilisation des disques peut devenir lente, le processeur peut être plus chargé, les services risquent de ne pas répondre à temps, les threads parallèles risquent de rencontrer des problèmes de verrouillage ...
johannes

L'audit @PlasmaHH fait partie des exigences de base et doit faire l'objet de tests. Dans la plupart des cas, je ne l'exécute pas sur des routes de journalisation "normales". La journalisation normale peut échouer, mais pas l'audit. "diverses statistiques" je me suis réuni sous performance;)
johannes

8
  1. Sauf si vous avez une couverture de test à 100%, ce qui n'est généralement pas le cas, vous ne pouvez pas savoir que votre logiciel ne plantera jamais (EDIT: et - comme dit dans les commentaires - même si c'est le cas, quelque chose d'indépendant de votre logiciel pourrait causer un accident); équivaut à penser que vous pouvez créer un logiciel qui ne contient absolument aucun bogue (même la NASA ne peut le faire). Vous devez donc au moins enregistrer les éventuels échecs en cas de panne de votre programme afin de savoir pourquoi.

  2. La journalisation doit être effectuée par une bibliothèque externe ou un framework interne en fonction de la technologie utilisée. Ce que je veux dire par là, c'est que cela devrait être quelque chose qui a déjà été testé auparavant et que vous n'avez pas besoin de vous tester vous-même. Il est exagéré de vérifier que toutes les méthodes enregistrent les tâches qu’elles sont censées faire.

  3. Les journaux ne sont pas destinés aux tests, il ne devrait y avoir aucune dépendance. Cela dit, vous n'avez pas besoin de désactiver la journalisation pour les tests si cela vous semble une contrainte, même si les journaux doivent être conservés dans un fichier correspondant à l'environnement (vous devez disposer d'un fichier différent pour les environnements de test, de développement et de production. tout au moins).

  4. Une erreur peut être très floue et il n’est pas toujours évident de comprendre ce qui ne va pas lorsqu'un test TDD échoue. Les journaux devraient être plus précis. Par exemple, si vous utilisez un algorithme de tri et que le scénario de test complet échoue, vous devez disposer de journaux pour chaque test de l'algorithme afin de vous aider à localiser le problème.


4
Même si vous avez une couverture de 100%, l'avez-vous pour tout ce qui peut arriver? Que se passe-t-il si la connexion réseau à votre base de données tombe en panne? Vos tests vous le diront-ils?
Zachary K

Vous ne pouvez jamais savoir que votre logiciel ne plantera jamais MÊME si vous avez une couverture à 100%. Une couverture de 100%, bien que souhaitable, donne beaucoup moins d'informations sur l'exactitude qu'il n'y parait.
Andres F.

Oui, vous avez raison à ce sujet aussi. Le fait est que l'absence de possibilité de crash n'est pas faisable. Je vais éditer.
Pierre Arlaud

1
La modification est toujours incorrecte. Même si vous avez une couverture de test à 100%, il peut y avoir un bogue dans votre code (inutile de blâmer des causes externes). Les tests n'impliquent pas que votre code fonctionne; la seule chose qu'ils sous-entendent avec certitude est que vous n'avez pas réussi à écrire un test qui trouve un bogue :) La couverture du test est une métrique importante, mais elle n'est pas directement liée à l'absence de bogues.
Andres F.

4
Il est trivial de prouver que "une couverture de test à 100% qui passe! = Sans bug". Contre-exemple: add(x, y) = 2(retourne toujours 2). Le test suivant passe et fournit une couverture complète: assert(2 == add(1,1)). Couverture de test à 100% pour une fonction buggy :)
Andres F.

8

La réponse courte à votre question principale est la suivante: en règle générale, les bogues dans votre code NE seront PAS exposés par TDD. Certains pourraient, idéalement, être nombreux, mais l’absence de tests infructueux n’implique pas l’absence de bogues. C'est une maxime très importante dans les tests de logiciels.

Étant donné que vous ne pouvez pas savoir si votre système aura un comportement incorrect, peut-être dans de rares cas, la journalisation est un outil utile qui peut aider à comprendre ce qui ne va pas lorsque des problèmes se produisent inévitablement.

La journalisation et le TDD répondent à des préoccupations différentes.


5

Oui, dans le cas général, vous devez vous connecter.

La journalisation ne concerne pas le débogage. Bien, OK, une partie de la journalisation concerne parfois le débogage, et vous pouvez ignorer cette partie si vous n'en avez pas besoin pendant le développement.

Mais la partie la plus importante de la journalisation concerne la maintenabilité. Une journalisation bien conçue peut répondre aux questions suivantes:

  • Est-ce que l'application est toujours en vie? (En enregistrant une pulsation toutes les 1000 secondes.)
  • La performance de l'application a-t-elle changé au cours des 10 derniers mois? (En enregistrant des statistiques sur les performances des cas d'utilisation.)
  • La charge de l'application a-t-elle changé au cours des 10 derniers mois? (En enregistrant le nombre de demandes par type de demande.)
  • Est-ce que l'une de nos interfaces a changé ses caractéristiques de performance?
  • La nouvelle version entraîne-t-elle une caractéristique d'utilisation différente pour certains des sous-systèmes?
  • Sommes-nous sous une attaque DoS ?
  • Quels types d'erreurs se produisent?

Tout cela peut être réalisé en se connectant. Et oui, il devrait être planifié et conçu et testé, de préférence automatique.

La journalisation est une fonctionnalité qui mérite d'être traitée, tout comme les autres fonctionnalités.


4

TL; DR: Logging et TDD sont orthogonaux. Avoir l'un n'a pas d'incidence sur le besoin de l'autre

Avons-nous besoin de nous connecter si nous faisons du TDD? un test en échec ne révélera-t-il pas ce qui ne va pas avec l'application?

Dans l’ensemble, la plupart des journaux que j’ai implémentés et que j’ai vu implémentés étaient destinés à un dépannage opérationnel et non à un débogage de développement (bien que cela puisse aider). Le principal public visé par cette journalisation est les administrateurs et les opérateurs qui gèrent vos serveurs, assistent les personnes à qui des journaux sont envoyés pour analyse et les clients qui souhaitent consulter ces journaux et essayer de comprendre ce qui se passe.

Ces journaux sont là pour vous aider à résoudre les problèmes liés en grande partie aux points d’intégration. Cela peut inclure des services réseau (base de données, soap, etc.), des ressources locales (disque, mémoire, etc.), des données erronées (entrée client, sources de données incorrectes / corrompues, etc.), etc. Capture d’exceptions, consignation des erreurs et même consignation informative (paramètres, configurations, etc.) peuvent tous aider à résoudre les problèmes.

Devrions-nous ajouter un test pour le processus de journalisation dans chaque méthode de chaque classe?

Ajoutez des tests là où vous en avez besoin pour tester la journalisation. Si vous avez des appels ad hoc pour vous déconnecter des informations, vous devez les tester. Toutefois, si vous implémentez la journalisation et les tests de journalisation à l'aide de la programmation orientée aspect ou de la méta-programmation, cela peut réduire la charge des tests.

Si, par exemple, certains niveaux de journalisation sont désactivés dans l'environnement de production, cela ne crée-t-il pas une dépendance entre les tests et l'environnement?

Si vous écrivez votre code avec IoC et que vous utilisez des simulacres, vous devriez être en mesure de tester efficacement toute votre journalisation sans vous fier à une configuration environnementale particulière.


3

TDD aide généralement à réduire les bugs de codage. Cela aide beaucoup moins avec des bugs avec la spécification ou juste des malentendus sur la façon dont les choses fonctionnent.

"Oh? Vous pouvez recevoir un message de données avant de recevoir la confirmation que la connexion a réussi? Je ne l'ai jamais su, eh bien, ça ne gérera pas ça!" ... Ce genre de chose. La journalisation est très utile pour vous dire ce que le logiciel a essayé de faire pour vous permettre de repérer ce que vous avez mal fait.


2

D'après mon expérience, un niveau de journalisation élevé est ajouté à l'application lorsque nous ne faisons pas de TDD. Ensuite, le niveau d'incertitude devient élevé, d'où l'ajout de la journalisation pour voir ce qui se passe.

Alors que lorsque je fais du TDD (ou peut-être à tout moment), je me retrouve à ajouter beaucoup moins d'instructions de journal. Cela signifie à son tour moins de LOC et peut (pas toujours) affecter les performances.

Mais nous ajoutons des journaux d’entrée-sortie pour les fonctions de manière semi-automatique dans mon entreprise dans la plupart des cas, quelle que soit la méthode de développement. Comme je le sais, cela a été considéré comme obligatoire pour l'analyse des problèmes de production.

Exemple: les méthodes d'un bean de service EJB présentes sur l'interface publique. Une autre peut être le cas où une fonction effectue des calculs complexes. Il peut être très utile d’avoir des chiffres dans la méthode (par exemple, vous pouvez écrire un test unitaire pour revenir au sujet général).


Pourriez-vous préciser les raisons pour lesquelles vous ajoutez des journaux d'entrée-sortie pour les fonctions? pourquoi est-ce nécessaire dans votre entreprise?
Gnat

Oui absolument. J'espère que c'est mieux maintenant.
dbalakirev
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.