• 10 hours
  • Medium

Free online content available in this course.

course.header.alt.is_video

course.header.alt.is_certifying

Got it!

Last updated on 12/10/18

Modifiez directement la valeur des données

Il est temps de revenir au test unitaire T_WebPageTask.CheckCreation en échec. Nous étions restés du chapitre précédent avec un point d'arrêt défini avant l'appel à Assert. Nous pouvons voir qu'il échoue parce que la date de démarrage de la tâche n'est pas valide : 

Date de démarrage invalide
Date de démarrage invalide

On dirait qu'elle n'a pas été initialisée. C'est effectivement le cas, il suffit donc d'aller dans le constructeur de TodoTask et d'ajouter le code pour stocker la date du jour comme le démarrage de la tâche :

Ajoutez le code d'initialisation manquant
Ajoutez le code d'initialisation manquant

Ainsi toutes les classes dérivées profiteront du fix.

Lorsque le test est relancé pour valider la correction, c'est la dernière validation qui échoue :

Echec du dernier Assert
Échec du dernier Assert

La propriété AbsolutePath ne correspond pas à ce que l'on attend. Cette fois, il ne s'agit plus de corriger le code de la classe mais plutôt du test unitaire qui se base sur la valeur d'une mauvaise propriété.

Comment trouver la bonne ?

Eh bien, on affiche la task puis sa propriété URL afin de voir toutes les propriétés disponibles ainsi que leur valeur : 

Valeur de la propriété AbsoluteUri dans QuickWatch
Valeur de la propriété AbsoluteUri dans QuickWatch

 On voit donc immédiatement qu’il faut se baser sur AbsoluteUri plutôt que sur AbsolutePath :

Et le test passe maintenant au vert !

 

Même si le test est passé au vert, est-il vraiment complet ? En effet, les paramètres passés pour construire une WebPageTask semblent tous être testés. Sauf que… la gestion des énumérations fait que la première valeur de l'énumération est aussi celle qui est prise par défaut par le compilateur C# si la variable n'est pas initialisée explicitement. Ainsi, on peut se demander si le fait de changer la valeur de la catégorie passée lors de la création de la WebPageTask dans le test sera vraiment prise en compte. Aujourd'hui qui peut dire si la valeur Science (première valeur de l'énumération) est mise explicitement par le code du constructeur ou implicitement par le compilateur ?

Valeur par défaut de l'énumération
Valeur par défaut de l'énumération

Il est évident que la meilleure solution est de modifier le test unitaire en fonction. Cependant, je veux profiter de cet exemple pour vous montrer que l'on peut, non seulement voir, mais aussi modifier la valeur des variables avec le débogueur. Regardons donc comment modifier la valeur d'un paramètre en redémarrant le débogueur avec un point d'arrêt avant la construction de la WebPageTask.

C'est très simple ! Il suffit de visualiser sa valeur avec n'importe laquelle des méthodes présentées précédemment et de cliquer sur la valeur elle-même pour la changer :

Changer une valeur avec auto-completion
Changer une valeur avec auto-complétion

La zone de saisie bénéficie de la même auto-complétion que l'éditeur. Une fois la valeur choisie, il suffit de valider avec la touche ENTER.

La nouvelle valeur apparaît partout (même en rouge pour indiquer qu'elle a été modifiée durant la dernière exécution) :

La valeur modifiée apparait en rouge
La valeur modifiée apparaît en rouge et dans tous les panneaux

Si l'on exécute maintenant le code du constructeur avec la nouvelle valeur pour la catégorie avec Step Over (F10), on se rend compte que la catégorie de la WebPageTask créée n'est pas la bonne. On retombe sur la valeur par défaut de l'énumération :

Et maintenant la seconde assertion du test unitaire échoue. :(

Pour comprendre d'où vient le problème exactement, on peut revenir avant l'exécution de la création de la WebPageTask avec Set Next Statement :

Revenir avant la création de la WebPageTask
Revenir avant la création de la WebPageTask

Et on descend dans le constructeur avec Step Into (F11). On peut voir que seule l'URL est stockée à ce niveau :

Constructeur de WebPageTask
Constructeur de WebPageTask

Le nom et la catégorie sont traités dans le code de la classe de base auquel on accède avec Step Into (F11) de nouveau :

Constructeur de ReadTask
Constructeur de ReadTask

Effectivement, ce code ne prend pas en compte le paramètre contentCategory pour donner la valeur de la propriété Category correspondante.

Il suffit donc d'écrire le code pour fixer le problème. On peut même le faire pendant que l'on débogue !

Editer le code pendant que l'on débogue est possible
Éditez le code pendant vous déboguez

Il s'agit de la fonctionnalité Edit and Continue : une fois la modification effectuée, on peut reprendre l'exécution normalement avec Step Over (F10) ou Step Out (Shift+F11). Il y a cependant un moyen plus simple de revenir directement dans le test unitaire grâce au panneau de la pile d'appels via clic-droit Run To Cursor !

Utilisez Run To Cursor depuis la pile d'appels
Utilisez Run To Cursor depuis la pile d'appels

On se retrouve alors dans le test, juste avant le retour du constructeur :

il faut maintenant Step Over (F10) pour voir le résultat :

Etat des Locals après le fix
État des Locals après le fix

Cette fois-ci toutes les valeurs concordent !

Résumé et conclusion

Nous avons vu comment, en plus de visualiser vos données, le débogueur de Visual Studio permet d’en modifier leur valeur et même le code sans re-compiler pendant une investigation.

Ce cours touche à sa fin ! Vous êtes maintenant armé pour partir à la recherche de bugs dans n’importe quel code C# !

Vous avez toutes les clés en main pour :

  • Contrôler le flot d'exécution d'un code C# avec le débogueur de Visual Studio

  • Visualiser et modifier ses données dans le débogueur de Visual Studio

N'oubliez pas de vous exercer pour valider ces compétences en complétant les quiz à la fin de chaque partie ! Je vous souhaite de bons débogages ! :D

Example of certificate of achievement
Example of certificate of achievement