Avons-nous besoin de la journalisation lors du TDD?
Lorsque vous effectuez le cycle Red, Green & Refactor, nous devons toujours écrire le code minimum pour réussir le test. C'est ainsi que l'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 à moins qu'il ne se passe quelque chose de vraiment compliqué, cependant, j'ai vu de nombreux messages qui parlent de l'importance d'une journalisation appropriée.
Donc, à part l'enregistrement d'une exception, je ne pouvais pas justifier la réelle importance de l'enregistrement dans une application testée appropriée (tests unitaires/d'intégration/d'acceptation).
Mes questions sont donc:
- Avons-nous besoin de nous connecter si nous faisons TDD? un test échoué ne révélera-t-il pas le problème avec l'application?
- Devrions-nous ajouter un test pour le processus de journalisation dans chaque méthode dans chaque classe?
- Si certains niveaux de journalisation sont désactivés dans l'environnement de production par exemple, cela n'introduira-t-il pas une dépendance entre les tests et l'environnement?
- Les gens parlent de la façon dont les journaux facilitent le débogage, mais l'un des principaux avantages de TDD est que je sais toujours ce qui ne va pas en raison d'un test qui échoue.
Y a-t-il quelque chose qui me manque?
1) Faut-il se connecter si nous faisons TDD? un test échoué ne révélera-t-il pas le problème avec l'application?
Cela suppose que vous ayez tous les tests possibles dont votre application a besoin, ce qui est rarement vrai. Les journaux vous aident à retrouver les bogues pour lesquels vous n'avez pas encore écrit de tests.
2) Devrions-nous ajouter un test pour le processus d'enregistrement dans chaque méthode dans chaque classe?
Si l'enregistreur lui-même est testé, il n'aurait pas besoin d'être retesté dans chaque classe, comme pour les autres dépendances.
3) Si certains niveaux de journalisation sont désactivés dans l'environnement de production par exemple, cela n'introduira-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, certains sont utilisés dans la production et certains niveaux supplémentaires sont utilisés dans le développement, similaires à:
"Le niveau du journal 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 parlent de la façon dont les journaux facilitent le débogage, mais l'un des principaux avantages de TDD est que je sais toujours ce qui ne va pas en raison d'un test qui échoue.
Les bogues de production auront passé tous les tests, vous aurez donc peut-être besoin d'une autre référence pour étudier ces problèmes.
Logging est utile pour expliquer le comportement non exceptionnel d'une application:
Les journaux d'événements enregistrent les événements qui se déroulent dans l'exécution d'un système afin de fournir un piste d'audit qui peut être utilisé pour comprendre l'activité du système et diagnostiquer les problèmes. Ils sont essentiels pour comprendre les activités des systèmes complexes, en particulier dans le cas d'applications avec peu d'interaction utilisateur (comme serveur applications) ...
Quelle que soit la façon dont l'application a été testée et quelle que soit la façon dont les exceptions sont enregistrées, ses utilisateurs peuvent demander,
la sortie de votre programme est 0 alors que nous nous attendions à ce qu'elle soit 1, pourquoi?
Vous devez vous connecter pour vérifier quelle était la configuration de l'application, les paramètres et autres détails d'exécution pour expliquer son comportement (non exceptionnel).
Du point de vue ci-dessus, la journalisation est plus orientée sur support que sur le développement. Une fois l'application mise en ligne, il est souhaitable de laisser quelqu'un d'autre gérer les questions des utilisateurs, afin de permettre aux programmeurs de se concentrer sur le développement ultérieur.
Enregistrer ce que fait l'application permet à quelqu'un d'autre de comprendre le comportement du programme sans creuser dans le code et sans distraire les développeurs par des demandes d'expliquer ce qui se passe.
La plupart des réponses se concentrent ici sur l'aspect de la correction. Mais la journalisation sert également un objectif différent: la journalisation peut être un moyen de recueillir des données pertinentes sur les performances. Ainsi, même lorsque le système fonctionne sans erreur, un journal peut expliquer 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 pour les 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.
À moins d'avoir une couverture de test à 100%, ce qui n'est généralement pas le cas, vous ne pouvez pas savoir que votre logiciel ne se bloquera jamais (EDIT: et - comme indiqué dans les commentaires - même si c'est le cas, quelque chose d'indépendant de votre logiciel pourrait provoquer un accident); c'est la même chose que de penser que vous pouvez faire un logiciel qui n'a absolument aucun bogue (même pas la NASA peut le faire). Donc, à tout le moins, vous devez consigner les échecs possibles au cas où votre programme se bloquerait afin que vous puissiez savoir pourquoi.
La journalisation doit être effectuée par une bibliothèque externe ou un framework interne en fonction de la technologie que vous utilisez. Ce que je veux dire par là, c'est que ce 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 tester que chaque méthode enregistre ce qu'elle est censée faire.
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, bien que les journaux doivent être conservés dans un fichier correspondant à l'environnement (vous devez avoir un fichier différent pour l'environnement de test, de développement et de production tout au moins).
Une erreur peut être très floue et il n'est pas toujours évident de savoir ce qui ne va pas lorsqu'un test TDD échoue. Les journaux devraient être plus précis. Par exemple, si vous faites un algorithme de tri et que le scénario de test entier échoue, vous devriez avoir des journaux pour chaque test de l'algorithme qui vous aident à repérer où se situe réellement le problème.
La réponse courte à votre question principale est: en règle générale, les bogues dans votre code ne seront PAS exposés par TDD. Some pourrait, idéalement beaucoup, mais l'absence de tests qui échouent n'implique pas l'absence de bogues. Il s'agit d'une maxime très importante dans les tests de logiciels.
Étant donné que vous ne pouvez pas savoir si vous aurez un comportement incorrect dans votre système, peut-être dans de rares conditions, la journalisation est un outil utile qui pourrait aider à comprendre ce qui ne va pas lorsque les choses se passent inévitablement.
La journalisation et TDD répondent à différentes préoccupations.
Oui, dans le cas général, vous devez vous connecter.
La journalisation ne concerne pas le débogage. Eh 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:
- L'application est-elle toujours en vie? (En enregistrant un battement de coeur toutes les 1000 secondes.)
- Les performances de l'application ont-elles changé au cours des 10 derniers mois? (En enregistrant les statistiques des 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.)
- L'une de nos interfaces a-t-elle changé leurs caractéristiques de performance?
- La nouvelle version entraîne-t-elle une caractéristique d'utilisation différente vers 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 doit être planifié et conçu et testé, de préférence automatique.
La journalisation est une fonctionnalité qui mérite un traitement, tout comme les autres fonctionnalités.
TL; DR: la journalisation et TDD sont orthogonaux. Le fait que l'un n'ait aucune incidence sur le besoin de l'autre
Avons-nous besoin de nous connecter si nous faisons TDD? un test échoué ne révélera-t-il pas le problème avec l'application?
Dans l'ensemble, la plupart des journaux que j'ai implémentés et que j'ai vus implémentés l'ont été pour le dépannage opérationnel, pas pour le débogage du développement (bien que cela puisse aider). Le public principal de cette journalisation est les administrateurs et les opérateurs qui exécutent vos serveurs, prennent en charge les personnes qui ont reçu des journaux pour analyse, et les clients qui souhaitent consulter les journaux et essayer de comprendre ce qui se passe.
Ces journaux sont là pour vous aider à résoudre les problèmes liés aux points d'intégration. Il peut s'agir de services réseau (base de données, soap, etc.), de ressources locales (disque, mémoire, etc.), de mauvaises données (entrée client, sources de données incorrectes/corrompues, etc.), etc. (paramètres, configurations, etc.) peuvent tous aider au dépannage.
Devrions-nous ajouter un test pour le processus de journalisation dans chaque méthode dans 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, elles doivent être testées. Bien que si vous implémentez la journalisation et les tests de journal à l'aide de la programmation orientée aspect ou de la méta-programmation, cela peut réduire la charge des tests.
Si certains niveaux de journalisation sont désactivés dans l'environnement de production par exemple, cela n'introduira-t-il pas une dépendance entre les tests et l'environnement?
Si vous écrivez votre code à l'aide d'IoC et que vous utilisez des simulations, vous devriez pouvoir tester efficacement toute votre journalisation sans vous fier à une configuration environnementale particulière.
TDD permet généralement de réduire les bogues de codage. Cela aide beaucoup moins avec les bugs de la spécification ou tout simplement les malentendus sur la façon dont les choses fonctionnent.
"Oh? Vous pouvez obtenir un message de données avant vous obtenez 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 afin que vous puissiez repérer ce que vous avez fait de mal.
D'après mon expérience, un grand niveau de journalisation est ajouté à l'application lorsque nous ne faisons pas TDD. Ensuite, le niveau d'incertitude devient élevé, c'est pourquoi nous ajoutons une journalisation pour voir ce qui se passe.
Alors que lorsque je fais TDD (ou peut-être test à chaque fois), 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é jugé obligatoire pour l'analyse des problèmes de production.
Par exemple, les méthodes d'un bean de service EJB qui sont présentes sur l'interface publique. Un autre pourrait être le cas lorsqu'une fonction effectue des calculs complexes. Il peut être très utile que des chiffres entrent dans la méthode (par exemple, vous pouvez écrire un test unitaire pour revenir au sujet général en cours).