Si vous avez plusieurs centaines de tests unitaires, et que ça finit pas prendre un temps non négligeable, vous serez sûrement sensibles à l’ajout d’une fonctionnalité dans Visual Studio 2010 qui permet de ne jouer que les tests impactés par les récentes modifications du code. En démonstration aux TechDays 2010, ça a fait vraiment réagir la salle : c’est le genre de fonctionnalité qu’il n’est pas facile à mettre en place soi-même et qui a un potentiel énorme pour des économies de temps. C’est relativement simple avec les bons outils de mettre en place une usine de test, ou de l’intégration continue. Mais des fonctionnalités de ce type, il faut vraiment du développement derrière…
Bref, vous vous êtes peut-être comme moi rué sur cette fonctionnalité dans la RC, pour la découvrir active dans les menus, mais avec un message d’erreur quand vous essayez de l’activer : “no tests were run because no tests are loaded, no tests are impacted, or the impacted tests are not able to run” ? Pas de panique, c’est normal : l’analyse d’impact n’est pas active par défaut (certainement parce que ça prend pas mal de temps en plus).
Dans le menu Test, vous pouvez choisir une collection de settings à activer, et Visual Studio 2010 (en tout cas la RC) est livré avec deux ensembles : Local et Trace and Test Impact. Par défaut, en mode Local, la gestion d’impact n’est pas active, alors que c’est le cas pour le second set. Bref, vous pouvez activer le second set, ou bien aller dans le menu juste en dessous “Edit test settings”, et modifier les paramètres de l’ensemble de settings que vous utilisez.
En l’occurrence, supposons que vous éditiez le mode Local : vous pouvez aller dans la section Data and Diagnostics et activer Test Impact. Une fois ceci réalisé, vous pouvez tester, et ça marche : si vous faites une modification sur votre System Under Test et que vous utilisez le menu Test / Run / All Impacted Tests, vous ne lancerez que les tests qui ont été impactés potentiellement par la modification de code. Attention, il faut bien compiler votre solution pour que cela fonctionne (vous voyez la barre de couleur sur le côté gauche de votre code modifié passer de jaune à vert lorsque vous sauvegardez).
Il est à noter que l’analyse d’impacts prend un peu de temps, et du coup, les tests fonctionnent un peu moins vite avec ce mode activé. Du coup, ça vaut le coup de plutôt jouer entre les deux ensembles de settings, avec le Local très rapide, et lorsque vos tests commencent à prendre de l’ampleur, changer entre Local et un autre test où vous activez l’analyse d’impact pour être toujours le plus rapide en fonction des besoins (parfois, vous savez qu’il faut quoi qu’il arrive relancer la totalité des tests unitaires).
