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 :
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 :
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 :
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 :
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 ?
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 :
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) :
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 :
Et on descend dans le constructeur avec Step Into (F11). On peut voir que seule l'URL est stockée à ce niveau :
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 :
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 !
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 !
On se retrouve alors dans le test, juste avant le retour du constructeur :
il faut maintenant Step Over (F10) pour voir le résultat :
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
