Avons-nous besoin de journalisation lorsque vous utilisez TDD?

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?

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.

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.

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.

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.

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.

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.

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.

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.

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