VI. Tests unitaires : Configuration des tests▲
Lorsque l'on crée un projet de test dans une solution, Visual Studio ajoute aussitôt un fichier d'extension « .testrunconfig ». Il s'agit du fichier de configuration pour l'exécution des tests.
Notez qu'il est bien sûr tout à fait possible d'en rajouter d'autres, de façon à avoir des configurations différentes pour plusieurs DLL de test.
VI-A. Définition du nom des « tests runs »▲
Lors de l'exécution de tests, on parle de « test run ». Chacun d'entre eux possède un nom qui par défaut est « UserName@ServerName DateAndTime ».
Il peut être très utile de définir un autre nom à vos « test run », principalement si vous lancez plusieurs « test run » différents lors d'un build.
VI-B. Définition de la couverture de code▲
VI-B-1. Paramétrage▲
On peut également, via l'onglet « Code Coverage », définir pour quelles DLL nous mesurerons la couverture de code lors de l'exécution des tests.
Il suffit pour cela :
- de compiler la solution dans la configuration ;
- de cliquer sur l'onglet « Code Coverage », puis sur « Add Assembly » pour sélectionner la DLL souhaitée.
On pourra laisser les autres options par défaut.
VI-B-2. Visualisation des résultats▲
Pour visualiser le résultat de la couverture de code, il suffit de faire un « clic droit » sur les résultats de tests, et de demander « Code Coverage Results ».
On pourra alors voir un résumé - pour tous les projets couverts - de la couverture de code, autorisant de descendre au niveau de chaque fonction.
Il sera alors possible de double cliquer sur une méthode, de façon à visualiser la partie de code qui est couverte (en bleu) et celle par laquelle aucun test ne passe (en rouge).
Attention cependant : si vous demandez dans votre fichier .testrunconfig de couvrir trois DLL, mais que seules deux d'entre elles possèdent des tests unitaires, on pourrait logiquement s'attendre à que cette troisième DLL apparaissent dans le résultat de la couverture de code avec une couverture à 0 %.
Cependant les DLL couvertes à 0 % n'apparaissent pas dans les résultats. Le pourcentage global de couverture de code peut donc s'avérer trompeur.
VI-B-3. Quel pourcentage rechercher ?▲
Je ne vais pas ici rentrer dans un débat sur le pourcentage de couverture de code à obtenir, mais je tenais à faire une courte mise en garde.
Si tous les experts s'accordent à dire qu'un projet couvert à 10 % est objectivement un projet à risque, a contrario, un projet couvert à 80 ou 100 % ne doit pas donner l'impression d'un projet sûr.
En effet une méthode couverte à 100 % signifie uniquement que du code de test passe par toutes les branches possibles de la méthode. Cela ne garantit en rien que des assertions existent pour toutes les branches possibles.
Il faut davantage s'attarder sur la qualité et la pertinence des tests unitaires que de se fixer un taux arbitraire de couverture de code à atteindre.
VI-C. Déployer des fichiers▲
VI-C-1. Paramétrage▲
Certains tests peuvent avoir besoin de ressources (fichier textes, scripts…) lors de leur exécution. Il est possible via la configuration de définir des fichiers à déployer.
Pour cela, il suffit de se rendre dans l'onglet « Deployment » et de sélectionner « Add File » ou « Add Directory », tout en s'assurant bien sûr que la case à cocher « Enable deployment » est bien cochée.
VI-C-2. Où les fichiers sont-ils déployés ?▲
À chaque fois que les tests s'exécutent, un répertoire avec le nom du « test run » est créé, avec à l'intérieur un répertoire « Out ».
Outre les différentes DLL à tester, c'est ici que l'on retrouve les fichiers déployés.
Attention au nommage des fichiers et répertoires! Si vous demandez de déployer un répertoire, c'est ce répertoire au complet qui sera copié dans le répertoire « Out ».
Dans tous les cas, si vous déployez deux fichiers ou deux répertoires avec le même nom, l'un des deux sera perdu. Un simple avertissement dans un fichier de log vous avertira de votre erreur.
VI-C-3. Précaution d'emploi avec les versions plus anciennes de Visual Studio▲
Notez que lors de l'ajout d'un répertoire, Visual Studio va automatiquement ajouter un « \ » à la fin du répertoire.
Dans les premières versions de Visual Studio 2005 (sans service pack), cela pouvait poser problème lors de l'exécution des tests, considérant que le fichier n'était pas valide. Si c'est le cas, il suffit d'éditer le testrunconfig en XML afin de supprimer le dernier « \ ».
VI-D. TimeOut▲
Le dernier onglet « TimeOut » nous permet de définir un délai maximal avant lequel un test non terminé sera considéré comme abandonné ou échoué.
Ce délai est défini par défaut à 30 minutes.
