Executive summary : Visual Studio amène des améliorations sur la sélection carrée, et une fonction permettant de retrouver les tests unitaires impactés par une modification de code, de façon à ne rejouer que ces tests pour gagner du temps. Il y a bien sûr plein d’autres choses, mais ce sont parfois les plus petites fonctions qui amènent les plus gros gains de productivité.
Vu les problèmes dans le métro, et la queue monstrueuse pour obtenir son badge, je me retrouve à la bourre à la première session plénière. Bon, j’ai loupé tout ce qui est Windows 7 et 2008 R2. Remarque, ça tombe bien qu’ils aient commencé par ça, ce n’est pas ce qui me passionne le plus. Visual Studio, par contre, ça m’aurait embêté de louper les annonces.
Premier point très intéressant selon moi, juste après la présentation de Pex : le suivi des tests impactés par une modification de code. Typiquement, vous avez 5000 tests unitaires, et ils vous prennent 20 minutes à effectuer sur votre machine. C’est tout de même dommage de devoir tout relancer alors que vous n’avez pas modifié énormément de code. Cette fonctionnalité vous permet de retrouver les tests sur lesquels vous avez potentiellement de l’impact, et du coup limiter fortement le nombre de tests à rejouer, à moins bien sûr que vous ayez tout réécrit dans le System Under Test.
Pour moi, ceci est une vraie avancée, peut-être pas nécessairement la plus complexe à mettre en place de la part de Microsoft, mais qui servira beaucoup à un développeur tel que ceux de mon équipe.
Par contre, une remarque sur Pex de manière générale : je pense, mais c’est un avis personnel, que c’est une très mauvaise pratique de laisser générer sa couverture de code par un outil. La blague que faisait le présentateur de Microsoft en disant que, malgré la mise en place de frameworks de test dans Visual Studio, personne n’en faisait, et que du coup Microsoft avait mis en place un outil pour les aider, est assez révélatrice. Le problème est que les développeurs ne pensent pas en termes de testabilité. Ajouter un outil est très intéressant pour augmenter la couverture de code, mais se baser sur cet outil pour générer des tests sans les architecturer me paraît dangereux. Cela retardera encore plus la prise de conscience des développeurs de l’importance des tests, car ils considéreront toujours que c’est un à-côté du code. Voire même que c’est une tâche bas de gamme puisqu’on peut l’automatiser.
Il faudra aussi tester les limites de Pex en soi. D’expérience, je sais qu’une couverture de code même à 100% ne veut pas dire que le code n’a plus de bug. Donc, l’intérêt de ce genre d’outil dépend de son intelligence, et je ne parle pas seulement en terme de parcours de la complexité cyclomatique. Vu que l’outil est inclus dans la Beta 2 de Visual Studio 2010, je ferai bientôt une petite étude là-dessus.
Un autre point, qui paraîtra aussi certainement comme un simple détail pour quelqu’un qui a assisté à la séance, mais qui me semble vraiment intéressant du point de vue de la productivité d’un développeur : les améliorations sur la sélection carrée dans Visual Studio 2010. La sélection d’un bloc carré de code (avec ALT + la souris) existait déjà en VS2005 et VS2008, mais la nouvelle version est plus intelligente, et supprime deux des limites qui étaient les plus criantes :
- Le remplacement de code automatique : si vous utilisez une sélection carrée et que vous tapez du code, vous remplacer le code sur toutes les lignes par ce que vous tapez. Très pratique !
- Copier-coller avec suppression intelligente des espaces : si vous sélectionnez un carré avec des lignes qui n’ont pas toutes la même taille et que vous les copiez dans d’autres lignes, vous vous retrouvez souvent avec des espaces en trop. Maintenant, c’est automatiquement supprimé. Il me reste à tester si c’est quand on copie dans une chaîne ou si c’est systématique, et surtout si on peut alors débrayer ce comportement, car il y a des fois où c’est utile de le garder dans l’autre sens, typiquement pour de la mise en page.
