Le débogage en Java/Java EE

C'est de loin la méthode la plus simple et la plus accessible aux débutants, tant que l'on reste dans le cadre de petits programmes peu complexes ou qu'il est impossible de faire autrement. À divers endroits dans le code source, on va insérer des 'system.out.println("ma_variable="+ma_variable.toString())', puis lors de l'exécution du programme on va regarder la console et voir défiler les valeurs des variables.

Cette méthode a plusieurs gros inconvénients, le plus gênant étant que pour activer/désactiver ces traces en console, il faut impérativement modifier le code source et recompiler. Parmi les autres inconvénients, il y a le fait que le média de sortie est par défaut la console (plutôt qu'un fichier), et le fait que les appels toString() ainsi que les appels println() ne sont pas neutres en matière de performance et peuvent ralentir énormément le programme dans certains cas.
Par ailleurs si vous développez une bibliothèque dont quelqu'un d'autre va se resservir plus tard pour développer une nouvelle brique fonctionnelle, il n'aura pas forcément envie d'avoir sa console polluée d'affichages, et d'un autre côté, il peut tout de même avoir envie de savoir ce qui se passe. Enfin, niveau visibilité, un code bourré de sorties console n'est pas génial. Cette méthode est donc à réserver aux petits projets très simples, et aux cas où l'on ne peut pas faire autrement.

Le principe est le même que lors de l'utilisation de l'affichage en console, mais on va utiliser un outil dédié qui va permettre d'affiner le niveau d'information que l'on veut obtenir sans avoir besoin de modifier le programme, et de choisir où ces informations seront enregistrées. Les outils de logs étant plus appropriés pour observer un programme en production, nous reviendrons plus en détail sur le sujet en partie III.

Le principe du mode debug est de faire avancer le programme au pas-à-pas afin de pouvoir observer chacun de ses états successifs. Il y a plusieurs IDE qui proposent un mode debug, dans le cadre de ce tutoriel nous nous restreindrons à présenter le mode debug d'Eclipse, qui est l'IDE le plus répandu. Nous utiliserons l'interface par défaut, mais nous encourageons vivement le lecteur à réorganiser son interface d'une manière plus ergonomique.

Les captures d'écran qui illustrent ce tutoriel ont été prises avec une version standard d'Eclipse. Le projet qui tourne à l'intérieur est l'un des exemples de démonstration de spring-security.

II-C-1. Lancement d'un programme en mode debug.▲

Pour lancer un programme en mode debug, il y a plusieurs solutions, via un raccourci clavier ou via le menu, mais pour l'heure, faites un simple clic droit sur votre projet, survolez le menu déroulant « debug » dans le menu contextuel, puis suivant qu'il s'agisse d'une application Java EE ou non, lancez le débogage sur le serveur ou en tant qu'application Java. Eclipse devrait vous proposer d'afficher la vue de debug, ce que nous vous conseillons d'accepter en cochant la case « toujours… ».

Pour ceux qui font du Java EE :
Si le programme que vous souhaitez déboguer est déployé sur un serveur d'applications indépendant (éventuellement situé sur un autre ordinateur), vous pouvez lancer le débogage en mode remote, comme l'illustre la capture d'écran suivante. Pour afficher ce menu, repérez l'icône représentant un insecte dans la barre d'outils supérieure et cliquez sur la petite flèche à sa droite pour faire apparaitre un menu déroulant dans lequel vous cliquerez sur « debug configurations ». À noter que pour que cela fonctionne, il faut que le serveur d'applications où est déployée l'application soit configuré de manière à accepter le débogage à distance. Pour aller plus loin…

II-C-2. Exécution en pas-à-pas▲

Le but principal de l'exécution en mode debug, c'est de pouvoir avancer en pas-à-pas dans le déroulement du programme. Pour cela nous allons placer un point d'arrêt à l'endroit qui nous intéresse afin de signaler au débogueur de s'arrêter lorsque le programme passe dans cette partie du code. Pour ce faire, double-cliquez dans la marge au début de la ligne de code où vous souhaitez démarrer le mode pas-à-pas. Un point bleu apparaît à cet endroit (là où pointe la flèche dans l'image qui suit), et le point d'arrêt est visible dans la liste des points d'arrêt de l'onglet « breakpoints » sur lequel nous reviendrons au III.C.3.

Il y a beaucoup à dire sur cette image. Tout d'abord, le cadre que nous avons entouré en orange permet de connaître les valeurs de l'ensemble des variables à chaque étape du pas-à-pas (et éventuellement de les modifier via un clic droit). Ensuite la barre d'outils que nous avons entourée d'un cadre vert est celle qui va nous permettre de contrôler la progression du mode pas-à-pas. Nous allons maintenant détailler l'utilité de chaque bouton d'après la lettre que nous lui avons associée :

1. ce bouton « play » permet de sortir du mode pas-à-pas, il indique au programme de se poursuivre normalement jusqu'à ce qu'il rencontre le prochain point d'arrêt ;
2. ce bouton « arrêt », qui est reporté dans la barre d'outils du bas sert à stopper le serveur d'Éclipse. Si le programme débogué est déployé sur un serveur d'applications indépendant, il sera grisé et c'est le bouton B' « disconnect » qui apparaîtra ;
3. ce bouton « rentrer » permet de continuer le pas-à-pas dans la sous-fonction qui va être appelée sur cette ligne s'il y en a une ;
4. ce bouton « sauter » permet de sauter à la ligne suivante dans l'exécution de la méthode en cours ;
5. ce bouton « remonter » permet de terminer l'exécution de la méthode actuelle et de poursuivre le pas-à-pas dans la méthode appelante.

Il est même possible de placer des points d'arrêt dans des bibliothèques. Cependant c'est assez complexe, nous ne le détaillerons donc pas ici.

Sur cette partie du debug, voir aussi DébogueurÉclipse

II-C-3. Points d'arrêt conditionnels▲

Dans certains cas, on peut souhaiter que le programme ne s'arrête sur un point d'arrêt que si une condition prédéfinie est remplie :

La capture d'écran parle d'elle-même. Comme vous pouvez le voir, les possibilités sont multiples. Bien sûr l'autocomplétion fonctionne dans le cadre d'écriture des conditions, ce qui est très pratique.

II-C-4. Tester des morceaux de code pendant le pas-à-pas▲

Un certain nombre de vues permettant d'aider le debug, affichez-les via le menu « Fenêtre », « Afficher la vue », « Nom de la vue » (ou cliquez sur « Autres… » pour les rechercher si elles ne sont pas dans la liste par défaut), puis réorganisez l'interface pour les afficher à un endroit commode.

II-C-4-a. Via des expressions.▲

Comme l'illustre la capture d'écran, cette vue vous permettra de renseigner des expressions qui seront ensuite réévaluées à chaque fois que vous avancerez d'un pas dans le débogage.

II-C-4-b. Via la vue display.▲

Très pratique, la vue display (où l'autocomplétion fonctionne également) permet d'exécuter du code pour altérer le comportement du programme d'une manière un peu plus aboutie que la simple modification de ses variables. Par exemple sur la capture d'écran nous ajoutons un objet dans une map, objet qui sera conservé dans la suite de l'exécution du programme. Tapez votre commande, sélectionnez-la, et cliquez sur le bouton « play » que nous avons encadré en rouge pour l'exécuter.

C'est le moment d'entrer plus en détail sur la journalisation, que nous n'avions que brièvement évoqué au II.B. Le principe est très simple : à tous les endroits du code où vous vous dites qu'il serait intéressant de savoir plus tard ce qui s'est passé, vous allez effectuer un appel sur votre API de logging en définissant le niveau d'importance de l'information. Par la suite, vous allez modifier le fichier de configuration de votre bibliothèque de journalisation pour définir précisément quelles sont les informations que vous voulez récupérer (par exemple en fonction de leur niveau d'importance et du nom de paquet) et où vous souhaitez les écrire.

Rappel : la journalisation s'appuie sur une API qui regroupe l'ensemble des classes que vous aurez besoin d'appeler depuis votre programme Java, mais cette API se borne à un rôle d'interface et la journalisation effective est réalisée par une autre bibliothèque. Vous entendrez par exemple parler de commons-logging/log4j (plutôt dans le cadre de projets anciens), et de SLF4J/LogBack (combo gagnant pour les projets récents). L'un des gros avantages apportés par Logback est le fait qu'il peut recharger automatiquement son fichier de configuration à intervalles réguliers, ce qui évite de devoir redémarrer le serveur à chaque modification et s'avère du coup très utile en environnement de production. Si vous utilisez Log4J il est possible de parvenir à un résultat équivalent via un Listener chargé d'effectuer la recharge à chaud.

La plupart des outils de journalisation définissent six niveaux :

• TRACE : niveau qui affiche le plus d'information. On peut par exemple mettre une trace à chaque entrée et sortie de méthode, et dans chaque boucle itérative. Beaucoup de développeurs jugent qu'il pollue le code et ne l'utilisent pas ;
• DEBUG : pour afficher les informations dont on s'attend à avoir besoin si un problème survient ;
• INFO : pour afficher les informations dont on juge qu'elles peuvent être intéressantes pour la personne chargée de monitorer le programme, mais sans revêtir de caractère alarmant ;
• WARN : pour afficher des informations sur des problèmes qui à eux seuls ne suffisent pas à faire planter le programme, mais traduisent un comportement anormal :
• ERROR : lorsque le programme rencontre un problème qui empêche son fonctionnement ;
• FATAL : lorsqu'une erreur va probablement induire un plantage complet du programme.

Certains outils permettent même de définir des niveaux personnalisés, cependant il y a déjà amplement de quoi faire avec ces six-là. Au niveau du fichier de configuration, vous pourrez par exemple définir que tous les messages de niveau INFO ou plus doivent être enregistrés dans un fichier horodaté journalier suivant un pattern de type monappli-201YMMJJ.log, tandis que les informations de niveau TRACE et plus iront dans un fichier numéroté de maximum 200 MO suivant un pattern de type monappli-debug-N.log avec N compris entre 1 et 10, et effacement automatique du plus ancien. Ce type de configuration vous garantit de conserver à part les informations les plus importantes sur le déroulement du programme, et de pouvoir accéder aux logs détaillés de l'histoire récente de l'application.

Attention, les traces peuvent avoir un coût non négligeable en matière d'utilisation de ressources matérielles, il est donc recommandé de se limiter au minimum vital, en se réservant la possibilité de modifier le fichier de configuration à chaud pour activer les traces correspondant au problème du moment.

Les frameworks d'audit permettent de surveiller le déroulement normal d'une application. Ils sont souvent associés à la programmation orientée aspect (AOP) car ils effectuent une tâche relativement transverse avec une logique indépendante du code source. Ils peuvent par exemple être paramétrés au moyen d'annotations ou de fichiers XML. Nous ne nous attarderons pas sur la question, car ils ne sont pas l'outil le plus utile pour le débogage, mais il était néanmoins intéressant de les mentionner, car ils peuvent apporter des informations complémentaires.

Dans le même ordre d'idées, il existe des outils comme Yourkit qui permettent de surveiller les performances du système et de la JVM.

Dans le cadre d'une application Java EE, il peut être intéressant de disposer d'une ou plusieurs JSP dédiées au diagnostic (que vous pouvez par exemple protéger via une basic-auth). Voici une liste non exhaustive de cas d'usage :

• pour afficher des renseignements de base comme la date du dernier redéploiement et quelques statistiques pertinentes sur la santé de votre application ;
• si votre application dépend de web-services tiers, vous aurez besoin de savoir si l'interrogation de ces web-services se déroule comme prévu. Par exemple il est possible que le web-service soit accessible depuis votre poste de développement, mais que pour une raison quelconque (réseau, pare-feu, règle Apache) il soit bloqué du point de vue de votre application, ou encore, il est possible que votre application ne vous renvoie pas les données que vous souhaitez obtenir, et que vous souhaitiez savoir si la faute doit être imputée au web-service ou aux traitements internes à votre application, auquel cas une petite JSP renvoyant les résultats bruts de l'interrogation du web-service pourrait s'avérer un précieux allié au diagnostic ;
• par ailleurs, le gros avantage d'une JSP, c'est que toute modification à chaud est prise en compte instantanément par le serveur sans qu'il soit nécessaire de le redémarrer… Ce qui peut s'avérer très utile pour tester un petit bout de code à des fins de débogage.

Par robustesse, on ne se réfère pas uniquement la capacité d'un logiciel à résister aux erreurs, mais aussi à sa capacité à fournir des informations détaillées, utiles et pertinentes !
Une des bonnes pratiques est le système de trace/log. On considère que les logs sont uniquement des informations fonctionnelles et les traces des informations techniques (ex. : une stacktrace). On peut alors utiliser des identifiants de transaction que l'on conservera dans les logs et dans les traces pour surveiller l'activité du logiciel durant une transaction particulière. Ce système d'identification de transaction permet de limiter les données propagées et ajoutées à chaque couche. Exemple :

22/12/2012 13:57:01 INFO [00001] Connexion de l'utilisateur DUPONT
22/12/2012 13:57:01 INFO [00002] Connexion de l'utilisateur DUFFOUR
22/12/2012 13:57:01 INFO [00001] Ouverture du document titi.txt
22/12/2012 13:57:01 INFO [00002] Ouverture du document titi.txt
22/12/2012 13:57:01 INFO [00002] Échec de la pause du verrou.

Il suffit de recouper les informations d'une même transaction pour comprendre que DUFFOUR a essayé d'ouvrir le fichier titi.txt, mais qu'il n'a pas pu obtenir le verrou.

La robustesse ne concerne pas que les logs, mais également les informations que le logiciel va pouvoir afficher à l'utilisateur. Dans l'exemple évoqué ci-dessus voici, par degrés de robustesse croissants ce que pourrait afficher le programme :

1. le logiciel a rencontré une erreur fatale ;
2. le logiciel n'a pas pu ouvrir le document ;
3. le document est verrouillé ;
4. le document est verrouillé par un autre utilisateur ;
5. le document est verrouillé par DUPONT.

Admettons que vous ayez écrit un programme qui comprenne une dizaine de classes, aboutissant à une trentaine de possibilités d'usage fonctionnel. Supposons que vous décidiez d'en refactoriser une partie pour ajouter une nouvelle fonctionnalité. Comment être certain alors que votre changement n'a pas induit de régression à moins de retester manuellement tous les cas d'utilisation envisageables ? Ce qui peut s'avérer de plus en plus gourmand en temps au fur et à mesure du développement. Supposons que vous suiviez une méthode de développement dans laquelle il faut livrer un prototype fonctionnel à chaque fin de semaine. S'il vous faut plus d'une semaine pour refaire tous les tests manuellement vous avez un très gros problème. Vous pouvez alors décider d'intégrer un plus grand volume de fonctionnalités avant de refaire les tests, ce qui accroîtra mathématiquement les risques de bogues. Finalement vous serez contraint de faire ce que tout le monde fait : utiliser des tests de non-régression partiellement ou totalement automatisés. Mais attention, tout programme ne se prête pas forcément à des tests. Ça dépend de comment il a été conçu. Dans le cas de certains programmes particulièrement mal ficelés qui mêlent du code métier, du code de présentation et du code de service ou qui font des appels via des méthodes statiques entre singletons, il n'y aura pas d'autre choix que de réécrire une bonne partie des classes juste pour les rendre testables. D'où l'intérêt d'avoir la problématique des tests en tête dès le moment où l'on conçoit l'architecture du code.

Nous allons distinguer deux types de tests :

• les tests d'intégration sont des tests qui permettent d'analyser les entrées-sorties du programme qui est alors vu comme une boite noire (on se moque de ce qu'il contient pourvu que lorsqu'on envoie certaines données, la réponse corresponde à ce qui est attendu). Leur très gros avantage est qu'ils n'ont pas besoin d'évoluer avec le code : tant que l'on continue de garantir la rétrocompatibilité du programme, les évolutions de celui-ci ne doivent pas casser les tests (bien sûr vous devriez avoir de temps en temps des évolutions qui modifient certains tests, mais rarement un grand nombre de tests d'un coup). Dans le cadre d'une application web, il est courant que sélénium soit utilisé ;
• les tests unitaires sont destinés à tester une seule et unique classe. Cela signifie que si la classe en question fait des appels en base de données, on va utiliser un mock (une classe qui simule le comportement de la classe d'accès à la base de données) afin d'effectuer le test en environnement neutre. Cela implique que les accès en base de données ne sont pas écrits directement dans la classe testée, mais délégués à une classe qui ne fait que ça, et qui est injectée dans la classe lorsqu'elle est construite. C'est ici qu'on voit l'importance d'avoir bien pensé l'architecture globale du programme et le découplage des différentes couches.

À partir du moment où vous avez un test unitaire pour chacune de vos classes et/ou un test d'intégration pour chacune de vos fonctionnalités, vous pouvez dormir relativement tranquillement : si une modification de code introduit une régression importante, elle sera quasi systématiquement détectée lors de l'exécution des tests. Un élément important est aussi qu'il doit être facile de relier un groupe de tests à une exigence/fonctionnalité/etc., afin de connaître le scope fonctionnel qui est KO et de mieux prioriser/cibler les corrections.
La limite des tests est qu'ils ne peuvent épuiser l'ensemble des possibilités du programme. À chaque fois c'est juste un cas d'école qui est testé, et vous pouvez passer à côté de problèmes non prévus.

Pour ceux qui souhaiteraient creuser un petit peu la question, la documentation sur Developpez.com est très riche sur la question. Vous pouvez également jeter un coup d'œil à tout ce qui est relatif aux outils de build automatisé. Mentionnons enfin qu'il existe des outils qui permettent d'analyser quelles sont les parties de votre code qui sont bien testées et celles qui mériteraient de l'être mieux, citons par exemple Cobertura et Clover.

Certains développeurs utilisent les tests pour certifier la conformité du programme au cahier des charges. Si c'est votre cas, nous vous déconseillons d'écrire les tests après avoir écrit le code qu'ils doivent tester. En effet votre impartialité serait alors biaisée et vous auriez tendance à écrire des tests qui passent dans votre compréhension du cahier des charges. Il est bien plus intéressant de commencer par écrire les tests, de s'assurer qu'ils compilent, mais ne passent pas (normal, vous n'avez encore rien écrit, et puis dans le cas contraire, c'est soit que le test a un problème, soit que la fonctionnalité était en fait déjà couverte par le code existant, et que vous n'avez donc rien à faire) et de vous astreindre à ne commencer à coder qu'après. Pour programmer ludiquement, vous pouvez écrire les tests pour vos collègues et leur demander d'en faire de même pour vous. Ces pratiques, qui rentrent dans le domaine du TDD (Test Driven Developement ou développement guidé par les tests) permettent d'être certain de respecter le cahier des charges sans être biaisé. Et puis l'avantage est que lorsque le développement s'achève, les tests sont déjà là, pas de risque de les oublier ou de les remettre aux prochaines calendes grecques à cause de la deadline qui arrive.

De nombreux outils d'analyse du code existent. Ils parcourent le code source automatiquement, repèrent les redondances, les situations connues comme problématiques et tous les endroits où les bonnes pratiques ne sont pas respectées. La plupart peuvent être utilisés en tant que plugins Maven ou indépendamment. Il existe des solutions tout-en-un comme Sonar, qui est capable de récupérer automatiquement le code dans un dépôt subversion, de l'analyser, et de présenter des rapports de synthèse graphique dans un navigateur web. Lorsqu'une société fait réaliser un logiciel au forfait et qu'elle en achète le code source, vous avez 90 % de chances qu'elle s'appuie sur l'un de ces outils pour juger de la qualité du code livré.

L'intégration continue fait un pas de plus dans l'automatisation des tests. Généralement couplé à un outil de build comme Ant ou Maven, l'outil d'intégration continue va surveiller le dépôt où est centralisé le code source et recompiler automatiquement le projet à chaque changement. Il enverra optionnellement une notification à l'outil d'analyse du code pour qu'il prenne en compte les derniers changements. Selon la manière dont l'outil de build est configuré, il pourra lancer automatiquement l'ensemble des tests unitaires (comportement par défaut de Maven) et d'intégration (configurable via des plugins dédiés), et enverra automatiquement des e-mails aux développeurs en cas de problème. De manière optionnelle, si le logiciel fait office de serveur (par exemple s'il s'agit d'une appli Java EE), un plugin peut permettre de la redéployer automatiquement, de façon à avoir une version démo intégrant les toutes dernières fonctionnalités disponibles en permanence.