Utiliser des systèmes de log qui améliorent la testabilité
Date de publication : 24/06/2006


Une des solutions les plus courantes pour améliorer la testabilité d'une application est d'intégrer un système de log qui fournit des informations sur les opérations effectuées par les composants (qui inclut aussi les données qui sont en train d'être exécutées), sur l'état de l'application et sur les erreurs rencontrées durant l'exécution. Les testeurs pourront alors utiliser ces informations pour monitorer les flux durant l'exécution des procédures de test et pour déterminer d'où vient l'anomalie rencontrée.


Au fur et à mesure que l'application s'exécute, ses différents composants écrivent alors dans les fichiers de log les fonctions utilisées et les principaux objets manipulés. Le système doit fournir suffisamment d'informations (pour que le log soit exploitable pour l'analyse ou le debugging éventuel de l'application) mais pas trop (sous peine d'alourdir la phase d'analyse des logs). Une ligne de log bien formatée devrait contenir le nom de la fonction (ou le nom de la classe utilisée), le nom de la machine et le numéro de process, l'heure de traitement et un message (il peut s'agir d'une description de l'erreur rencontrée ou d'un code d'erreur).


En analysant les différents messages écrits dans les fichiers de log, l'exécution d'une procédure de test peut alors être monitorée et corrélée avec les données inscrites dans la base de données (si c'est applicable). Dans le cas d'une anomalie sévère, le fichier de log indique le composant responsable de l'erreur. Dans le cas d'une erreur de calcul, le fichier de log liste tous les composants qui ont participé à l'exécution de l'opération. Il devrait alors y avoir assez d'informations pour permettre aux développeurs de corriger l'anomalie.


Grâce aux informations fournies, les testeurs ne se contentent plus uniquement de dire qu'il y a une anomalie. Ils élargissent leur compétence et sont maintenant capables de transmettre aux développeurs des informations détaillées sur les opérations internes de l'application qui ont provoqué l'anomalie.


On peut après soit supprimer complètement le système de log du code de l'application, soit, ce qui est préférable, le configurer de telle sorte qu'on puisse le désactiver temporairement et/ou paramétrer différents niveaux de détail dans les fichiers de log. L'avantage de ce système est que lorsque l'application s'exécute dans l'environnement de production, les anomalies sont analysées d'une manière plus efficace (on peut alors reproduire l'anomalie en s'appuyant sur les fichiers de log plutôt qu'en se basant uniquement sur une description approximative et des messages d'erreur peu explicites).


On distingue habituellement 2 niveaux de détail : le premier niveau n'affiche que les erreurs (un message s'affiche uniquement quand une erreur survient) alors que le deuxième affiche plus de détails (notamment les flux de données et les composants qui s'exécutent, en plus des messages d'erreur). Il est également conseillé de réaliser des tests de régression pour s'assurer que de nouvelles anomalies ne sont pas générées à cause du système de log mis en place.



Bottom