IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Intégration Continue avec Visual Studio et Team Foundation Server - Partie I, Présentation de MsTest et de Static Code Analysis


précédentsommairesuivant

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.

Définition du nommage des tests runs
Définition du nommage des tests runs

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.

Définition des DLLs pour lesquelles on veut de la couverture de code
Définition des DLL pour lesquelles on veut de la couverture de code

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 ».

Visualisation du résumé de couverture de code
Visualisation du résumé de couverture de code


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).

Visualisation de la coloration de la couverture de code
Visualisation de la coloration de la couverture de code

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.

Définition des fichiers à déployer
Définition des fichiers à déployer

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.

Emplacement de déploiement des fichiers
Emplacement de déploiement des fichiers

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.


précédentsommairesuivant

Copyright © 2009 Pierre-Emmanuel Dautreppe . Aucune reproduction, même partielle, ne peut être faite de ce site ni de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts. Droits de diffusion permanents accordés à Developpez LLC.