Débuggez votre application Java

Game of Throws : qu’est-ce qu’un rapport de bug ?

Quand un logiciel échoue, les utilisateurs impactés peuvent se plaindre. Pour définir ce qui a mal fonctionné et le réparer, recueillez autant d’informations que possible sur la panne. C’est un rapport de bug.

Par exemple, imaginez que vous prêtiez main-forte aux personnes maintenant une application qui aide les équipes commerciales à calculer les tailles de selle de dragon en fonction de leur âge. Voici une brève description du produit :

Comme chacun le sait, les dragons sont des créatures mythiques qui n’existent pas.🐲  Pas naturellement, en fait. C’est un fait peu connu qu’en l’an 1 après J.-C., le sage alchimiste Lou Tan Dey-ta a créé un petit groupe de dragons grâce à des moyens contre-nature et quelques potions effervescentes. Ces dragons sillonnent encore les cieux aujourd’hui. 🐉

Les dragons ont une espérance de vie extrêmement longue et grandissent à un rythme constant, mais lent. L’achat de la bonne selle est une affaire compliquée. Pour aider ceux qui seront assez chanceux pour monter sur un dragon un jour, Lou Tan a publié un algorithme pour calculer la taille d’une selle en fonction de l’âge du dragon. Des siècles plus tard, cet algorithme a été réécrit en toute hâte en Java pour aider ceux qui ont la bonne fortune d’avoir besoin de selles de dragon.

Le calculateur de taille de selle de dragon est devenu un improbable accessoire favori des soirées réussies !

Le code laisse beaucoup à désirer. Malheureusement, un utilisateur a suscité un rapport de bug sur l’application. L’équipe commerciale a récemment perdu une cliente importante, la princesse Drag’on, qui a acheté une selle trop petite en raison d’estimations défaillantes de l’application.

Regardez le rapport de bug :

Reporter de bug : Sander des équipes commerciales

Date : 18 mai 2020

Titre du bug :

Estimations de selles de dragon non valides à partir de l’application

Description :

L’exécution de l’application “Taille de selle de dragon” sans aucun argument résulte en une panne que je ne comprends pas !

Cela impacte nos Chevaucheurs de dragon premium, car je ne peux pas recommander de selles adaptées en ce moment…

Étapes pour reproduire :

L’exécution de la run task de Gradle (./gradlew run) résulte en l’erreur suivante :

Gravité :

Impacte le flux de travail des équipes commerciales ! Nous avons déjà perdu un client qui a choisi de chevaucher les dragons à cru. Car notre contournement manuel pour « deviner » a résulté en une selle trop petite.

Réparez le plus vite possible, s’il vous plaît ! 

Un bon rapport de bug doit inclure :

• La personne qui a signalé le bug : le reporter de bug.
  Vous avez besoin d’un contact pour vous aider à reproduire le bug et répondre à toute question supplémentaire. La personne qui l’a signalé peut aussi aider à vérifier qu’il est réparé.

• La date (quand le bug s’est produit).
  Le fait de connaître le moment où un bug a été signalé peut vous aider à vérifier s’il est lié à d’autres problèmes connus. Par exemple, il a pu se produire une interruption du réseau ce jour-là.

• Une description ou une explication du bug.
  Jusqu’à ce que vous parliez à l’utilisateur, encouragez-le à fournir autant d’informations pertinentes que possible dans le rapport de bug. Par exemple, cela ne fait pas de mal que l’utilisateur fournisse également la version du logiciel ou le numéro de build (s’il a accès à cette information). Encouragez-le à vous fournir autant de détails que possible, afin que vous puissiez reproduire et comprendre le problème.

• Une série d’étapes pour reproduire le bug.
  Pour vous aider à reproduire le bug, demandez à l’utilisateur de détailler les étapes impliquées. Il peut décrire exactement ce qu’il a fait et faire une capture d’écran du résultat. Cela l’encourage aussi à s’assurer qu’il n’a pas commis d’erreur en documentant le process précédant le bug.

• Gravité et impact du bug.
  Le bug impacte-t-il les utilisateurs ? Les affecte-t-il directement ? Coûte-t-il de l’argent ? Nuit-il à votre marque ? Les conséquences d’un bug vous aideront à déterminer son importance et sa priorité. Le fait de travailler sur un bug prend du temps qui pourrait être consacré à l’amélioration du code, l’ajout de fonctionnalités, et la réponse à d’autres problèmes.

Comment dois-je répondre à un rapport de bug ?

Dans cet exemple, l’équipe commerciale veut que le bug soit réparé le plus vite possible, ce doit être urgent !😱  Bougez-vous !

Attendez ! Stop !🛑  Tout d’abord, pour être sûr que cela vaut la peine d’y consacrer plus de temps, vérifiez le champ de gravité dans votre rapport de bug. Si vous travaillez au sein d’une équipe avec un product owner et d’autres personnes qui s’intéressent au logiciel, demandez-leur toujours si c’est plus important que d’autres tâches.

Ensuite, ralentissez un peu pour comprendre le bug. Ainsi, vous pourrez le réparer méthodiquement et aller vite à nouveau. Même le fait de réparer le problème le plus simple peut accidentellement résulter en une réparation incomplète, ou causer l’apparition d’un autre problème ailleurs. Souvenez-vous, si la solution était évidente, vous (ou un autre développeur) ne l’auriez peut-être pas cassée au départ.

Pour reproduire méthodiquement ce bug, vous devez :

1. Comprendre le rapport de bug (ce que vous devez observer).

2. Parler à l’utilisateur.

3. Trouver une version adaptée de l’application pour procéder au test.

4. Reproduire le bug.

Heureusement, l’utilisateur vous a montré comment reproduire le bug dans le rapport ci-dessus, donc la dernière partie sera un peu plus simple. 😉 Passons à l’étape 1 !

Étape 1 : Comprenez le rapport de bug

Tout d’abord, lisez le rapport de bug et essayez de comprendre ce que vous dit chaque section. Dans le rapport ci-dessus, vous voyez qu’ils ont perdu un client, et que les estimations de selles ne fonctionnent pas correctement. Cela signifie qu’il y a des défauts et des pannes qui impactent directement les utilisateurs, y compris l’équipe commerciale !

Le bug a été signalé en 2020, et le résultat suggère que le programme a échoué en raison d’une taille de selle négative et inattendue.

Nous verrons de manière plus détaillée comment lire le reste de cette exception plus tard, en enquêtant de façon plus approfondie sur le problème. Tout d’abord, nous devons nous assurer que nous pouvons reproduire le problème – car il pourrait ne pas être réel !

C’est une bonne question, et nous allons y répondre dans la section suivante ! 🙃

Étape 2 : Parlez à l’utilisateur

Un rapport de bug peut provenir d’utilisateurs réels, de testeurs, ou de qui que ce soit d’autre ayant utilisé votre code. Ce sont des personnes réelles, et il est bon de commencer par parler avec elles pour comprendre le bug. La personne qui a signalé le bug a fait un rapport sur ce qui a déclenché le bug. Pour l’aider, vous devez pouvoir reproduire le problème.

C’est souvent une bonne idée d’aller voir l’utilisateur en personne et de voir s’il peut vous faire une démonstration du problème. De nombreux bugs de logiciel sont causés par le PEBKAC (Problem Exists Between Keyboard and Chair, ou  « le problème est situé entre la chaise et le clavier »). En d’autres termes, une erreur manuelle. Bien que vous appréciiez et fassiez confiance aux personnes signalant des bugs, vous savez à quel point il est facile d’être frustré et contrarié de manière irrationnelle par un programme qui ne se comporte pas bien. Je le sais bien !

Comment être sûr que ce n’est pas un cas de PEBKAC ? Une brève conversation permet généralement de vérifier s’il s’agit d’un problème réel. L’utilisateur vous sera reconnaissant si vous pouvez lui montrer que le problème a disparu comme par magie, sans aucun effort. Peut-être que l’utilisateur avait un câble réseau débranché, ou exécutait la mauvaise version du logiciel.

Le fait de discuter avec l’utilisateur peut fournir d’autres informations à utiliser dans votre enquête (mode Sherlock Holmes ON !). Il peut également être utile d’avoir quelqu’un à qui montrer votre solution quand vous aurez fini, et qui réponde à vos questions.

Si l’utilisateur n’est pas accessible, demandez-lui un court enregistrement d’écran du problème ! Vous pouvez alors regarder le comportement de l’utilisateur et reproduire exactement ce qu’il fait. Si possible, vous devriez aussi faire cela lorsque vous allez le voir en personne. Les nuances du moment peuvent se perdre, et les étapes décrites ne capturent pas toujours chaque détail.

Voici une vidéo qu’un développeur pourrait avoir capturée en étant assis à côté d’un utilisateur ayant soulevé un bug.

Imaginez que l’utilisateur vous ait montré le bug, et qu’il se déroule exactement comme dans le ticket. C’est un problème de logiciel.

Cet utilisateur doit travailler sur d’autres tâches, vous aurez donc besoin d’un autre environnement pour reproduire le bug et creuser davantage. Il est temps d’enquêter jusqu’à trouver la cause première du problème. C’est-à-dire la raison pour laquelle il se produit.

Étape 3 : Mettez en place un environnement représentatif

Il vous faut une version de ce code à exécuter et tester. La première chose à faire est d’effectuer git clone sur le répertoire et git checkout master sur sa branche produit. Cela variera en fonction du projet, mais commencez par répondre à cette question :  « Comment puis-je exécuter une version de notre code de production localement ? »

Pour vérifier le code et le réparer, vous devez cloner le répertoire, l’importer dans votre IDE, et vous assurer que tout cela a bien fonctionné en exécutant les tests dans le projet.

Voyons cela en action avant d’en décomposer les étapes :

Comme vous l’avez vu, nous venons d’obtenir quelques informations au sujet du bug :

• L’utilisateur peut le reproduire.

• L’utilisateur utilisait la dernière version du code.

• L’utilisateur se contente de suivre des instructions simples pour consulter le code de Git et l’exécuter avec gradlew run.

Voici un récapitulatif :

• Clonez le répertoire.
  Nous avons cloné le répertoire de https://github.com/OpenClassrooms-Student-Center/openclassrooms-dragon-saddlesize-checker. Cela nous donne le code source Java du projet que nous débuggons afin que nous puissions le construire, le modifier, et l’exécuter localement.

  • Ce projet utilise sa branche master pour représenter le logiciel qui est sorti en production. C’est la branche sur laquelle nous allons enquêter.

  • Même si nous avons utilisé IntelliJ pour cela, vous pouvez également le faire depuis la ligne de commande si vous préférez. Pensez à importer votre projet dans IntelliJ avant de commencer le débug.

git clone https://github.com/OpenClassrooms-Student-Center/openclassrooms-dragon-saddlesize-checker

• Exécutez les tests.
  Nous avons utilisé Gradle et IntelliJ pour exécuter les tests unitaires existants dans le projet. Exécutez-les avant de commencer pour vous assurer qu’il n’y a aucun problème connu dans le code qui causerait son échec.

  • Si le code ne se construit pas, cela signifie que vous ne regardez pas la version correcte pour ce bug. Étant donné que l’utilisateur utilise actuellement une copie en exécution de ce code, même s’il comporte des bugs, il a été compilé un jour.

  • Vous pouvez éliminer tout build cassé de votre investigation initiale. Évitez de descendre dans un tunnel sans fin d’inconnues, et assurez-vous de commencer avec la version du code source qui représente celle qui est utilisée par l’utilisateur. Élémentaire, mon cher étudiant ! 🕵️

Étape 4 : Reproduisez le bug

Si vous regardez à nouveau le rapport de bug, vous verrez que les étapes pour reproduire le bug impliquent de taper :

./gradlew run

Faisons cela et voyons ce qu’il se passe ! Je vous montrerai comment le faire de la même façon que l’utilisateur l’a fait, et également avec l’intégration Gradle d’IntelliJ :

Comme vous l’avez vu, nous avons validé le fait que le bug est réel. En le reproduisant, nous savons qu’il y a un problème sous-jacent qu’il faut traiter, et qu’il n’avait rien à voir avec la machine locale de l’utilisateur qui l’a signalé.

Si vous allez réparer un bug, il est important de savoir comment le code devrait se comporter. Le fait de revoir le ticket ne nous donne pas cette information. Prochaine étape, regardez les tests.

Regardez les tests de ce projet dans le dossier src/test/java et ouvrez le com.openclassrooms.debugging.DragonSaddleSizeEstimatorTest. Il contient des tests avec des valeurs attendues pour une sélection d’années différentes.

Le test pour l’an 2 après J.-C. (*n’oubliez pas de lire l’histoire dans le README du projet) porte le titre de estimateSaddleSize_shouldReturnASizeOfOne_forEarlyEraTwoAD et ressemble à ceci :

@DisplayName("Given we have a saddle size estimatorUnderTest spell")
@ExtendWith(MockitoExtension.class)
class DragonSaddleSizeEstimatorTest {
    ...
    @DisplayName("When estimating for a saddle size in the year 2 AD then the size is 1 centimeter")
    @Test
    public void estimateSaddleSize_shouldReturnASizeOfOne_forEarlyEraTwoAD() throws Exception {
       
        double estimatedSaddleSize = estimatorUnderTest.estimateSaddleSizeInCentiMeters(2);
        // A one year old dragon has a 1 cm saddle size
        assertThat(estimatedSaddleSize, is(equalTo(1.0)));
    }
    ...
}

Comme vous l’avez vu précédemment, les tests ont réussi. Cela signifie que la taille de selle pour l’an 1 après J.-C. est correctement calculée, du moins dans nos tests. Nous savons également qu’il y a une classe DragonSaddleSizeEstimator   avec une méthode estimateSaddleSizeInCentiMeters(Int year), qui est utilisée pour estimer la taille d’une selle quand on lui fournit une année.

La ligne 9 appelle la méthode estimateSaddleSizeInCentiMeters, et la ligne 11 valide que le résultat attendu est de 1 cm. Il y a aussi un autre test, qui vérifie la taille des selles des dragons vivant en l’an 2021. Si vous regardez le DragonSaddleSizeEstimatorTest  , vous verrez qu’il y a deux valeurs attendues dans les tests :

Vous pouvez supposer que le test est correct, étant donné qu’il représente un comportement avec lequel les experts métier et les sorciers qui prédisent les tailles des dragons seraient d’accord. 😎

Il existe un autre indice concernant la façon dont le programme devrait se comporter. Si vous creusez un peu plus et consultez le fichier README, il vous dit que nous pouvons exécuter l’application pour calculer la taille des dragons pour n’importe quelle année. C’est exactement ce que nous allons faire. Voici ci-dessous les instructions du README :

Exécutez cette application

Calculez la taille de selle d’un dragon pour l’année en cours

./gradlew run

Cela ira par défaut à l’année en cours et vous fournira une estimation adaptée.

Calculez la taille de selle d’un dragon pour N’IMPORTE QUELLE année

Vous pouvez passer n’importe quelle année à la commande gradlew avec  --args  Eg.

./gradlew run --args 2020

Cela renverra la taille de selle pour l’année 2020. 

Essayez par vous-même !

Voyez si vous pouvez exécuter l’application pour définir la taille de selle pour 2020, en spécifiant l’année.

Sous Linux et OS-X, utilisez la commande suivante :

./gradlew run --args 2020

Sous Windows, elle devrait être :

gradlew.bat run --args 2020

Est-ce que cela a échoué, ou avez-vous récupéré une valeur ?

Que se passe-t-il si vous l’exécutez pour les années 2021 et 2022 ? Recevez-vous les mêmes valeurs que celles qu’attendait le test ?

Écrivez un test qui échoue pour vérifier votre théorie

En tant qu’ingénieur responsable, vous contactez l’utilisateur qui a soulevé le bug et expliquez qu’il peut passer une valeur pour l’année 2020. L’utilisateur est ravi qu’il y ait un contournement, mais préférerait ne pas spécifier l’année. C’est une distraction du flux de travail habituel. Il a confirmé que 2020,0 est la valeur correcte pour 2021. De la même manière, 2021,0 est la valeur pour 2022.

Vous êtes prêt à écrire un test qui échoue ! Soyez prudent. Le bug s’est déjà introduit en production une fois par le passé. Comme vous l’avez vu, tous les tests existants réussissent. Vous devez dupliquer la façon dont le programme fonctionne dans le monde réel pour bien concevoir ce cas de test !

Regardons la méthode main(String[] args) de la classe DragonSaddleSizeGuesser, le point d’entrée de Java pour tout programme.

public static void main(String[] args) throws Exception {
    DragonSaddleSizeEstimator estimator = DragonSaddleSizeEstimator.INSTANCE;
    // Loop needlessly to replicate and ancient ritual
    for (int i=0; i<Integer.MAX_VALUE; i++) {
    }
    // Estimate the saddle size of a dragon,
    // relative to the year One when all extent dragons were born.
    int targetYear = Calendar.getInstance().get(Calendar.YEAR);
    // Take the year from the command line arguments
    if (args.length != 0) {
        targetYear = Integer.parseInt(args[0]);
        estimator.setCopyOfUniversalConstant(42); // The universal constant
        estimator.setYearOfBirth(1); // All dragon's were spawned in 1 AD
    }
     
    System.out.println("Calculating saddle size for a dragon in the year " + targetYear);
     
    // Calculate Saddle Size
    double saddleSize = DragonSaddleSizeEstimator.INSTANCE.estimateSaddleSizeInCentiMeters(targetYear);
     
    // Report
    new SaddleSizeReporter(targetYear, saddleSize).report();
}

Réfléchissons à tout cela !

• Ligne 2 : cette classe principale obtient une instance d’une classe DragonSaddleSizeEstimator à la ligne 2 depuis une variable statique nommée INSTANCE.

• Lignes 4 à 5 : d’étranges rituels recommandés par les spécialistes mystiques, qui n’affectent pas l’exécution. Ils ressemblent un peu à des exigences métiers. Ne les jugez pas – pour l’instant. 😉

• Ligne 8 : l’année en cours est obtenue avec Calendar.getInstance() de Java.

• Lignes 10 à 14 : permettez à l’utilisateur de passer une année spécifique en utilisant des arguments depuis la ligne de commande.

• Ligne 19 : estimez la taille de selle pour une année donnée.

• Ligne 22 : faites un rapport sur la taille de selle.

Regardons ce code. Si vous ignorez les lignes 10 à 14, le code restant est tout ce qui serait nécessaire pour exécuter l’application sans que l’utilisateur ne lui passe une date. Et si nous transformions cela en test ?

Pour rappel, les tests fournissent un moyen rapide de reproduire un bug de façon répétée. Si le test s’attend au comportement correct, il continuera à échouer jusqu’à ce que vous intégriez la première réparation qui corrige le bug. La méthode scientifique suggère d’effectuer de multiples expérimentations pour confirmer les théories. Pendant que vous essayez de réparer le problème, utilisez le test pour confirmer les théories. De plus, le fait de reproduire le bug fidèlement à chaque exécution vous aide à examiner ce que fait le logiciel.

Voici quelques questions pour vous. Comment le code s’est-il comporté quand une année lui a été passée sur la ligne de commande ? Comment peut-on comparer cela à l’exécution de l’application sans lui avoir passé une année ?

Vous voyez où nous voulons en venir ? La première théorie est que vous pouvez écrire un test qui échoue démontrant que, si vous exécutez l’application sans passer de date, cela lèvera l’exception soulevée dans le rapport de bug.

Si vous regardez l’exception dans le rapport de bug (reproduite ci-dessous), vous pouvez suivre la chaîne de lignes commençant par « at com.openclassrooms.debugging » à la ligne 3, jusqu’à la dernière occurrence de ce type.

Calculating saddle size for a dragon in the year 2020

Exception in thread "main" com.openclassrooms.debugging.exception.InvalidSaddleSizeException: Unexpected saddle size:-49.0

at com.openclassrooms.debugging.DragonSaddleSizeVerifier.verify(DragonSaddleSizeVerifier.java:13)

at com.openclassrooms.debugging.DragonSaddleSizeEstimator.estimateSaddleSizeInCentiMeters(DragonSaddleSizeEstimator.java:60)

at com.openclassrooms.debugging.DragonSaddleSizeGuesser.main(DragonSaddleSizeGuesser.java:34)

Pouvez-vous voir que cela se situe dans  com.openclassrooms.debugging.DragonSaddleSizeGuesser  ? Cela se produit juste après un appel à  estimateSaddleSizeInCentiMeters(..)  . Regardez l’exemple de notre méthode principale ci-dessus. Il correspond à la ligne 19, où nous avons appelé  estimateSaddleSizeInCentiMeters()  .

Le bug a quelque chose à voir avec la façon dont DragonSaddleSizeEstimator est appelé quand vous ne fournissez pas de valeur pour l’année dans la ligne de commande. Le test va dupliquer la façon dont la classe principale appelle le DragonSaddleSizeEstimator.

Le test unitaire existant pour le DragonSaddleSizeEstimator utilise des mocks, ou simulations, pour le DragonSaddleSizeVerifier. C’est-à-dire qu’il utilise de fausses versions de cette classe pour accélérer les tests et les rendre plus prévisibles. C’est une pratique de test normale.

Étant donné que DragonSaddleSizeVerifier est la classe qui lève l’exception dans l’extrait ci-dessus (ligne 2 de la trace d’appels), il vous faudra utiliser une version réelle de cela dans le nouveau test. En piochant directement dans la méthode main, ou méthode principale, créez un nouveau DragonSaddleSizeEstimatorIntegrationTest. Ce test créera une nouvelle instance du vérificateur, ainsi que de toute autre classe avec laquelle il aurait besoin de collaborer. Cela prouvera qu’elles s’intègrent correctement, donc cela signifie que c’est un test d’intégration.

Laissez-moi vous montrer comment je peux prendre le comportement dans notre méthode main et le transformer en test d’intégration qui échoue :

Comme vous l’avez vu, j’ai pu créer un test qui duplique le comportement de la méthode main ci-dessus. Ne reproduisez pas toutes les lignes de la méthode principale, mais son flux normal. Étant donné que c’est un test, j’ai fait l’impasse sur les déclarations print et la mise en place des paramètres passés au programme.

Voici notre test :

@DisplayName("Given that we have a DragonSaddleSizeEstimator")
public class DragonSaddleSizeEstimatorIntegrationTest {

    @DisplayName("When the year is 2020 Then the saddle size should be 20.19 meters")
    @Test
    public void estimateSaddleSizeInCentiMeters_shouldReturnTwentyPointNineteen_whenCalculatingTheSizeIn2020() throws Exception {

        // ARRANGE
        DragonSaddleSizeEstimator estimator = DragonSaddleSizeEstimator.INSTANCE;

        // Act
        Double expectedSaddleSize = DragonSaddleSizeEstimator.INSTANCE.estimateSaddleSizeInCentiMeters(2020);

        // Assert
        assertThat(expectedSaddleSize, is(equalTo(2019.0)));

    }

}

Le test a été écrit en trois étapes :

• Ligne 9 : Implémenter l’utilisation d’une instance du  DragonSaddleSizeEstimator  . Cela se fait exactement comme dans la méthode principale.

• Ligne 12 : Utiliser cette instance en appelant la méthode  estimateSaddleSizeInCentiMeters()  avec la valeur 2020.

• Ligne 15 : Affirmer que l’estimation correcte attendue est 2019,0.

Vous pouvez récupérer ce code avec la branche ‘integration-test’ et la commande CLI :

git checkout integration-test

Contrairement à la méthode main, Calendar.getInstance() n’est pas utilisé pour obtenir la valeur passée à la ligne 12. L’exception levée a été reproduite avec succès.

Lisez toujours l’exception. 😇  Les quelques premières lignes sont les suivantes :

com.openclassrooms.debugging.exception.InvalidSaddleSizeException: Unexpected saddle size:-49.0
at com.openclassrooms.debugging.DragonSaddleSizeVerifier.verify(DragonSaddleSizeVerifier.java:13)
at com.openclassrooms.debugging.DragonSaddleSizeEstimator.estimateSaddleSizeInCentiMeters(DragonSaddleSizeEstimator.java:60)
at

Si vous exécutez le test avec l’option débug, cela vous permet de demander à la JVM de marquer une pause quand elle lève une exception. La ligne supérieure montre sa localisation, et l'endroit d’où elle a été levée. Vous pouvez alors appeler des méthodes sur l’exception et interagir avec elle pour voir des détails là où elle a été levée.

Je vais exécuter le test encore une fois en utilisant le débugger et dire à l’application de s’arrêter quand l’exception est levée, et nous la regarderons alors de plus près.

Félicitations, vous venez de voir le débugger en action. Essayez vous-même avec le répertoire que vous avez déjà cloné.

En résumé

• Un rapport de bug fournit des détails sur un bug, tels que : qui l’a signalé, son impact, et comment le reproduire.

• Vous écrivez un test pour une application qui montre ce qui devrait se produire en l’absence du bug. Cela s’appelle un test qui échoue, car il échouera en présence du bug.

• Avec un débugger, vous pouvez exécuter un test et suspendre la JVM quand une exception spécifique est levée.

Dans le chapitre suivant, nous allons enquêter sur la première ligne de notre trace d’appels !