La version finale de Visual Studio 2012 étant sortie très récemment, j'ai pu le prendre en main et le tester pendant quelques heures. Je vous propose une petite visite guidée et commentée de cette nouvelle mouture de l'IDE.


Look & feel

Quand le sage lui montre la lune, le fou regarde les majuscules


C'est probablement le sujet qui a fait le plus jaser à la sortie de la RC de Visual Studio 2012 il y a quelques mois. Beaucoup se sont d'abord indignés contre les menus tout en lettres capitales dans la barre du haut. Franchement, je trouve la controverse un peu surfaite - les menus sont un tout petit détail de l'IDE, personnellement je vais assez peu dedans et le passage en majuscules ne m'a pas du tout gêné une fois la surprise initiale passée.

Penchons-nous plutôt sur la charte graphique et l'aspect général de cette nouvelle version.

Je trouve la page de démarrage simple, claire et lisible. C'est grosso modo la même que VS 2010 avec des informations mieux organisées et plus de matière sur les nouveautés de l'IDE. L'onglet Vidéos contient notamment des tutoriels instructifs sur ces dernières.


Page de démarrage

Dans tout l'IDE, Microsoft a fait le choix d'une interface graphique de type "ligne claire" à fort contraste avec très peu de couleurs et des zones carrées à la Metro Style. Les bords et les espaces non remplis, autrefois de couleur foncée, sont maintenant sensiblement de la même couleur que toutes les autres zones (éditeur de texte, explorateurs...) c'est à dire blancs ou gris très clair dans la charte par défaut. J'avoue que j'ai du mal avec ce style très lumineux (high key dirait-on en photographie) qui m'éblouit un peu. Les petits icônes, généralement noirs ou très peu colorés, sont aussi souvent peu reconnaissables et mal choisis.


Thème clair

J'ai donc essayé le thème sombre également proposé de base et... c'est un peu l'excès inverse, je suis vite revenu à l'autre.


Thèeme sombre

Du côté des performances, j'ai constaté une amélioration nette par rapport à VS 2010, que ça soit au lancement ou en termes de réactivité globale de l'IDE. Je n'ai pas non plus fait l'expérience de crashes intempestifs comme avec son prédécesseur à sa sortie. Tout paraît plus fluide - grâce à l'interface allégée ? Cela reste néanmoins à vérifier dans un contexte d'utilisation intensive, avec de nombreux fichiers ouverts, des designers UI, des tests unitaires et des recherches qui tournent, etc.

Au final, en bon adepte du dépouillement, je salue l'effort des concepteurs de VS 2012 pour simplifier l'habillage de l'outil et se concentrer sur l'essentiel ("La perfection, ce n'est pas quand il n'y a plus rien à ajouter mais plus rien à enlever", disait quelqu'un). Il va juste falloir trouver un thème plus confortable pour les yeux sensibles.


Navigation et éditeur de texte

Le retour de la vengeance des pin's


Autant le dire tout de suite, comparé à VS 2010, les innovations ne sont pas énormes en matière de navigation et d'édition du code dans ce cru 2012. On y trouve :

  • Une fonction "preview" très pratique. Il suffit de simple-cliquer sur un fichier dans l'explorateur de solutions pour afficher celui-ci comme si on l'avait ouvert. Simplement, son affichage est temporaire, un fichier en preview chasse l'autre. L'onglet du fichier preview s'affiche à droite, pour le distinguer des fichiers déjà ouverts. C'est une excellente fonction que je me suis retrouvé à utiliser énormément.


Fonction Preview

  • L'épinglage de fichiers, plus anecdotique. Les fichiers épinglés restent de façon permanente à gauche de la rangée d'onglets et ne sont jamais masqués même lorsqu'on a énormément de fichiers ouverts en même temps.


Pin's !

  • Un icône "Tout réduire" est maintenant présent par défaut dans l'explorateur de solution pour replier complètement l'arbre de la solution. Ce n'est pas trop tôt, cette fonctionnalité quasi-obligatoire à mon avis devant auparavant être ajoutée via un add-in ou une macro.


  • Surlignage de la ligne actuelle : elle peut paraître mineure, mais cette fonction apporte un confort non négligeable en nous indiquant instantanément où le code va s'insérer si on continue à taper au clavier. En effet, lorsqu'on part se balader de part et d'autre dans le fichier on perd souvent ce repère et le curseur n'est pas toujours clairement distinguable. Dommage que la ligne surlignée soit assez peu visible en thème clair, et plutôt trop visible en thème foncé.


Il y a aussi la fameuse zone de Lancement rapide qui se présente comme un champ de recherche "environnemental" pour retrouver un menu, une action, un fichier récemment ouvert...


Lancement rapide

L'idée est bonne sur le papier mais 95% de mes actions dans l'IDE étant des tâches familières déclenchées par des raccourcis clavier, j'en ai eu très peu l'utilité. Pour chercher dans des fichiers, je préfère utiliser l'excellent Ctrl-virgule apparu dans VS 2010. L'avenir nous dira si cela change.

En revanche, les manques de fonctions de productivité déjà signalés dans la version 2010 (mais pourtant présents depuis longtemps dans des outils tiers comme Resharper) sont toujours là :

- Toujours pas de "add reference and use"
- Toujours pas de fermeture automatique d'accolades
- Pas de suggestion de noms de variable
- Pas de goto base/inheritor depuis l'éditeur de texte
- etc.

Cette absence d'évolution est particulièrement criante dans le domaine du refactoring où il faut vraiment chercher pour trouver une nouveauté, à part peut-être une entrée de menu pour chercher de la duplication de code sur le code actuellement sélectionné (baptisé de manière amusante rechercher les clones en français).
Pendant ce temps, JetBrains nous ajoute des refactos à la pelle, dont le fameux Extract Class -Resharper reste à des années-lumières de ce que l'environnement de Microsoft sait faire par défaut.


Tests unitaires

Un petit pas pour le Shim, un grand pas pour l'humanité


Selon l'aveu même de représentants de Microsoft, dans un exercice d'auto-critique assez rare pour être souligné, l'équipe de Visual Studio s'est rendu compte que l'environnement de tests de 2010 était orienté testeurs et très peu pratique pour les développeurs.
En effet, le même type de projet Visual Studio servait pour les tests qualité et les tests unitaires des développeurs. Le test runner de VS 2010 était tout sauf confortable car lent, avec une interface verbeuse et peu visuelle obligeant à raisonner selon une notion de "liste de tests" peu familière. Tout cela a été corrigé dans VS 2012 où on a maintenant :

Un test runner digne de ce nom.

Il s'inspire bien sûr fortement des runners déjà existants, que ça soit celui de TestDriven.net, celui de Resharper ou d'autres. On y retrouve l'habituelle barre rouge ou verte ainsi que des pastilles des mêmes couleurs pour chaque test. A noter qu'on peut enfin écrire de nouveau tests et relancer le runner directement, il les prendra en compte sans besoin de passer par une fastidieuse opération d'ajout de tests à la liste. VS 2012 va même plus loin avec quelques fonctionnalités supplémentaires à saluer :

  • Une option permettant d'exécuter automatiquement les tests après chaque build. On est "presque" dans le continuous testing.
  • Dans ce mode, les tests les plus susceptibles d'échouer (ceux qui étaient déjà rouges, etc.) sont réexécutés en premier et les tests qui étaient verts ne sont pas réexécutés si d'autres échouent. On est "presque" dans l'intelligent test running à la JUnit Max.
  • On peut analyser la couverture de code d'un ou plusieurs tests.
  • Des raccourcis clavier sont présents de base pour exécuter un ou tous les tests (d'ailleurs on ne peut pas lancer des tests en faisant un clic droit depuis l'explorateur de solutions, il faut forcément utiliser un raccourci ou le test runner, radical mais étrange pour du Visual Studio...)


Test Runner

Plusieurs types de projet de test au lieu d'un seul.

Les tests d'intégration "pour les testeurs" ont été séparés des tests unitaires automatisés "pour les développeurs". Le Projet de test unitaire est à privilégier lorsqu'on veut faire du TU avec MSTest. Mais la bonne nouvelle, c'est qu'il n'y a même pas besoin d'utiliser ce type de projet pour tirer parti du test runner de Visual Studio, une bonne vieille bibliothèque de classes suffit pour peu qu'on ajoute les références adéquates.

Une plateforme unifiée pour tous les frameworks de test :

la VS Unit Test Platform. Elle fournit une API pour que des adaptateurs pour les différents frameworks de test puissent être développés (ceux de XUnit et NUnit sont déjà disponibles). Cela veut dire que virtuellement n'importe quel framework de test peut maintenant fonctionner avec le test runner de base de Visual Studio, alors qu'auparavant on devait installer soit des runners spécifiques aux frameworks, soit des runners génériques tiers (Gallio, Resharper...)


Un autre gros morceau de l'environnement de tests de VS 2012 est le framework Microsoft Fakes. Cet ambitieux composant inspiré du travail de MS Research sur Pex & Moles n'est ni plus ni moins qu'un framework d'isolation intégré à Visual Studio. Il permet de générer deux types de doublures de test : les Stubs et les Shims. Les premiers sont l'équivalent des Mocks des frameworks déjà existants et peuvent seulement remplacer des interfaces ou des classes abstraites, et les seconds sont plus lents mais peuvent mimer des classes concrètes (MS Fakes marche ici sur les plates-bandes d'outils payants comme TypeMock Isolator). Les Stubs sont recommandés pour mocker des classes de son propre projet alors que les Shims sont utiles comme doublures de classes d'assemblies tiers. On peut ainsi modifier des classes comme DateTime pour simuler une date courante différente, etc.
Au passage, on peut se demander où les concepteurs du framework sont allés chercher le terme Shim ("cale"), signe que le champ lexical de la doublure de test commence à sérieusement s'épuiser. Ceux qui avaient déjà du mal avec les fakes, stubs, mocks, dummies, etc., et on peut les comprendre, seront probablement désormais totalement perdus avec les nouvelles dénominations à la Microsoft....


Techniquement, la mise en oeuvre de ces doublures est assez inédite bien qu'un peu contraignante. Pour pouvoir utiliser MS Fakes, il faut sélectionner une référence à un assembly dans le projet de test et "Ajouter un assembly Fakes" :


Ajout d'assembly Fake

Une nouvelle DLL va alors se rajouter à nos références ; à l'intérieur, tous les Stubs et Shims possibles pour les types de l'assembly de base auront été générés et sont prêts à être utilisés dans nos tests. Malgré le surcoût initial d'ajouter l'assembly fake, cette approche est intéressante puisqu'il y a des chances que ces classes déjà présentes à la compilation soient plus performantes que des proxies générés au runtime, comme dans les frameworks d'isolation actuels.
Le setup des fakes se fait avec une syntaxe classique utilisant des lambdas. Pas de dépaysement de ce côté-là, en revanche un gros point noir : le framework ne semble pas proposer les méthodes d'assertion avancées de ses concurrents -vérifications sur le nombre d'appels d'une méthode d'un Stub, vérification simple des paramètres passés à une méthode, syntaxe fluent, etc.


Utilisation d'un Stub


Application Lifecycle Management

Du pain et de l'Agile


Je n'ai pas pu tester la partie ALM de Visual Studio 2012 par manque de serveur Team Foundation, mais le remaniement a l'air assez considérable et Scrum semble plus que jamais la méthodologie par défaut promue par Microsoft. On sent que l'équipe TFS a mis le paquet pour que Visual Studio, dans ses versions supérieures, devienne un centre complet de gestion du cycle de vie d'un projet.

Parmi les nouveautés que j'ai pu voir,

  • Une nouvelle vue Backlog plus claire (et pas juste un résultat de query TFS)
  • Un Task Board électronique présent par défaut, avec drag & drop et autres joyeusetés.
  • Un écran de planification de sprint
  • Un écran "My Work" dans Team Explorer avec les tâches de l'utilisateur
  • Un cadre pour les revues de code
  • Un système de gestion de feedback utilisateur


Task Board

En parallèle de cela, on peut noter que Microsoft a fait des efforts pour rendre ses outils plus compatibles avec la philosophie agile -notamment après les mini-vagues d'indignation qui ont eu lieu lors de la sortie des premières version beta de VS 2012. On a toujours la possibilité d'assigner les tâches à chaque développeur (façon Waterfall/micro-management) dès le sprint planning, mais ce n'est plus obligatoire ni recommandé (dans l'exemple donné dans la documentation TFS, l'équipe ne le fait pas). De même, j'ai l'impression que la référence au diagramme de Gantt qui apparaissait dans l'écran de planification de sprint a été enlevée.


Conclusion

Ce soleil qui ne voulait pas devenir une Etoile noire


Il y aurait bien d'autres choses à dire sur Visual Studio 2012, qui est un univers à lui tout seul. Comme d'habitude, Microsoft court après son écosystème - une foule de fournisseurs d'add-in tiers innovants - dont il "officialise" dans VS 2012 quelques fonctionnalités, tout en prenant bien garde à le faire assez lentement pour ne jamais rattraper tout son retard sur ces satellites, de peur d'anéantir la galaxie.
Ainsi, l'accent est surtout mis dans cette nouvelle version sur l'expérience utilisateur, l'ergonomie et la gestion de projet, et moins sur des fonctionnalités de développement "de fond" (je ne parle pas ici de la plateforme .Net et de ses langages qui ont bien évolué avec la version 4.5 du framework).

Toutefois, l'intégration d'un test runner potable fait bien progresser l'IDE dans le domaine des tests unitaires. Elle rend Visual Studio "nu" enfin utilisable de façon à peu près correcte dans un contexte de développement agile piloté par les tests - il n'en demeure pas moins que si l'on veut une bonne productivité, un plugin tiers comme Resharper me parait encore indispensable.