Développer du code performant et de qualité avec Visual Studio 2008

La première étape lors du développement d'une méthode, ou d'une fonction, en dehors de l'analyse et du développement proprement dit, est de vérifier que cette méthode répond aux spécifications. Il nous faudra donc tester les différents cas qui sont censés être gérés au sein de cette méthode.

Visual Studio nous permet, au travers des différents menus, qu'ils soient contextuels ou non, et des différentes fenêtres mises à notre disposition, de créer, de gérer et de lancer les tests unitaires.

Le Framework utilisé par Visual Studio a été également fortement amélioré. Un test unitaire peut désormais hériter d'un autre test unitaire, ce qui permet, entre autres, de réaliser les différentes initialisations dans une classe de base et évite les doublons de code pour les tests unitaires.

Les tests unitaires peuvent également être appliqués à du code T-SQL.

Parfait, nous avons créé des tests unitaires et ceux-ci sont tous au vert. Enfin une application sans bugs, sans comportements non contrôlés et qui donc satisferont pleinement l'utilisateur final ! Mais… est-on sûr de cela ? Non bien sûr, effectivement, nous venons de tester des morceaux d'application, mais quel est le pourcentage de code qui est réellement couvert par les tests unitaires? Pour le savoir, Visual Studio nous propose une fonctionnalité appelée « couverture de code ». Cet outil nous donne ce pourcentage méthode par méthode. Enfin, pour identifier les lignes de code qui ont été testées et celles qui ne l'ont pas été, cette fonctionnalité surligne chacune de nos lignes de code dans une couleur différente selon si un test couvre ou non celle-ci.

L'analyse du code permet d'identifier les erreurs de codage et les vulnérabilités au niveau de la sécurité. Cette analyse utilise la source de notre code afin de vérifier que nous respectons les différentes guidelines. Dans le cas contraire, nous recevons un avertissement dans la fenêtre « Liste des erreurs » si bien connue des utilisateurs de Visual Studio 2005.

De quel type sont les messages que l'analyseur nous renvoie ? Il vérifie par exemple qu'une librairie de classes est bel et bien signée, que les variables sont bien initialisées avant leur utilisation et bien d'autres choses encore.

Par rapport à son prédécesseur, Visual Studio 2008 propose plus de 20 nouvelles règles dont principalement des règles autour des conventions de nommage et de l'orthographe, ce qui est très utile étant donné que parfois, les fautes d'orthographe dans une application peuvent provoquer un retour disproportionné de la part des utilisateurs par rapport à ces fautes. Pour éviter de recevoir des messages au sujet de l'orthographe des termes liés au métier auquel l'application est destinée, il vous est possible d'utiliser un dictionnaire personnel.

Mais le code d'une application s'arrête-t-il à la partie .NET de celle-ci ? Bien sûr que non. D'ailleurs, souvent, le rôle de développeur .NET et de développeur SQL coïncide. C'est pourquoi ce type d'analyse s'applique également sur du code T-SQL. Ainsi, si nous avons utilisé un « SELECT * » dans une requête, l'analyseur nous indiquera qu'il est préférable de donner le nom des colonnes à retourner. Il sera ensuite très simple de réaliser la modification en utilisant du refactoring sur le code T-SQL.

Enfin, on notera une véritable évolution du point de vue de la gestion de ces messages puisque la suppression des messages est bien plus efficace qu'auparavant. Il est par ailleurs possible d'indiquer que les messages nous indiquant des améliorations possibles dans du code généré ne soient pas pris en compte.

Maintenir du code peut s'avérer une tâche ardue si les bonnes pratiques n'ont pas été mises en place. L'analyse statique du code ne permet pas de vérifier si les bonnes pratiques du point de vue architectural (faible cohésion entre les objets…) sont respectées ou non.

Ainsi, sur base de valeurs telles que le nombre d'objets liés à une classe et le nombre de lignes présentes dans une méthode, un indice de maintenabilité est calculé. Le développeur peut ainsi aisément identifier les zones de code à refactoriser.

Un des critères importants pour les utilisateurs d'une application est la vitesse d'exécution de celle-ci.

Ainsi, il est intéressant de réaliser des tests de performance durant le processus de développement. Identifier un goulot d'étranglement dans le code et cela avec des chiffres obtenus ligne par ligne permet de mettre le doigt sur une méthode qui rendra l'utilisation insatisfait et qui demande donc du refactoring.

Afin d'identifier ce qui s'avère être la meilleure solution, il est également important de pouvoir comparer deux ensembles de résultats de tests de performance. Cela semble anodin, mais il s'agit d'une des nouveautés les plus appréciées dans cette nouvelle version.

Le choix des résultats à comparer se doit d'être simple afin de permettre d'obtenir des résultats de comparaison réellement utiles. Cela est possible grâce à l'utilisation de filtres basés sur le timestamp ou le processus, entre autres.

Comment notre application va-t-elle se comporter si plusieurs centaines ou plusieurs milliers de personnes s'y connectent simultanément ?

Souvent, les tests sur les applications sont effectués par quelques personnes maximum et l'application ne subit pas le stress qu'elle subira le jour de la mise en production. Or, nous savons tous qu'une application qui n'est pas accessible le jour de sa sortie ne reçoit que difficilement pleine confiance des utilisateurs qui doivent s'y connecter.

Ainsi, il est important de réaliser des simulations réalistes basées sur différents critères comme la durée du test, le nombre d'utilisateurs et bien d'autres critères.

Enfin, si le nombre d'utilisateurs simulés est insuffisant, il nous est possible d'utiliser des agents à installer sur d'autres ordinateurs qui simuleront des utilisateurs supplémentaires.

Pour tester nos applications web, nous allons utiliser la notion de scénario. Pour réaliser ces scénarios, rien de plus simple, il suffit d'enregistrer ceux-ci dans Internet Explorer grâce au plugin Test Recorder. Cette nouvelle version du plugin est capable de capturer le trafic généré par les requêtes effectuées à l'aide de XMLHttpRequest (et donc ce qu'il est communément appelé « AJAX »). Test Recorder peut également gérer les paramètres dynamiques qui peuvent être utilisés dans notre application.

Ces scénarios peuvent évoluer au fur et à mesure que le développement avance. Dès lors, le refactoring des tests d'applications s'avère d'une grande utilité. Ce refactoring permet d'extraire des sous-tests qui peuvent être exécutés seuls ou être liés entre eux. Grâce à cette possibilité de faire appel à d'autres tests, il est aisé de créer de nouveaux scénarios.

Les métadonnées et les résultats sont stockés dans des fichiers XML. Grâce à cela, vous pouvez manipuler ces fichiers à la main ou par programmation. Il est par ailleurs aisé de partager des fichiers contenant les définitions de tests, par l'intermédiaire de Team Foundation Server par exemple.

Toutes les définitions de tests doivent respecter un schéma qui est décrit dans le fichier TestTypes.xsd. En respectant ce schéma, nous pouvons créer de nouvelles définitions de tests qui pourront être exécutés par Visual Studio.

Éviter tout conflit et faciliter la manipulation des sources sur le serveur, voici ce qui ressort des nouvelles fonctionnalités et menus présents dans Visual Studio. Ainsi, il est par exemple possible d'automatiser le téléchargement de la dernière version lors de chaque « check-out », ce qui assure d'éviter la perte de modifications réalisées par un membre de l'équipe sur ce même fichier.

Plusieurs personnes peuvent intervenir sur un même fichier, à des moments différents. Ainsi, bien que l'on puisse forcer la déclaration du lien entre des fichiers et un Work Item lors de l'envoi des fichiers sources sur le serveur (check-in), comment pouvons-nous savoir qui a fait quelle modification ?

Tout simplement en utilisant des annotations. Celles-ci nous donnent la date et le nom du développeur qui a fait des modifications, bloc de lignes par bloc de lignes. Ces informations proviennent directement de Team Foundation Server puisque, à nouveau, c'est lui qui centralise ce type d'informations.

Cette fonctionnalité était disponible au sein de Visual Studio 2005 sous la forme d'un Power Tool.

À nouveau présent en tant que Power Tool dans la version précédente de Visual Studio, la comparaison de répertoires permet d'identifier rapidement les différences entre le contenu des répertoires ou des fichiers.

Cette comparaison peut être réalisée entre des répertoires ne se trouvant pas sur la même machine.

Nous utiliserons la « Wildcard Expansion » pour remplacer un « SELECT * » par un SELECT avec les noms des colonnes. Notez que ce refactoring est capable de gérer les alias, évitant ainsi toute ambigüité et ainsi toute erreur dans les requêtes.

On notera également que lors du refactoring de la procédure stockée, tout DataSet utilisant cette procédure pour son chargement est automatiquement refactorisé.

Cet ensemble de fenêtres permet non seulement de réaliser des comparaisons entre des données ou des schémas de bases de données, mais également de générer les scripts permettant de synchroniser deux bases de données.

Les scripts générés peuvent être également sauvegardés pour une exécution ultérieure. Cette fonctionnalité est très utile pour faciliter les mises en production, que ce soit vis-à-vis des changements sur le schéma ou des configurations stockées dans une table par exemple. Nous sommes évidemment libres de modifier ces scripts si le besoin s'en fait sentir.